Fix those PGCs now!

[kikatu]

... Well, rOLZ I will leave you with something you can understand:

http://img179.imageshack.us/img179/8567/51274696cv9.png
http://img295.imageshack.us/img295/2610/47381451jx4.png

Picture #1 is showed after uncalled PGCs were deleted. #2 are the search results of what can be problematic, but I do not understand this commands. A trace was done on the whole navigation, no issues.

:thanks: again rOLZ. :)

[blutach]

Check it out on a trace and make sure the trace still works. If a title has been removed from a VTS and gprm(0) needs to hold that number for something to work properly, then you may need to reprogram those commands with a hard coded number. Many times, however, you need do nothing, especially if a title has not been removed.

Regards

[r0lZ]

When using Delete Uncalled PGCs (and also Delete Uncalled Titlesets) most of the time PgcEdit needs to remove a title in the middle of the list or a VTS in the middle of the DVD, or (for Delete Uncalled PGCs only) a TTN in the middle of a title domain or a PGC in the middle of a domain. Therefore, the following items are moved up in the list, and their numbers are decreased.
PgcEdit fixes all direct references to the moved items. For example, if TTN 3 of a VTS is uncalled, TTN 4 will become TTN 3, and all JumpVTS_TT to TTN 4 are remapped to jump to TTN 3 after the change. That's fully automatic.

However, in some DVDs, SPRM 4 (Title#), 5 (TTN#), 6 or 10 (PGC#) are used in the navigation. Typically, the SPRM value is copied in a GPRM, and then that GPRM is compared with one or several constant values to decide where to jump. Since PgcEdit cannot guess the value of the SPRM, it cannot fix the value used in the comparison that follow the line where the SPRM is used.

For example, still assuming that TTN 3 has been removed, and assuming that the original TTN 4 (now TTN 3) has been played just before the following code is executed, the navigation will be wrong:
[61 00 00 0F 00 85 00 00] 1 Set gprm(15) =(mov) sprm(5:Title number in VTS)
[00 A1 00 0F 00 04 00 0C] 2 if ( gprm(15) == 4 ) then { Goto line 12 }

In the original DVD, sprm(5) contains 4 after the execution of TTN 4. Therefore, the comparison of line 2 is true, and the nav continues at line 12. After Delete Uncalled, sprm(5) and consecutively gprm(15) contain now the value 3, as TTN 3 has just been played instead of TTN 4. Therefore, the condition of line 2 is false, and the nav continues with the following line. There is something wrong!

This indirect type of navigation commands is almost impossible to fix automatically. Suppose for example that PgcEdit is smart enough to analyse the commands, and to figure out that gprm(15) contains the TTN number when line 2 is executed. You think probably that it could therefore modify the second line to:[61 00 00 0F 00 85 00 00] 1 Set gprm(15) =(mov) sprm(5:Title number in VTS)
[00 A1 00 0F 00 03 00 0C] 2 if ( gprm(15) == 3 ) then { Goto line 12 }
However, unfortunately, that's not true. For example, if TTN 3 of another VTS has been played before, the goto command must NOT be modified. Only an human, with the help of the trace, can figure out when it is necessary to modify the commands, and how. Hence the warning.

That sounds complex, and it's complex! ;)

However, don't worry too much. If the trace shows no error, then you can probably assume that the nav is safe, as blu said.

Also, I have noticed that a specific authoring program (I don't know which one) seems to use SPRM(5) in all entry menus of all VTSs (Root and Angle menus in your example.) I still doesn't understand why, as it's probably useless. Indeed, the commands following the Set command compares the GPRM (here gprm(0)) with an high value that sprm(5) CANNOT contains, as usually this value is greater than the highest TTN value in the DVD. The conditions are therefore never true, including after Delete Uncalled. For example:
[61 00 00 0F 00 85 00 00] 1 Set gprm(15) =(mov) sprm(5:Title number in VTS)
[00 A1 00 0F 00 63 00 0C] 2 if ( gprm(15) == 99 ) then { Goto line 12 } If all TTN numbers in the original DVD are less than 99, the jump to line 12 will never occur, and you are on the safe side.

I can't be sure that it's the case here, as I don't have enough info, but your 2nd screenshot looks like the one I have analysed. Take care anyway, and when you see this kind of warning, verify always the navigation carefully. For example, in this case, try to play a TTN that follows a deleted TTN, and call the root menu with the remote. If everything works fine, that should be OK.

[Calimari]

For example, if TTN 3 of another VTS has been played before, the goto command must NOT be modified.

Isn't SPRM(5) used for holding the titlenumber of the current VTS? I always thought SPRM(4) was used for holding information about title numbers in general, including those in other VTS's.

[blutach]

@calimari

I think what r0lZ is saying is suppose you have jumped to say the menu domain of another VTS and that tests SPRM 5 (which will still hold the last TTN in the previous VTS).

Regards

[r0lZ]

Exactly, blu!
As far as I know, SPRM(5) contains the "Title in VTS" (VTS_TTN) number of the last accessed title, even in another VTS. It can also be used in the VMGM or the FP-PGC.
Therefore, in a DVD with several VTS, we cannot assume that its value changes if we remap the TTNs of a specific VTS.

[Calimari]

I see. So this means, let's suppose that TTN 2 of VTS 6 is Title 9 of the dvd, that SPRM(5) will hold the value "2" and SPRM(4) will hold value "9", after the title has played. Is that correct?

I always had the impression that using SPRM(4) is the logical way to test which title has played in another VTS. But, SPRM(4) would hold a unique value (eg. Title 9) while SPRM(5) can be used to test which VTS_TTN (not unique) has just played, no matter in which VTS. So it could be TTN 2 of VTS 6 but also TTN 2 of VTS 7.

This means, BEFORE deleting uncalled PGC's or VTS's in PgcEdit, the user has to check where (in what VTS's) the navigation has been before it reaches the SPRM(5) command. Next to the warning window that PgcEdit pops up, the 'Go to calling command' and 'Jumps from VMG to current VTS' functions are very useful here.
If the nav has passed through VTS's where one or more TTN's will get deleted, the SPRM(5) command will give a wrong value (as rOLZ already explained it an excellent example).
Also, it's very important to check where the navigation goes next, as the value of SPRM(5) can be used again in the next VTS, for example: to test which preview has just played and set the audio or subtitle language of the main movie according to that info.
It's not easy to do this when the navigation is complicated, as the user can't just follow one trace and edit the commands.
DVD navigation is like a spaghetti, all "wires" are connected in one or another way. It's important to keep an eye all the time on where the navigation could come from, and where it could go to.
So, when PgcEdit warns you about SPRM 4,5,6 or 10, it's better to abort the deleting and use "Find uncalled PGC's" first to edit the navigation.

[blutach]

I always use Find Uncalled PGCs first. And do a check to see if the relevant SPRMs mean anything.

If a TTN or title is not being deleted, it is usually no big deal. Even if it is, it is because the PGC is uncalled in the first place and is usually meaningless. But do test for calls, especially with comparisons and ensure your trace still works.

Regards

[r0lZ]

I see. So this means, let's suppose that TTN 2 of VTS 6 is Title 9 of the dvd, that SPRM(5) will hold the value "2" and SPRM(4) will hold value "9", after the title has played. Is that correct?Yes.

I always had the impression that using SPRM(4) is the logical way to test which title has played in another VTS. But, SPRM(4) would hold a unique value (eg. Title 9) while SPRM(5) can be used to test which VTS_TTN (not unique) has just played, no matter in which VTS. So it could be TTN 2 of VTS 6 but also TTN 2 of VTS 7.

This means, BEFORE deleting uncalled PGC's or VTS's in PgcEdit, the user has to check where (in what VTS's) the navigation has been before it reaches the SPRM(5) command. Next to the warning window that PgcEdit pops up, the 'Go to calling command' and 'Jumps from VMG to current VTS' functions are very useful here.
If the nav has passed through VTS's where one or more TTN's will get deleted, the SPRM(5) command will give a wrong value (as rOLZ already explained it an excellent example).
Also, it's very important to check where the navigation goes next, as the value of SPRM(5) can be used again in the next VTS, for example: to test which preview has just played and set the audio or subtitle language of the main movie according to that info.
It's not easy to do this when the navigation is complicated, as the user can't just follow one trace and edit the commands.
DVD navigation is like a spaghetti, all "wires" are connected in one or another way. It's important to keep an eye all the time on where the navigation could come from, and where it could go to.
So, when PgcEdit warns you about SPRM 4,5,6 or 10, it's better to abort the deleting and use "Find uncalled PGC's" first to edit the navigation.I agree. However, most of the time, it is relatively easy to figure out how the SPRM(5) is used, and why. Usually, it is used in the root menu of the main titleset, for example to highlight the next button of a bonus menu.

Also, note that I've already noticed some discrepancies in the value hold by SPRM(4). Seems that, again, we cannot trust the players, and that this SPRM is not reliable. It can, for example, still hold 0 after the playback of a title, or hold 1 when the DVD is inserted, in the FP-PGC. It's probably why it is used very rarely in commercial DVDs.

[bigotti5]

AFAIK SPRM4,5,6 are not updated independently.
E.g if SPRM5 is updated, SPRM4 and SPRM6 will also be updated.
SPRM4,5 cannot hold 0, only 1-99 are allowed, default is 1.
SPRM6 can hold 1-32767, default is undefined.

[r0lZ]

I agree. However, that's theory.

I can confirm that SPRM 4 can, although it should not, hold 0. I've verified that myself with a cheap little player. It's certainly a bug or an omission, but as I said, we can't trust the SPRMs!

[Calimari]

SPRM4,5 cannot hold 0, only 1-99 are allowed, default is 1.


@rOLZ:

I just checked this with the (JumpSS) Jump to VTSM X, Root menu (TTN X) command. PgcEdit uses "1" as the default value for TTN (SPRM(5)). So far so good. But, the user can fill in "0" as the TTN number without any problem. This is an illegal value for SPRM(5). However, PgcEdit doesn't seem to test this value so it doesn't complain on a "0". The navigation works fine in trace mode. But Media Player Classic hangs on this. The navigation just stops after executing that JumpSS command.
(I didn't test this on a standalone player).

Maybe a suggestion for the next release? There might be other fools like me who do fill in a "0" :) (just to test!).

Oh, another thing. PgcEdit's command editor displays the text "and set sprm(5) to TTN *textwindow*" Also, in the main window, the name TTN is used for the titlenumber in a VTS. Anyone who's not familiar with sprm's (again, like me earlier in this thread :)) and starts googling for TTN and sprm's might end up here (http://dvd.sourceforge.net/dvdinfo/sprm.html). This might be misleading as that table describes SPRM(4) as TTN, while SPRM(5) is VTS_TTN. So, in PgcEdit, the value of "Title X" is stored in TTN, and the value of "TTN X" is stored in VTS_TTN.
Now, I don't know how official the naming scheme of that table is, and I sure don't wanna niggle. But I thought this could be useful to others who read this thread.

[bigotti5]

0 as a value for TTN in a JumpSS command is not illegal, if JumpSS remains in same VTSM domain 0 is the command to not set a new value in SPRM5.

AFAIK you should avoid JumpSS to jump inside a domain, use LinkPGCN instead.

[Calimari]

I see. Well, actually I used the JumpSS command in a VMGM to jump to a VTSM (rootmenu). TTN seems to be used there to set SPRM(5). In that case, 0 is not allowed.

Anyway, thanks for this useful tip.

[bigotti5]

TTN seems to be used there to set SPRM(5). In that case, 0 is not allowed.

I have to correct my statement above....(VTS)TTN in JumpSS can never be 0 but VTS value has to be 0 if JumpSS is used in a VTSM domain

[r0lZ]

Oh, another thing. PgcEdit's command editor displays the text "and set sprm(5) to TTN *textwindow*" Also, in the main window, the name TTN is used for the titlenumber in a VTS. Anyone who's not familiar with sprm's (again, like me earlier in this thread :)) and starts googling for TTN and sprm's might end up here (http://dvd.sourceforge.net/dvdinfo/sprm.html). This might be misleading as that table describes SPRM(4) as TTN, while SPRM(5) is VTS_TTN. So, in PgcEdit, the value of "Title X" is stored in TTN, and the value of "TTN X" is stored in VTS_TTN.
Now, I don't know how official the naming scheme of that table is, and I sure don't wanna niggle. But I thought this could be useful to others who read this thread.Well, PgcEdit uses "Title" when it refers to a global title, defined in VMG_TT_SRPT, and uses TTN when it refers to a title within a VTS (VTS_TTN).
I'm not sure it's a good terminology, but it is coherent, at least within PgcEdit. IfoEdit, for example, uses Title for the global titles and for the VTS_TTNs! Very confusing.
I can't change that easily, but maybe I'll modify that for the next major release, later...

[r0lZ]

(VTS)TTN in JumpSS can never be 0 but VTS value has to be 0 if JumpSS is used in a VTSM domain
Right.

However, I'm not sure if TTN 0 is illegal in a JumpSS command. It could mean "last visited VTS_TTN", just like VTS 0 means last visited VTS (or, of course, current VTS). In other words, SPRM 5 should not be modified when the TTN parameter is 0. Bigotti, can you confirm that TTN 0 is really illegal? What is your source of information?

Anyway, in the command editor, the valid range displayed in the GUI is 1-99. But it is impossible to prevent the user from entering a 0 in the numeric fields in PgcEdit, as he needs to type 0 to be able to enter an hexadecimal number, beginning with "0x". Although not very useful, it is also possible to enter octal numbers, beginning with 0 (and also language codes, beginning with the apostrophe, such as "'en".)
Therefore, the question is: should I highlight the command in pink when the TTN number is 0?

[EDIT:] I did it.

[bigotti5]

I'm not sure if TTN 0 is illegal in a JumpSS command. It could mean "last visited VTS_TTN", just like VTS 0 means last visited VTS (or, of course, current VTS).

I do not think so
VTS value indicates a target for the jump (if 0 no jump necessary), TTN value just sets SPRM5 (in every case).
Verifiers are complaining about 0.

[r0lZ]

Yes, I suppose so. This is why I have modified the code. TTN 0 is now considered as an error.

[spyhawk]

It is reported that having TTN 0 on JumpSS command that certain standalones, particularly Sony, are having trouble playing. Adding this check is a good idea. Here's the discussion (http://www.cdr-zone.com/forum/about7245.html&highlight=title).

[r0lZ]

It is reported that having TTN 0 on JumpSS command that certain standalones, particularly Sony, are having trouble playing. Adding this check is a good idea. Here's the discussion (http://www.cdr-zone.com/forum/about7245.html&highlight=title).

Hum, I see, in the first post:I then tried an idea from one of the other posts on this forum: I added a new PGC in the VMG and I changed the button command to jump to this PGC. I added a pre-command to the PGC which said "jump VTS root menu (titleset 11)".I suppose that the first attempt of zakman was to jump directly from the main root menu to the imported root menu.

Although in the second post, toaddub says:... it is valid to jump from VTSM to VTSMthat's not true. It is never possible to jump from a titleset to another titleset. I guess the problem with the Sony player is that it is standard compliant!
(Also, in the same post, toaddub makes another error, as there is no resume cell parameter in a JumpSS command, but that's not the point.) So, this thread is confusing, as almost everything is wrong.

However, I agree that setting the TTN parameter to 0 can cause some player to crash, if it is true that this value is illegal. I have never used TTN 0 myself, so I can't be sure, but anyway it is more cautious to use 1, or any existing TTN number.

[Calimari]

However, I agree that setting the TTN parameter to 0 can cause some player to crash, if it is true that this value is illegal. I have never used TTN 0 myself, so I can't be sure, but anyway it is more cautious to use 1, or any existing TTN number.

A software player like MPC sure didn't like it. So I believe this is a good reason to assume that some hardware players will choke on it too.
Normally, when creating a jump from the VMGM to a VTST, PgcEdit fills in a correct default value "1" in the TTN field. However, someone who wants to do some experiments with the SPRM's, might fill in something else. The catch is, after playing around and wanting to restore the default situation, he might fill in "0", not knowing anymore that the default value was "1".
After all, in other fields, "0" is used as a default value (eg the menu editor, where it tells the player to use the SPRM's to highlight a button). This sounds obvious to experienced users, but might lead to confusion for someone who is new to dvd authoring.
Therefore, I believe it's a good thing you highlighted the TTN input field in pink when "0" is inserted. The user is still free to choose a value, but at least he's warned that he might do something wrong.

[r0lZ]

I agree. It's why I did it! :)

[spyhawk]

It is never possible to jump from a titleset to another titleset.Yes, it's possible. I have verified with toaddub's statement. I just made a test disc to jump from VTSM to VTSM where the menu belongs to a menu category (Root, Audio, Chapter, etc.) and all of my software players (WinDVD, PowerDVD, Showtime, MPC) and 5 standalones (none of them Sony), and they ALL jump perfectly. DvdReMake Pro does not flag this command as error. I don't know what the official spec says but at least this works, don't have to go through VMGM anymore. However, to be on the safe side, it's better to go through VMGM.

(Also, in the same post, toaddub makes another error, as there is no resume cell parameter in a JumpSS command, but that's not the point.)He was mentioning the resume cell parameter in a CallSS command, r0lZ. ;)

[r0lZ]

I agree that it is easy for a software player, and even for most recent standalone players, to jump from titleset to titleset, but that's not the point. This jump is illegal, and prohibited. You have to bounce via the VMGM. It's the rule.

In the other thread, they discuss the way to jump from a VTSM menu to another VTSM menu. No room for CallSS commands in this scenario. Anyway, it's not important.

[kikatu]

Hi:

bluetach, tracing the navs menus seems OK. rOLZ (deja-vu), no worries, it worked fine on the players. This time might not be problematic, but the knowledge here might come into play. :thanks: for the responds guys, & extended input.

[mikenadia]

[20 24 00 0A 00 84 00 21] 15 if ( gprm(10) == sprm(4:Title number in volume) ) then { LinkPGCN PGC 33 }
[71 00 00 0A 00 0B 00 00] 16 Set gprm(10) =(mov) 11
[20 24 00 0A 00 84 00 21] 17 if ( gprm(10) == sprm(4:Title number in volume) ) then { LinkPGCN PGC 33 }
[20 04 00 00 00 00 00 23] 18 LinkPGCN PGC 35
********** post commands:
Is it safe to assume I can just delete line 17 or NOP to solve the sprm 4 warning .
Thx

P.S. Blutach, when you say to check that my trace is still working, how do you go about it?
My PGC is called by 20 commands. Do I have to start from a menu and trace all combinations?
Thx

[blutach]

Is it safe to assume I can just delete line 17 or NOP to solve the sprm 4 warning .
1. Only if you are sure those titles are never called. If you have renumbered titles (due to deleting uncalled PGCs, some of which were titles, or otherwise), then these commands could be incorrect. Cearly, if the title numbers have been changed, the comparison to gprm(10) needs to change, too. When deleting uncalled PGCs or remapping PGCs, PgcEdit always flags if sprm(4), (5) or (6) comparisons are in the DVD so you can examine them first.

2. What I mean by ensuring your trace still works, is to go thru the menus and make sure the trace still behaves like it did before deleting PGCs.

Quite frankly, if a PGC is called by 20 commands, I'd leave it in.

Regards

[r0lZ]

I agree. It is specially dangerous to delete some title PGCs or to remap them when SPRM 4 is used in some VM commands, unless you know exactly what you you are doing, and you fix them manually.
Unfortunately, it is impossible for us to know if you can do it only by looking at the 4 commands in your post. And deleting a command to hide the warning can have disastrous results! So, I suggest, in this precise case, to kill and blank the PGCs you don't need, but do not delete them completely, and leave the commands unchanged.

[mikenadia]

From reading the thread, it is my understanding that if I have only sprm(4 or 5) - no sprm(6 or 10) - I can safely delete (without modifying the commands) all uncalled PGC that do not " force" a Tiltle Remap. Am I right or wrong?

Thanks in advance.

[r0lZ]

Yes, SPRM 4 and 5 are the two different title numbers (global Title and local TTN to the VTS). If you delete a title, all subsequent titles will be renumbered, and the navigation commands using SPRM 4 or 5 indirectly could not work any more. However, even if no titles are renumbered but the last title(s) is (are) deleted, the navigation could also be broken, if SPRM 4 or 5 is used to identify a deleted title. So, in this case, it is safe to remap the menu domains only. (Of course, there are many cases where remapping the title domains is safe, but you have to analyze the whole DVD to be sure.)