PgcEdit v7 discussion thread

[Sir Didymus]

...
Anyway, I have released PgcEdit_winexe_7.4beta1.zip (http://home.tiscali.be/debie.roland/pgcedit/beta/PgcEdit_winexe_7.4beta1.zip). Could you test it, especially with NTSC material? Also, I wonder if it works fine with ARccOS protected DVDs.

Thanks for your help!

Hi r0lZ!

Thanks for your excellent work on the VTS and PGC playback time!
Afraid I can only report about PAL material...

I tested your quoted release on two ARccOS titles (I say again: PAL material). After ripping the titles with the PSL2 plugin (ver. 2.19), in the cleaned up output these titles evidenced incorrect playback times on many cells.

I am happy to report that, into these conditions, your beta is completely (and properly) working: it allows to automatically correct both the individual cells playback times and the whole PGC playback time.

:thanks:

SD

[r0lZ]

I checked a new PGCEdit release with 2 NTSC DVD which I have now (Tomb Raider and Tomb Raider 2). Unfortunately, change nothing:-(. Wrong timemap still stay in IFO's. Warning:

Time Map tables
DVD-TEXT General Name: ""
Provider ID: "MPUCODER"
Number of VTS: 1
-------------------- VTS 1 --------------------
1 VTS_TMAP tables defined in VTS_TMAPTI for 1 PGCs.

VTST 1 , 1 TTN 1 (1:57:09) Title 1 (sequential title)
1759 x 4 seconds = 1:57:16 ; ********** WARNING! **********
------------------- Summary -------------------
VTST 1 , 1 TTN 1 (1:57:09) Title 1: Wrong TMAP duration

In addition, I checked with Total Commander and OS Filecompare utility (fc.exe) a new and original IFOs (before/after timemap plugin using). All files are absolutely identical:-((. What your utility doing? Maybe you forgot to write an overpatching to IFO?
Well, if the files are not changed, it's probably because nothing needs to be changed.
As I explained above, it is possible that the conversion of the 90KHz clock timings to time codes is wrong in NTSC. But in this case, at least some time codes should have changed.
Note that a log is displayed when at least one time code is modified. If all timings are OK in the original IFOs, the log is not displayed.

BTW, r0lZ, you placed on your homepage (videohelp) a plugin list with Timemap plugin v1.0. Now I have (downloaded early) a v1.1 (Plugins - Time map - About). What is it?
Aaaa, I see. It just a string into plugin "set version 1.1". I changed it to 1.0. Please, no penalty to me for this copyright violation:-)).
You're right. I don't remember a v1.1. It's probably something I forgot to change when I've copied/pasted the header of the file. Anyway, the next version will be 1.2, so that no confusion will be possible. Consider the current version as v1.0 or 1.1, it doesn't matter.

[r0lZ]

OOPS!
I think I found an error. It seems an identification error of stream type (PAL/NTSC) or just incorrect uses a divisor (90000 or 90090). In Tomb Raider a last entry of timemap is 1759, start sector is 2236550 (see my IFOs at Lara2.zip). This sector contains a "VOBU start presentation time" is 633230329. Thus:

633230329 / 90000 = 7036 or 1:57:16 (that be indicating as "wrong" timemap).
633230329 / 90090 = 7029 or 1:57:09 (as wrote at movie playtime).

Please look this condition in your program (90000 or 90090 divisor) and check it.
I'm not sure we are talking of the same thing.

The time map tables are always computed by dividing the clock values by 90000, because the clock is always a 90 KHz clock, even in NTSC. Therefore, 633230329 / 90000 = 7036 seconds (approx.)
The conversion problem occur only when the clock has to be converted to a SMPTE drop-frame time code in NTSC. Those time codes are used in the PGCs and in the Cell Elapsed Time in the nav packs, but not in the time map tables.

Also, note that this time map table is not accurate. An entry in the table must be the address (LBA) of a nav pack, but there in no guarantee that there is a nav pack exactly at the right position.
Also, if a tiny black cell is added at the end of the PGC, that cell is usually not included in the time map, because it doesn't make sense to jump in that cell. But the total time of the PGC must include it.

You must also understand that the total playing time of the PGC is the total of the playing time of all cells, but is not the end time of the last VOBU of the last cell. For example, if the VOB ID changes somewhere in the PGC, the clock is reset (but not exactly to 0.)
And the start time of the first VOBU of the first cell is never 0. This delay must be removed from the total.
Also, if a cell is removed at the beginning of the PGC, the total time of the PGC will change, of course, but the timings in the VOBUs are not modified.

Anyway, I see in the log:Provider ID: "MPUCODER"Therefore, this DVD has been muxed with Muxman. IMO, you should trust it! If PgcEdit gives the same tables than Muxman, it's an excellent guarantee that my calculations are right!

[r0lZ]

@ Sir Didymus and Blutach:
Thanks for the feedback, guys!

I still need some confirmation that it works well in NTSC. Someone can test that?

[President]

2 r0lZ.

Thank's for the answers.

[President]

2 r0lZ.
In the NTSC DVD your and Mpucoder timemaps are identical, exclude this (the same timemap after PGCEdit recalculating).
Mpucoder:

[00000000] Number of VTS_TMAPs 1 [0001]
[00000004] End byte of VTS_TMAPs table 7051 [00001b8b]
[00000008] Time map 1: start byte 12 [0000000c]
[0000000c] Time unit (in seconds) 4 [04]
[0000000e] number of entries in time map 1759 [06df]
[00000010] Entry 1: at sector 349 [0000015d]
[00000014] Entry 2: at sector 1495 [000005d7]
...
[000000c0] Entry 45: at sector 56345 [0000dc19]
[000000c4] Entry 46: at sector 57327 [0000dfef]
[000000c8] Entry 47: at sector 58602 [0000e4ea]
...
[00000198] Entry 99: at sector 125788 [0001eb5c]
[0000019c] Entry 100: at sector 127223 [0001f0f7]
[000001a0] Entry 101: at sector 128685 [0001f6ad]
...

You:

[00000000] Number of VTS_TMAPs 1 [0001]
[00000004] End byte of VTS_TMAPs table 7051 [00001b8b]
[00000008] Time map 1: start byte 12 [0000000c]
[0000000c] Time unit (in seconds) 4 [04]
[0000000e] number of entries in time map 1759 [06df]
[00000010] Entry 1: at sector 349 [0000015d]
[00000014] Entry 2: at sector 1495 [000005d7]
...
[000000c0] Entry 45: at sector 56345 [0000dc19]
[000000c4] Discontinuity Entry 46: at sector 57327 [8000dfef]
[000000c8] Entry 47: at sector 58602 [0000e4ea]
...
[00000198] Entry 99: at sector 125788 [0001eb5c]
[0000019c] Discontinuity Entry 100: at sector 127223 [8001f0f7]
[000001a0] Entry 101: at sector 128685 [0001f6ad]
...

Maybe it's important for you.

[r0lZ]

Well, seems nobody knows exactly where the discontinuity bit must be set. Apparently, mpucoder doesn't set them at all.

I have analysed several commercial DVDs, and all of them share the same method: the discontinuity bit is set on the last entry of each cell. Therefore, I have adopted that method. Anyway, I'm almost sure this bit is never used by the players.

The sector numbers are exactly the same because we use exactly the same method to compute them... and it's the right method! Thanks again to mpucoder for his help!

[bigotti5]

Set the discontinuity bit is not implemented in the current release of muxman, r0lZ method is correct.
One difference to the commercial solutions (Scenarist, Maestro) I have seen is the number of entries.
Pgcedit, muxman have one or two entries more (the last one or two).

[r0lZ]

BTW, bigotti5, do you know why there are more entries in some cases? Is it only when there is an additional tiny chapter at the end of the PGC? I have noted that this last cell is usually not included in the time map tables.

[bigotti5]

..do you know why there are more entries in some cases?

IMO it has to do with the VOBU_SRI entries in the navpacks.
Here an example where Pgcedit creates one entry more than the original.
Time unit is 3
Below the VOBU_SRI entries from the additional navpack in pgcedit


......
[0509] Next 7 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[050d] Next 6.5 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[0511] Next 6 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[0515] Next 5.5 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[0519] Next 5 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[051d] Next 4.5 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[0521] Next 4 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[0525] Next 3.5 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[0529] Next 3 sec. VOBU with video 1073741823 1073741823 [3fffffff]
[052d] Next 2.5 sec. VOBU with video 457 -2147483191 [800001c9]
[0531] Next 2 sec. VOBU with video 457 -2147483191 [800001c9]
[0535] Next 1.5 sec. VOBU with video 334 -2147483314 [8000014e]
[0539] Next 1 sec. VOBU with video 222 -2147483426 [800000de]
[053d] Next 0.5 sec. VOBU with video 111 -2147483537 [8000006f]
[0541] Next VOBU with possible video 111 -2147483537 [8000006f]
[0545] Previous VOBU with possible video 112 -2147483536 [80000070]
......

You see the "Next 3 sec VOBU .." has the value "3fffffff"
If the "Next x sec" (x = time unit) holds "3fffffff" then there is no entry in the time table.
Not sure if I am correct...

[r0lZ]

Thanks. I don't understand the reason well, but that's an information.
Now, the question is: do I need to remove the additional entries, or is it OK to leave them?

[wmansir]

Right. There is an option to remove the toolbar and statusbar in trace mode. I don't use it, and I forgot that. Anyway, in the next version, you will not be able to save twice at the same time.

Grrr...this option has been annoying me for 6 months! Since I have PCGEdit setup to start in Trace Mode I didn't even realize the disappearing toolbar was related to activating Trace Mode. Thanks to this post I final found it under the Trace setup options. Thanks, r0lZ.

[FredThompson]

@r0lZ,

Would you please add the Version Info resource. It's all blank right now:

1 VERSIONINFO
FILEVERSION 8,4,2,11
PRODUCTVERSION 8,4,2,11
FILEOS 0x4
FILETYPE 0x2
{
BLOCK "StringFileInfo"
{
BLOCK "040904b0"
{
VALUE "FileDescription", ""
VALUE "OriginalFilename", ""
VALUE "CompanyName", ""
VALUE "FileVersion", ""
VALUE "LegalCopyright", ""
VALUE "ProductName", ""
VALUE "ProductVersion", ""
}
}

[r0lZ]

Well, I don't know how to do it. Remember that PgcEdit is written in Tcl/Tk, a scripting, interpreted language. There is normally no "exe" file.
The standalone exe is an auto executing zip archive, created by freeWrap, a Tcl wrapper. It is not compiled. There is nothing in the freeWrap command line to specify the version information.

[FredThompson]

Use Resource Hacker on the exe file and you can set the various data. http://www.users.on.net/johnson/resourcehacker/

[blutach]

Very good FredThompson. I have been wondering why this info hasn't been there, too.

Regards

[FredThompson]

It lets OpenExpert work properly: http://www.baxbex.com/openexpert.html

This is a great util. I've got Wordpad, Notepad, IE and Firefox set for all file types and PgcEdit, VobBlanker, IfoEdit and MPC set for .ifo files.

[r0lZ]

Thanks for the links!

I haven't tried Resource Hacker yet, but since the zip files are created automatically by a batch file when a new PgcEdit release is created, I would like to set the version information automatically with a CLI tool. Do you know something similar as Resource Hacker, but usable from CLI?

Also, I wonder what's the benefit of OpenExpert over the standard "Open with" menu of WinXP. It is possible to configure several app for the same file type under XP without an external program like OpenExpert.

[FredThompson]

I don't know if there is a CLI resource tool, sorry.

OpenExpert lets you set the order of the associations, which is nice. I suspect it's also stickier.

I don't think it will let you custom assign icons by extension. That would be nice since Windoze uses the default association. (Try setting icon by graphic or video file type and you'll see what I mean...)

[dirio49]

Thanks for the links!

I haven't tried Resource Hacker yet, but since the zip files are created automatically by a batch file when a new PgcEdit release is created, I would like to set the version information automatically with a CLI tool. Do you know something similar as Resource Hacker, but usable from CLI?



Yes, it does

Check out the help file

http://www.angusj.com/resourcehacker/reshack_hlp.zip

[FredThompson]

OpenExpert let's you set true global associations and overrides, so to speak. The registry hack which added "Open with Notepad" to all file types in Win2K behaves differently with WinXP.

[r0lZ]

Yes, it does

Check out the help file

http://www.angusj.com/resourcehacker/reshack_hlp.zip
Yes, I've found that Resource Hacker can be used from CLI, but apparently, it is not possible to specify the version number directly. The only thing you can do via CLI is to add/replace an already compiled resource. Therefore, I need now something to be able to compile the version information... or another program, able to modify the version number directly from CLI.

Anyway, this work seems a bit too complicated for the benefit. Why do you need this info? IMO, it's totally useless.

[ron spencer]

yah just focus on program....this version thing is useless

[FredThompson]

Resource Hacker - File | Save As - set the destination file type as "resource file"

The FileVersion field isn't that important. The descriptions are the fields I was looking for. OpenExpert keys on those. Perhaps other file association programs/checkers/junk removers key into this as well.

This is what I have. You might want to add your copyright statement so it's embedded.

1 VERSIONINFO
FILEVERSION 8,4,2,11
PRODUCTVERSION 8,4,2,11
FILEOS 0x4
FILETYPE 0x2
{
BLOCK "StringFileInfo"
{
BLOCK "040904B0"
{
VALUE "FileDescription", "PgcEdit"
VALUE "OriginalFilename", "PgcEdit"
VALUE "CompanyName", ""
VALUE "FileVersion", "7.3"
VALUE "LegalCopyright", ""
VALUE "ProductName", "PgcEdit"
VALUE "ProductVersion", "7.3"
}
}

[Surgeon]

Hi r0lZ,

First, let me send out a big THANK YOU for the effort you've put into developing PgcEdit over the years! It's become one of my most often used utils and the latest version, 7.3, is simply wonderful!

As an owner of several Sony 400-Disc DVD changers, one of the areas that PgcEdit addresses is of great interest to me -- it's ability to edit the VIDEO_TS.IFO's TextData for the Volume Name allows the changers to id the discs automatically, which saves a lot of time by not having to manually input the information into the players for each disc.

Concerning this feature, I offer the following questions/observations...

Why do you limit the DVD-Text string to 30-characters max? In my research, I have never found any such string length imposed in the actual DVD specs, and actually have several discs with much longer titles (eg: I have one with the TitleText data of "Don't Be A Menance To South Central While Drinking Your Juice In The Hood"). The text simply "scrolls" on the LCD display if it's lengthy, and the player's "explorer" menus simply truncate the longer titles to fit their format automatically. And since I control my changers via a RS-232 interface connected to my HTPC, allowing for the full-length title is a big plus. I feel that this needs to be expanded to allow 128 characters at least...

Also, very occasionally, I run across a disc which has multiple entries for the DVD-Text Volume field. Mainly these are "episodic" discs which list the name of the disc as the 1st Volume text, followed by title entries of the individual epidsodes. (Sony's recient release of "Odyssey 5" is a perfect example). PgcEdit *should* pick/edit the 1st occurance of the VolumeText fields as the disc's title, but instead it processes the last occurance (which is the disc's last episode title).

The following is an excerpt from IfoEdit's VMG_TXTDT_MG table showing what I am refering to:

[000000ea] Language_1: reserved? 0 [0000]
[000000ec] Volume: 1 0 0 0 [01 00 00 00 ]
[000000f0] Name: Odyssey 5 - S1D1 48 0 1 20 [30 00 01 14 ]
[000000f4] : Odyssey 5 - S1D1 240 0 1 20 [f0 00 01 14 ]
[000000f8] Name: Play All 48 0 1 37 [30 00 01 25 ]
[000000fc] : Play All 240 0 1 37 [f0 00 01 25 ]
[00000100] Name: Pilot 48 0 1 46 [30 00 01 2e ]
[00000104] : Pilot 240 0 1 46 [f0 00 01 2e ]
[00000108] Name: Shatterer 48 0 1 52 [30 00 01 34 ]
[0000010c] : Shatterer 240 0 1 52 [f0 00 01 34 ]
[00000110] Name: Astronaut Dreams 48 0 1 62 [30 00 01 3e ]
[00000114] : Astronaut Dreams 240 0 1 62 [f0 00 01 3e ]
[00000118] Title: 2 0 0 0 [02 00 00 00 ]
[0000011c] Name: Title1 48 0 1 79 [30 00 01 4f ]
[00000120] : Title1 240 0 1 79 [f0 00 01 4f ]
[00000124] Title: 2 0 0 0 [02 00 00 00 ]
[00000128] Name: Title2 48 0 1 86 [30 00 01 56 ]

In addition to the above TitleText issues, I have a question which has been bugging me for quite some time concerning disc playback in general which I hope you, or some other knowledgeable soul, might be able to help me with...

What happens differently between between inserting a disc (and having it begin playing by reseting it's registers and starting with the FirstPlay PGC) and doing a Non-Resume Play (after hitting Stop, Stop while playing)? I know the Non-Resume Playback doesn't re-execute the FirstPlay PGC, but does it clear/reset/set any registers and which PGC does it start with? Is there any simple way to determine via the PGC command-set & registers if playback was initiated from a "Non-Resume" state versus inserting the disc? Unfortunately PgcEdit, which has taught me a lot, doesn't emulate the Stop/Stop/Non-Resume playback scenario, so I'm lost on this point... Any insights would be *greatly* appreciated...

Again, thanks so much r0lZ for such a terrific utility!
-Surgeon-

:thanks:

[blutach]

The label limit is, AFAIK, 32 characters (all upper case, no spaces) for ISO9660, but for UDF 1.02 (which is all the player really needs, despite the twin filesystems), it can be 126 characters, upper and lower case, including spaces.

Regards

[Surgeon]

The label limit is, AFAIK, 32 characters (all upper case, no spaces) for ISO9660, but for UDF 1.02 (which is all the player really needs, despite the twin filesystems), it can be 126 characters, upper and lower case, including spaces.

Regards

Blutach,

I think we're referring to 2 different things... The filesystem's (9660/UDF) title fields are different than the various TextData fields contained within the VIDEO_TS.IFO file structure itself, which AFAIK contains *no* limits. It's these VIDEO_TS.IFO file data structures, that are utilized by the various dvd players/changers, that I'm referring to...

-Surgeon-

[blutach]

But I think the disk label in PgcEdit (http://www.videohelp.com/~r0lZ/pgcedit/index.html)'s ISO create/burn routine is gotten from this field and that's why it is limited.

Regards

[Surgeon]

You are 100% correct, in that the default disc volume label is pulled from the dvd's TitleText during the .iso creation (as also is the default output .iso name itself). But that field itself is editable separately on the .iso creation screen. And if it simply truncated the full dvd's TitleText down to 30 characters (maybe during the step where it converts it into all uppercase) then that wouldn't be any big deal, as long as it still maintained the full name you entered within the .IFO's VolumeName field...

-Surgeon-

[r0lZ]

Hi r0lZ,

First, let me send out a big THANK YOU for the effort you've put into developing PgcEdit over the years! It's become one of my most often used utils and the latest version, 7.3, is simply wonderful!
Thanks!

Why do you limit the DVD-Text string to 30-characters max? In my research, I have never found any such string length imposed in the actual DVD specs, and actually have several discs with much longer titles (eg: I have one with the TitleText data of "Don't Be A Menance To South Central While Drinking Your Juice In The Hood"). The text simply "scrolls" on the LCD display if it's lengthy, and the player's "explorer" menus simply truncate the longer titles to fit their format automatically. And since I control my changers via a RS-232 interface connected to my HTPC, allowing for the full-length title is a big plus. I feel that this needs to be expanded to allow 128 characters at least...
I haven't a good reason to limit the text to 30 characters! My old Sony DVD-S725D scrolls the text on the LCD display, like your player, but it can also display it on screen, and that display is limited to 30 characters. But it's probably due only to the size of the font.
Note that I have already received several requests to shorten the string even much more! The ability to display a long text depends of the player, as it is (probably) not specified by the standard.
I will add a user configurable option with the number of characters in the config file. I'm not sure I will add the GUI to change the value interactively, but you should be able to edit the .cfg file manually. Is it OK for you?

Also, very occasionally, I run across a disc which has multiple entries for the DVD-Text Volume field. Mainly these are "episodic" discs which list the name of the disc as the 1st Volume text, followed by title entries of the individual epidsodes. (Sony's recient release of "Odyssey 5" is a perfect example). PgcEdit *should* pick/edit the 1st occurance of the VolumeText fields as the disc's title, but instead it processes the last occurance (which is the disc's last episode title).
When there is no VMG_TXTDT_MG table in the original DVD, PgcEdit creates the Volume General Name and the Volume Movie Name only. That's easy.
However, it is not so easy to know which field must be changed when there is already a VMG_TXTDT_MG table in the original DVD.
My player displays the Volume General Name, but I have modified the code at the request of several users, to change also the Volume Movie Name, the Title 1 General Name and the Title 1 Movie Name, because those names are used by some players.
I've just looked at the code, and it is true that I read all fields sequentially. This is why the last entry has precedence. I will fix this bug. Thanks!

Note: When the VMG_TXTDT_MG table exists already, the user can only overwrite the existing label. The table is not rebuilt from scratch. Therefore, it is not possible to lengthen the string in this case, and the maximum length value in the setups will be ignored.

What happens differently between between inserting a disc (and having it begin playing by reseting it's registers and starting with the FirstPlay PGC) and doing a Non-Resume Play (after hitting Stop, Stop while playing)? I know the Non-Resume Playback doesn't re-execute the FirstPlay PGC, but does it clear/reset/set any registers and which PGC does it start with? Is there any simple way to determine via the PGC command-set & registers if playback was initiated from a "Non-Resume" state versus inserting the disc? Unfortunately PgcEdit, which has taught me a lot, doesn't emulate the Stop/Stop/Non-Resume playback scenario, so I'm lost on this point... Any insights would be *greatly* appreciated...
Well, I really don't know what a "Non-Resume Play" is supposed to do. IMO, since it forgets the current playback position and restarts the playback at the beginning, it should emulate exactly the insertion of the DVD. Why do you think it doesn't re-execute the FirstPlay PGC? IMO, it is probable that all players have a different way to handle this situation. Anyway, it should be possible to verify if the FP-PGC is reexecuted by creating a simple test DVD. Unfortunately, I can't do the test myself. My Sony cannot read burned DVDs any more. :(

[blutach]

@Surgeon - I have a feeling that Titlewriter may be able to do what you want. I have not used it very much, but it's genesis was, IIRC, in entering and editing DVD text data fields.

Regards

[r0lZ]

Right, blu. With TitleWriter, you can also modify each label independently. I haven't implemented that in PgcEdit, because too few players are able to use this info. Only the global name is really useful IMO.

I have already modified the code to allow upto 126 characters (+ the final TAB and null byte = 128) in the string. The default is still 30, but this value is now configurable. I have changed my mind, and have added also the GUI to change it interactively. (See the Options -> Functions menu.)
I have also fixed the "last entry bug". (But I cannot test without an example.)

Surgeon, if you want to test the latest PgcEdit beta, send me a PM or a mail.

[Surgeon]

Yes, Fallen Angel's TitleWriter works perfectly for adding/editing the DvdText & I've used it for years. It's an excellent util, but Fallen Angel has added so many features centering on it's Dvd Menu creation & Automation sides (both features that I have yet to use) that these days it's interface almost seems, at least to me, like using Microsoft Word instead of Notepad when all you want is to create a simple text file...

Don't get me wrong -- I still use it often via it's CLI, as my current procedure is:
1) Rip a dvd into a folder that I name with what I want the Dvd's TitleText to be.
2) Clean-up the rip using r0lZ's PgcEdit (blanking leading FBI, comming-attractions and other garbage).
3) Run FixVTS on the entire dvd to help insure proper pointers & alignments.
4) Exit PgcEdit.
5) Use a little automation script I wrote (in AutoIt) to run TitleWriter via it's CLI to set the DvdTitle to it's folder name.
6) The automation script then burns the disc using VSO's Copy2Dvd CLI interface, passing the DvdTitle as the disc label.

That process works perfectly for me... It's just that I *really like* r0lZ's PgcEdit and if could add/edit the DvdTitle stuff for me as well, then I would be able to stay inside the PgcEdit environment and use it's ability to CLI the mkisofs/imgburn -- kinda like one-stop shopping!

Maybe as an alternative approach to processing all the DvdTitle stuff and moving the affected pointers within PgcEdit, r0lZ may want to consider allowing the DvdTitle & Author stuff to simply be editable text fields while inside PgcEdit, and then use TitleWriter's CLI to add/change the titles during the 'save' process if they change? -- Just a thought...

-----------

And concerning the FirstPlay PGC not being run during a "Non-Resume-Play" sequence, it's my understanding that the FirstPlay PGC was designed to check the disc's region-code, parental-settings, NTSC/PAL formats, etc. when a disc is first inserted (we all know that a lot of various checks are also made elseware these days). The original ideal behind this is that information only needed to be checked once, hence "FirstPlay".

When a player does a "Non-Resume-Play" (following a Stop/Stop sequence) it appears to me that it starts directly with Title-1's PGC. The reason I say this is because when I use VSO's ConvertXToDvd to create an episodic dvd with a simple title-selection menu, that menu is hard linked to through the FirstPlay PGC, in which case it works normally when a disc is first inserted into the player. However, the "Non-Resume-Play" sequence starts playing the 1st title (even if it was Stop/Stop'ed on a different title), with NO menu displayed. (Pressing the "Menu" buttons work fine of course.) I've tested this on several different players with the same results, so it solidifies my belief that the FirstPlay PGC is just a one-shot upon disc insertion only. Hence, my question asking if anyone knew for sure where a Non-Resume-Play wants to start, and if it sets/clears any detectable registers in the process?

-Surgeon-

PS: r0lZ, I've sent you a PM also as I'd love to test what you've come up with on the DvdTitle issues...

[blutach]

Many modern players can store current the playing position on a Stop-Stop for several DVDs (as the software players do). I know a player I just bought can do this for 6 DVDs.

I don't think FP-PGC is just a one shot as it can - and often is - called from within the DVD itself.

Regards

[bigotti5]

...it's my understanding that the FirstPlay PGC was designed to check the disc's region-code, parental-settings, NTSC/PAL formats, etc. when a disc is first inserted (we all know that a lot of various checks are also made elseware these days). The original ideal behind this is that information only needed to be checked once, hence "FirstPlay".

No - FP is not mandatory by the DVD spec

[Surgeon]

Many modern players can store current the playing position on a Stop-Stop for several DVDs (as the software players do). I know a player I just bought can do this for 6 DVDs.

Really? Are you sure your talking about a Stop-Stop, (and not a single Stop, which is resumable) because every player I've ever seen, software or no, usually follows a single Stop with a message like "Playback will resume from the current position; to restart playback from the beginning press Stop again", so what would be the point in saving any pointers if it's going to playback from the beginning anyway?

I don't think FP-PGC is just a one shot as it can - and often is - called from within the DVD itself..

I realize that the FirstPlay PGC can be called from another program chain; what I'm saying is that it's a one-shot from the player's internal functionality -- kinda like a computer's autoexec.bat, which I would also have to consider to be a one-shot, even though it could be executed directly more than once if desired...

-Surgeon-

[Surgeon]

No - FP is not mandatory by the DVD spec

I never said it was mandatory (even though I think it's a required field inside the VIDEO_TS.IFO file, even if it contains no code). All I said was, like autoexec.bat, it's the first thing a player's internal code looks for to execute when a disc is inserted, but it isn't automatically executed again by the player's internal code during a "Non-Resume-Play" operation. (The major question still being: does anyone have any knowledge on exactly what does happen during a "Non-Resume-Play" operation?)

-Surgeon-

[bigotti5]

..does anyone have any knowledge on exactly what does happen during a "Non-Resume-Play" operation

It depends on the player - I dont believe its specified

[Surgeon]

It depends on the player - I dont believe its specified

That's really more than just a little hard to believe...

I mean, a lot of big-$$$ engineers from Philips, Sony, Pioneer, etc. sat around a table for a long period of time hashing out the "official dvd specifications" so they could have a standard; everyone decided that Stop-Stop-Play would perform a "Non-Resume-Playback" function; yet went home early and just left it in "up-in-the-air" as to exactly how that would happen...

If that were truely the case that's not exactly what I would call a standard, would you??? :confused: :confused: :confused:

-Surgeon-

[bigotti5]

That's really more than just a little hard to believe...

Read John Taylors book DVDDemystfied about the "standards"

Some Pioneer remote controls require two keypresses to get to the title menu—the “Title” key
and then the “Menu” key—unless the disc is stopped, in which case only the “Title” key is needed.
The “Menu” key works with a single press, except that when the disc is stopped it goes to a
player-generated menu that is neither the title menu nor the root menu.
Unfortunately, in typical style of the DVD specification, the “clarification” is almost impenetrable.
...

[blutach]

Almost everyone agrees that, in many instances, the specs are there in name only surgeon. They sat around that table and made these specs and many times they can be breached/ignored. 2COOL's very interesting work with dummy PGCs in the title domain is but one example.

Don't place too much trust in the fact that these highly paid folks made the specs. In practical terms, they are fuzzy, from my observations.

Regards

[r0lZ]

My Sony has also a Non-Resume-Play function when you press stop twice. But it restarts the DVD from the beginning, and it plays the first logos and than goes to the main menu, exactly like when the DVD is inserted. I'm not sure the FP-PGC is executed, though. But IMO, clearing all registers and jumping to the FP-PGC is the safer way to restart the DVD. Jumping to the main movie (or title 1?) even if it was not playing when the user pressed stop twice is probably very hazardous, as the GPRMs will not be properly initialized for the subsequent navigation.

My cheap KISS player has no Non-Resume-Play function at all.
If Non-Resume-Play is in the standard, then the standard is somewhat flexible!

BTW, I can confirm that the First-Play-PGC is not mandatory. If "FP-PGC start byte" is 0 in VMGM_MAT, the FP-PGC is not defined, and the navigation begins at Title 1.
If it is defined, however, it must have at least a jump in the pre or post commands.
Note: PgcEdit creates the FP-PGC anyway if it is not present when the DVD is opened, and adds a JumpTT to Title 1.

[bigotti5]

Note: PgcEdit creates the FP-PGC anyway if it is not present when the DVD is opened, and adds a JumpSS to Title 1.

JumpTT ;)

[Surgeon]

Strange... But, hey... I defer to you guys & gals as the experts!

After all, that's why I decided to stop lurking and post my query here to start with... I was just kinda assuming that there was a standard procedure for the Non-Resume-Play function, and that it was just occasionally bastardized by a few players here and there...

I guess I should have realized that in our screwed-up world that standard is just an imaginary term... :o

C'est la vie...

-Surgeon-

[r0lZ]

Maybe the bastardization is the standard! :D
There are several other points in the standard that are also very differently implemented in various players. The content of SPRM 7 is a good example. More than 50% of the players use SPRM 7 to store the PG number instead of the PTT number!

Anyway, you might be right. If I can find a RW that is still supported by my Sony, I'll do a test DVD to verify what happens exactly when this Non-Resume-Play function is called...

[ron spencer]

with V7.3 work properly with V2.0.0.0 if ImgBurn?

[Surgeon]

r0lZ,

I don't know how concerned you are with your Sony player not playing back the discs you burn, but it sounds to me that a little "tweaking" of the various focus & tracking settings might resolve the problem...

Most late-model Sony players have a "Service Menu" and all their settings are controlled via various software registers. Only thing is, making the adjustments are more than a bit tricky and require a *lot* of small trial & error changes, as there's not any one particular setting that simply improves it's ability to read discs. This is also further compounded by the fact that there are multiple settings for different disc types, like CD, DVD Single-Layer, DVD Dual-Layer(Layer0), DVD Dual-Layer(Layer1), etc. The service menu also has an "Automatic-Calibration" feature for each of the types, but it really needs to be used with a set of Certified Calibration Discs, which I don't have and are big-$$$'s. Some people have reported success performing the "Automatic Calibration" with "standard" commercial discs, but I would recommend using new, high quality discs if you go this route...

If you're interested in playing around with the settings, let me know your unit's model# & I'll see if I can locate the remote-control sequence to get you into the service menu. (Commonly, starting with the unit OFF, it's "Top Menu", "Clear", "PowerON".) By "playing" with the various settings, like TRK Offset, Focus Gain, Focus Offset, etc. you can definitely improve any given disc's readability.

But you must also be aware that "tweaking" the settings for a particular disc (like, say, a Ritek DVD+R written with a NEC writer) *could* also negatively impact how it reads other, ie: commercial, discs. (The overall goal is to find a happy medium that reads *all* discs.)

If it sounds like something you want to explore, let me know & I'll be happy to assist you in any way I can...

-Surgeon-

[Surgeon]

OK... Since I've now been enlightened as to "there is no spoon", and also knowing that you guys & gals have slung a lot more PGC code than I have, let me try to garner your insights into the underlying programming quandary that prompted my original query about the "Non-Resume-Play" functionality to start with...

Given the following simple structure:

VMG, First-Play PGC
** pre commands:
1 (SetGPRMMD) Set gprm(0) in register mode =(mov) 0
2 (SetGPRMMD) Set gprm(1) in register mode =(mov) 1
3 (SetGPRMMD) Set gprm(2) in register mode =(mov) 0
4 (JumpSS) Jump to VMGM PGC 1

VMGM_1 [dummy] TitleM
** pre commands:
1 if ( gprm(0) != 1 ) then { Goto line 3 }
2 (SetHL_BTN) Set Highlighted Button =(mov) 2048 (button 2) ; LinkPGCN PGC 2
3 (SetHL_BTN) Set Highlighted Button =(mov) 1024 (button 1) ; LinkPGCN PGC 2

VMGM_2 [0:10] 2b
[Menu_Button1] ==> [JumpSS] Jump to VGM PGC 3
[Menu_Button2] ==> [JumpSS] Jump to VGM PGC 4

VMGM_3 [dummy]
** pre commands:
1 Set gprm(0) =(mov) 1
2 (JumpTT) Jump to Title 1

VMGM_4 [dummy]
** pre commands:
1 Set gprm(0) =(mov) 2
2 (JumpTT) Jump to Title 2

VMGM_5 [dummy]
** pre commands:
1 if ( gprm(1) >= 1 ) then { LinkPGCN PGC 6 }
2 LinkPGCN PGC 1

VMGM_6 [dummy]
** pre commands:
1 if ( gprm(0) == 1 ) then { LinkPGCN PGC 4 }
2 if ( gprm(2) >= 1 ) then { LinkPGCN PGC 3 }
3 (SetHL_BTN) Set Highlighted Button =(mov) 1024 (button 1) ; LinkPGCN PGC 2


VTSM_1_1 [dummy] RootM
** pre commands:
1 (JumpSS) Jump to VMGM PGC 1

VTST_1_1 TTN1 Title1
** pre commands:
1 Set gprm(3) =(mov) 1
2 Set gprm(0) =(mov) sprm(4:Title number in volume)
** post commands:
1 Set gprm(3) =(mov) 0
2 (CallSS) Call the VMGM PGC 6, resume cell 1


VTSM_2_1 [dummy] RootM
** pre commands:
1 (JumpSS) Jump to VMGM PGC 1

VTST_2_1 TTN1 Title2
** pre commands:
1 Set gprm(3) =(mov) 1
2 Set gprm(0) =(mov) sprm(4:Title number in volume)
** post commands:
1 Set gprm(3) =(mov) 0
2 (CallSS) Call the VMGM PGC 6, resume cell 1

That's about one of the simplest dvd layouts with a menu & auto-chaining to the next episode that I've seen. (The entire disc can easily be fully created by using the demo version of ConvertXToDvd (http://www.vso-software.fr/products/convert_x_to_dvd/) and dragging a couple of small video files (avi, divx, etc.) into the program, and setting the Auto-Start Playback & Loop-Playback features to OFF.)

----------

Now to the problem I'm seeking help on:

Given that the Non-Resume-Play (Stop/Stop/Play) on Sony's DVD players skips the FirstPlay PGC and goes directly to playing Title-1, what changes could I make in the PGC's code to accomplish:

1) Displaying the Menu when a disc is 1st inserted (it already does this now via the FirstPlay PGC)
2) Displaying the Menu from a Non-Resume-Play (Stop/Stop/Play)
3) *NOT* displaying the Menu if I jump directly to Title-1 via Sony's "Direct_Play_Disc/Title/Chapter" feature via my HTPC's serial control cmd.
Most commercial discs accomplish this criteria perfectly, but they are soooo inundated with tons of commands, most of which I'm sure are not needed in such a simple layout as the one above.

Can anyone point me in the right direction as to what changes would need to be made to accomplish the above goals? (Even if there isn't a spoon, I *still* want to bend it!)

Thanks so much!
-Surgeon-

[r0lZ]

Thanks for the suggestion.

I have a DVP-S725D. It is very old, but has many features not found anymore on the current players. I like it also because it is very standard compliant, even if it has some bugs and limitation. Unfortunately, it has never read perfectly the burned DVDs, especially the RWs.

I know how to access the service menu, but I'm a bit threatened by the options. I've noticed the automatic calibration menu, but I have not tried it yet.
Which DVD should I use first to try this function? A good commercial single layer?

[Surgeon]

I would recommend purchasing a new release, as soon as it first comes out, from a quality disc manufacturer, like Sony. A new release should theoretically be pressed with new dies, hence somewhat a more accurate disc.

Problem is, you might have to look hard to find a single-layer release, which sounds like what you need to calibrate...

Maybe a short, featureless, animated release???

-Surgeon-