PgcEdit: Delete Uncalled PGC's --> sprm(5)

[Calimari]

When I try to delete uncalled PGC's, PgcEdit warnes me that sprm(5) is used several times. Here's an example:

5 Set gprm(0) =(mov) sprm(5:Title number in VTS)
6 Set gprm(0) *=(mul) 256
7 Set gprm(0) |=(or) sprm(7:Chapter number (or PGN))
8 NOP
9 NOP
10 NOP
11 NOP
12 NOP
13 NOP
14 NOP
15 NOP
16 NOP
17 if ( gprm(0) >= 25957 ) then { Goto line 21 }
18 LinkPGCN PGC 43
19 NOP
20 NOP
21 NOP
22 RSM

I'm getting this far: The value of sprm(5) is stored in gprm(0). I suppose sprm(5) is the number of the title that was playing. Then this number is multiplied by 256 (why?) The OR-function, I'm not sure how to interprete that. Title number or chapter number. Then there's a check to see if the title number is 25957 or higher (25957/256 = 100 titles). If it's higher, RSM (resume) is called. If it's lower, PGC43 is called (leading to menu language setting).

I suppose PgcEdit gives a warning because some titles will get another number after the deletion of several uncalled titles.
Can someone give his vision on the code above? Thanks in advance.

[blutach]

It's a way of storing the title and chapter number for later on. Whether it is ever executed later is another matter.

So, if you are playing title 4, chapter 7, it will store 1031 (the OR has an additive effect since the MUL has bitwise shifted the title number left 8 bits). Later on, the DVD might navigate to the chapter menu and automatically highlight chapter 7 (this is quite snazzy actually when you see DVDs do this).

You just have to trace thru and see if it uses this info at all. Many times the gprm will be overwritten quickly, so you can ignore the warning about sprm 5.

Regards

[Calimari]

Blutach, I knew you were the right man for answering this.

What you say sounds logical, I see it clear now. All those sprm(5) commands are in the root menu's of the VTS'. They are indeed used to remember title/chapter when playback is interrupted by the user to call a language/subtitle menu, as all those root menu's are only callable by the remote control. I checked in MPC and everything seems to work fine after I deleted all uncalled PGC's (90!)
I guess it doesn't matter which number a title has when it's interrupted and recalled again.

Thanks for your quick responding!

[blutach]

I guess it doesn't matter which number a title has when it's interrupted and recalled again.

Hmmm. I wouldn't go that far. If TTN 4 is playing and this somehow needs to be remembered for the nav to work, then you may need to change things a bit. As I said before, when you encounter this, check whether the gprm (in this case 0) is actually used or quickly overwritten. Most times you will be OK unless TTNs are deleted by the function, in which case, you need to be especially careful.

Of course, a regular RSM (Resume), called with the menu button or usually the Play Movie button won't matter as this info is stored in the player.

Regards

[Calimari]

Of course, a regular RSM (Resume), called with the menu button or usually the Play Movie button won't matter as this info is stored in the player.
Regards

Yes, every use of sprm(5) is followed by RSM. That's why I thought that the title number didn't matter. That was an easy check. Checking and following gprm(0) is another thing. It's used 1090 times! The navigation is very difficult, almost impossible to follow manually. Additional problem is, the menu's are available in 3 languages, but all presented as LU(en). They're just different PGC's. It's like a spider web, as you can see in the attached file with the DVD commands.

I'll give it a shot, then I'll check in MPC to see if the navigation works like it should. In case of any problems, I'll re-rip and leave the uncalled PGC's in it. The original is already smaller then 4.3GB, so space doesn't matter.

[blutach]

Sadly, the use of LUs has almost become extinct. This is poor authoring practice IMO.

The trick in your case will be to determine whether:

(a) gprm(0) is quickly overwritten before anything really happens (in other words, the commands in the root menu become meaningless because gprm(0) is overwritten before a branch in the navigation dependent on this gprm occurs) OR

(b) whether any TTN is being deleted by PgcEdit's delete routine.

If (a) = yes then irrespective of (b), you can proceed with confidence.
If (b) = no then irrespective of (a), you can proceed with confidence.

PgcEdit's trace function is useful to determine (a).

Regards

[Calimari]

Thanks for the advice.
I'll spend some more time on it tomorrow and investigate that. I have to re-rip to start all over.

Oh, here's the attachment I forgot in my earlier post

[r0lZ]

I have seen recently exactly the same strange authoring in another DVD. The same method is used in all VTS, and IMO, it's totally useless. I don't understand why they do that, as it is illegal to have more than 99 TTNs in a domain. Therefore, the RSM command cannot be executed. As far as I know, the content of gprm(0) is not directly reused elsewhere, and you can safely delete uncalled PGCs. Anyway, that's what I did, and I haven't noticed nav problems so far.

Unfortunately, I can't analyse the DVD to discover that those commands are useless, and suppress the warning, as this would require a full trace, simulating all possible navigation choices.

As blu said, if you want to be sure, you can do it manually. You should trace and see if gprm(0) can be directly used in another PGC (in your example in PGC 43 and subsequent PGCs), before it is reinitialized with another value, but I'm almost sure it's not the case.

Also, you can use the Find Uncalled PGCs function before Delete Uncalled PGCs (or abort Delete at the warning), and see if a TTN will be deleted somewhere. If, in the same VTS, the deleted TTN is followed by another TTN that will be kept, it might be unsafe to use Delete Uncalled PGCs. It is theoretically possible to check that in PgcEdit, and suppress the warnings if no TTNs have to be renumbered, but I cannot do that easily at the beginning of the function, and issuing the warning when the DVD has already been modified by the function is dangerous and confusing.

[Calimari]

Blutach & rOLZ.

A manual trace of this movie is a very hard job. A lot of if .... then LinkPGCN... instructions make it look like a real labyrinth, like a spider web. It's almost impossible to hold track without writing things down.
A good movie would pull me over the line, but this one is a Steven Seagal...

Also, you can use the Find Uncalled PGCs function before Delete Uncalled PGCs (or abort Delete at the warning), and see if a TTN will be deleted somewhere. If, in the same VTS, the deleted TTN is followed by another TTN that will be kept, it might be unsafe to use Delete Uncalled PGCs.

Good hint. Actually, there's one TTN marked as uncalled, and it's in an entirely uncalled VTS. So I guess it's safe to go on and delete all uncalled PGC's. I'll go for it and punish one of my children by forcing him to watch this movie to test it

Thank you both,
Greets.

[blutach]

Attack Force? LMAO

Regards

[Calimari]

Attack Force? LMAO

Regards

OK, OK, I confess

[Calimari]

Another problem after deleting uncalled PGC's:
After deleting them, a numer of VTST's were left without VTSM, as those were deleted. After cleaning/stripping the movie with VobBlanker, each VTST seems to have its own VTSM again, as VobBlanker created them. The VTSM's have no pre/postcommands. Checking for uncalled PGC's marks these VTSM's as uncalled again. Should I delete them again or is there a good reason VobBlanker created these?

[blutach]

You have smart gaps turned on in VobBlanker. It's a good idea to run that as a final thing before burning.

Regards

[Calimari]

Right, I have that option turned on. I forgot it creates dummy menu files.
Thanks.

Now that we're speaking about this, is it still usefull to turn the 32k gap option on in PgcEdit after VobBlanker created a physical 'fill-up'?

[blutach]

It is meaningless - there are at least 32k gaps already. Does not hurt.

Regards