PgcEdit v9.2 released! (16 February 2009)

[mpucoder]

Nice trick. I'm not sure it is possible to know the DOS pathname from PgcEdit, but I will have a look...

Try GetShortPathName. I'm not familiar with tcl/tk, but I did find that function used to initialize tcl/tk over at scilab (http://www.scilab.org/developers/doxygen_scilab/d2/da4/InitTclTk_8c.html), so it would be weird to not make it available.

[r0lZ]

Thanks, mpucoder. I'm not sure it is implemented in Tcl itself, as GetShortPathName() is a low-level C function only, but it's a good starting point.

[M_Knox]

r0lZ, I investigated the problem a bit and I think you need

set filename [encoding convertfrom [string trim [lindex $argv 0] \"]]

When the correct encoding is set (via PGCEDIT_ENCODING environment variable or a commandline option), this will go just fine.

Another way is to fix freewrap so it does not override the default encoding with cp1252, but I have not tried this yet...

[r0lZ]

Interesting. But iirc, I've added the code to change the encoding globally, so [encoding convertfrom] should never be needed. I don't want to have to change every line of code containing a filename! A freewrap patch will therefore be much appreciated!

[M_Knox]

No, you don't have to convert *every* filename like this, only this one, because it comes from argv, and argv is set before you have the chance to change the encoding system.

I'll see what I can do about freewrap.

[r0lZ]

Yep! I understand. That's easy then.

[vwpassion]

I was wondering if it'd be possible to select a button by double-clicking it, instead of moving the mouse down and pressing "Select" when in trace mode.

[r0lZ]

You should always use the cursor and return keys to operate the menu buttons in trace mode, to check if they work well with a real remote. And you can already use the middle mouse button to activate a button and continue the trace, or the right mouse button to activate it and break the trace. Is it necessary to add the double-click?

[vwpassion]

Oh, hadn't actually tried using the cursors during trace mode. Middle mouse button is already in use though, but cursor (enter) will totally do! Thanks.

[arrirc]

Hello r0lz

Without changing any commands, can the "DVD Text" button of PGCEdit be used either to add a new text or modify the existing one? Will doing this may cause some unwanted behaviour while playing the DVD in STB?

Thanks again for developing this excellent program.

[r0lZ]

The DVD-Text data are used by some players to display the name of the DVD, or the name of the current title or chapter in their GUI. (The DVD-Text standard is theoretically able to define many different names, but PgcEdit handles only the General Name). Unfortunately, very few players use the DVD-Text strings, so usually, the DVD-Text table is not defined. Some players use the DVD-Text General Name to identify the DVD (for example, my old Sony can display it on screen.) A multi-disc player (with a disc changer) should also use the name of the disc to help the user identify the disc that is currently loaded. Anyway, the DVD-Text data are never used to control the navigation, so changing the strings or removing them completely has no effect other than cosmetic.

I use that PgcEdit function mainly to identify the DVD.

In PgcEdit, when there are already DVD-Text data, Set DVD-Text General Name can only modify the current General Name (the global name of the DVD). Most of the time, there is not enough room in the table to overwrite it with a longest title, so you may have to enter a short name. Also, in some rare cases, PgcEdit is unable to modify the table at all (for example if the DVD-Text General Name field has not been defined).

If you want to enter a General Name anyway, you can delete completely the DVD-Text data, and PgcEdit will recreate a new table from scratch. But since PgcEdit creates ONLY the DVD-Text General Name field, all other fields will be lost. That's not a problem IMO, unless you have a player that can use them.

If you want complete control on the DVD-Text strings, have a look at TitleWriter (but don't ask me how it works, as I don't use it.)

[arrirc]

Thank you very much for the clear explanation. :) I as you, do not want to delve deep into DVDText table, rather want the same as you do: I use that PgcEdit function mainly to identify the DVD.

My present STB SONY DVP-NS50P seems to be able to handle DVD Text. So I just want to put the name of the DVD using the DVD Text button's feature of PGCEdit. So I hope that I can safely put the DVD name there. If there is is any existing Text, will PGCEdit display it and/or modify it if I input something using DVD Text button? Inother words I would like to put only the name in the DVD Text if it is not there already without deleting the existing table, if any that is.

Thanks again :)

[r0lZ]

Yes, if the General Name is already defined, it is copied in the input dialog, as the default string. You can change it without affecting the other fields, but usually, as explained above, you cannot lengthen it without clearing the table. You will not be able to enter more characters than what PgcEdit can handle for the current DVD, so the function is safe to use.

The General Name (and the Provider ID) are also displayed in the title bar of the main PgcEdit window.

[EDIT] Note that the maximum length of the General Name can be changed in the PgcEdit options. There is no theoretical maximum, but some players display only the first characters, and truncate the rest. Of course, if the original string is shorter, you may not be allowed to enter as many characters.

[arrirc]

Thank you very much r0lz for helping me out :)

[arrirc]

Hello r0lz

Could you please take a look at this problem http://forum.doom9.org/showthread.php?t=148886
?
Thank you

[mikenadia]

I used to delete the command but was wondering if there was not something else to do.
The command should never be executed , but if I force it ,it changes the navigation completely. For example, my last command in FP-PGC was a " Jump to nowhere". By forcing it, it bypassed the Main menu and went on to play the movie directly. In this case, it was easy to change the command in the PGC but I assume it is not always the case.
Can I replace the "Jump to Nowhere" by another command that will be more neutral with respect to the DVD-navigation.

Thanks in advance.

[r0lZ]

There should never be jumps to nowhere in an original DVD. The presence of jumps to nowhere can be caused either by an authoring error, an intentional protection, an error of the ripping program when it has removed the protection, or you have carelessly deleted some PGCs or VTSs.

If a player is forced to execute a command that jumps to nowhere, you can't tell what it will do. You have been lucky if it played the main movie. Most players will simply stop the DVD or hang. Of course, if you are sure that the jump cannot be executed, you can simply remove it. If it can be executed, hen you should try to replace it by a jump to a valid PGC, but you have to be sure that the PGC can be accessed from that point without breaking the navigation. That's not always easy to do, so I suggest to jump to the First-Play PGC, to restart the DVD completely. If the FP-PGC is never accessed from elsewhere, you can also apply PGC -> Reset Used GPRMs to 0 on the FP-PGC. This will assure that the navigation state is as much as possible close to the state it should be at startup.

[mikenadia]

Thank you, r0lz.
Pure Cosmetics:
When I open a new file in which there is a "Jump to Nowhere" command, it is highlighted and not in Edit mode. And when I right-click on "Delete"(thinking that I am in edit mode) I hear a bleep and nothing happens if I click on Delete many times (until I understand that I am not in Edit mode). If I right-click on Edit Command, I hear the bleep but it puts me automatically in Edit mode, so if I click a second time, I can edit the command.
This is probably indicated in the command color code...

[r0lZ]

This is a minor bug.
When you say "I'm not in Edit mode", I assume you are in Trace mode, right?
In Trace mode, no edits should be possible, as it is too dangerous to mix the trace and the edits. However, I have not disabled the Edit mode completely, as some power users may find useful to edit in trace mode. For example, it is possible to modify the current command to force the trace to use the modified command immediately as soon as you click Run, but you cannot delete the command because it is currently "in use" by the trace. Changing anything in the global structure of the DVD or current PGC (such as adding, deleting or moving elements) should never be possible, as the trace would get confused.
You have discovered a way to switch to edit mode while the trace is running, but use it at your own risk!

[mikenadia]

I did not discover anything. What I found is not a bug, pure cosmetics. I am not in Trace mode. What I meant by Edit mode was that the functions in the menu that appears by right-clicking on the command were functional (Edit command, Delete....).
I load the DVD (straight from the rip and probably intentional " Jump to Nowhere"). The bad command is highlighted. I should have clicked (left-click) on the command (what I meant by edit mode) before the right-click (for the menu list to appear ) for those commands to be functional. Nothing important. Only one click away.

[r0lZ]

Ah, OK, I understand.

The fact that a bad command (such as a jump to nowhere) is highlighted doesn't mean that it is selected. The highlight is a warning, and nothing else. So, yes, to pop the context menu up and use its Edit function (or the Edit button in the bottom part of the main window), you have to select the command you want to modify first. The command will be highlighted too, but in a different way, to show that it is selected.

When a PGC is opened (also immediately after having loaded a DVD), the first line with the "*** pre commands" label is automatically selected, but of course it doesn't make sense to edit it.

I can't change that behaviour easily, so you will have to live with that little annoyance.

[mikenadia]

With PGCedit 9.2 and 9.1 , I have this error message when loading the DVD and it seems to loop afterwards (the application is still running according to Windows Task Manager but nothing happens). Probably, bad rip or bad authoring.
With PGCedit 8.6 , I am able to load the DVD.
can't read "but": variable is array
can't read "but": variable is array
while executing
"set but"
(file "C:/U PANA BOGA W OGRODKU D4/VIDEO_TS/PgcEdit_backup/menubuttons.but" line 26970)
invoked from within
"source $butfilename"
(procedure "::menued::get_all_menu_buttons_from_butfile" line 14)
invoked from within
"::menued::get_all_menu_buttons_from_butfile $directoryname"
(procedure "readdvd" line 201)
invoked from within
"readdvd $dvddir ::raw_sectors ::pgcs ::menus ::ttns"
(procedure "::main::Read_New_DVD" line 64)
invoked from within
"::main::Read_New_DVD {C:/U PANA BOGA W OGRODKU D4/VIDEO_TS}"
(menu invoke)
The question is , even if one variable is not declared , is it that bad that it cannot and should not load in v9.x. What can I do in v8.6 either to fix the problem or to make it loadable in v 9.2.

Thanks in advance.

[r0lZ]

Seems your menubuttons.but file is damaged. Quit PgcEdit, then manually remove the PgcEdit_backup folder (located within your DVD folder), and relaunch PgcEdit v9.2. Do NOT open the DVD immediately at startup. Then go to the File Menu, and open the DVD from there. (Do NOT use the toolbar.) This way, if PgcEdit crashes when the DVD is loaded, you should see an error message. If it's the case, please copy it and paste it here. Otherwise, your menubuttons.but file should be recreated from scratch, and you should be able to load the DVD without problem the next time you start PgcEdit.

If that doesn't work, please post or send me your menubuttons.but file.

[mikenadia]

Cosmetics.
From r0lZ: PgcEdit is an IFO editor (though there are some functions related to the VOB files.)
I had to delete a VOB that was a " Warnings".
Then I loaded the DVD in PGCedit and wanted to kill Playback on tht PGC linked to the missing VOB.
I had a message that PGCedit cannot blank the cell because the VOB is missing or empty.
Because PGCedit trust the IFO, is it possible to allow this operation with a warning (or create an empty VOB). The reason is that the only way I found to recreate an empty VOB was to use VOBblanker . VoBblanker ask for a full scan because of the missing VOB but if I proceed without blanking the new VOB , I have an error message and an Abort because the info in the IFO file is wrong ( I was not able to kill Playback that PGC in PGCedit).
I hope that this is not too confusing.

[r0lZ]

You should NEVER touch or delete a VOB file manually!

There are two functions to get rid of unnecessary cells with PgcEdit. You can blank a single cell at a time, or blank a whole domain.

When you blank a single cell, PgcEdit appends a new cell to the existing VOB file and it fixes the reference of the current cell to point to the new one. Note that it leaves the original cell in the VOB. To remove it, you should use FixVTS (or simply process the DVD with VobBlanker). Of course, the VOB file must be present to use that option, as otherwise PgcEdit will be unable to place the new cell at its correct location.

In the other hand, when you use "Domain > Blank Out All Cells in Domain" (or the corresponding function in the context menu), PgcEdit blanks all cells of the current domain at the same time, and it is sure that none of them are still necessary. Therefore, it can replace the whole VOB with a tiny cell, or even, if the current domain is a menu domain, it can convert all menu PGCs to dummies and remove completely the VOB. Of course, the disc space is regained immediately, and it is not necessary to run FixVTS.

So, to repair the IFOs of the domain with the missing VOB, you should use that function. Usually, for a menu domain, I prefer to remove completely the VOB file (but in some rare cases, that's not possible without breaking the navigation). For a title domain, I use the option to also Kill Playback of the PGCs whenever possible, so that the tiny cell is not played. Anyway, in your case, the IFO will be repaired, and the VOB file (if any), will be correctly referenced.

[Plutox]

...probably Windows 7 related.

I have just come back to messing around with DVD structures after a year doing more important stuff and in that time I've moved to Windows 7 (not that bad an experience). I'm a paid-up user of PGCEdit.

Essentially, "automatically start preview playback" does not work. This is clearly not a low level problem as preview does everything it ought when it is started manually (by any available method); it simply does not start automatically. I've tried the usual compatibility options to no effect.

Thoughts please. :thanks:

[r0lZ]

Hum, I've just installed Win7 some weeks ago, and I haven't tested yet PgcEdit fully. I'll have a look next year ;), as I don't have much time right now.

Thanks for the report, Plutox!

[Plutox]

Hum, I've just installed Win7 some weeks ago, and I haven't tested yet PgcEdit fully. I'll have a look next year ;), as I don't have much time right now.

Many thanks. I haven't found any other anomalies - yet :)

[Mike89]

Lately with some movies when I'm using RipIt4Me, I rip then use the Tool option in RipIt4Me to open the rip with PgcEdit and get this message.

http://i62.photobucket.com/albums/h86/MikeO1989/PgcEditError.jpg

I don't know why I'm getting this message now with some movie rips (only using RipIt4Me) when I never got this message before until recently. I don't know quite what to do after the message. Any comments?

[r0lZ]

RipIt4Me is outdated, and cannot handle the new advanced protections.

According to the error message, RI4M has not finished the job, and some titlesets are missing. You can try to accept the dialog, but I doubt your DVD will work. It might work if all missing material is fake and never called really. Use Info -> Calls Cross References to verify if there is really something missing, and anyway, test the DVD carefully.

I haven't written RI4M and I don't use it, so I can't help much more. And BTW, this is the thread dedicated to PgcEdit, and not to RI4M.

[Mike89]

I know this is not a RipIt4Me thread but it was an error message in PgcEdit, that's why I posted it here.

I had more comments about this message and subsequent results from button decisions and DVD behavior afterwards but I guess this is not the thread to post it (I thought I was at the right place, now I don't know where to post it).

[blutach]

It's most likely a bad rip Mike. Use an up to date ripper.

If you still experience issues, then post here.

Regards

[r0lZ]

I had more comments about this message and subsequent results from button decisions and DVD behavior afterwards but I guess this is not the thread to post it (I thought I was at the right place, now I don't know where to post it).
Well, I can explain (here!) what this message implies and how to handle it, but I cannot know the origin of the problem that causes it to pops up. Anyway, when that message is displayed, it is usually due to a bad rip. It can also be caused by big human errors, for instance when he has manually deleted some files in the DVD folder. But you haven't do that, of course. So, obviously, RI4M cannot handle the DVD. Follow blutach's advice...

[Mike89]

I do use another ripper (dvdfab) if I can't get a successful rip but to tell the truth, still prefer RipIt4Me if it will rip the movie (so I try to make it work if I can, if not then on to DVDFab). As I said, this issue just started happening recently to some movies. And they were movies that didn't seem to have much copy protection (RipIt4Me displayed DVD Shrink in the beginning menu meaning DVD Shrink would rip it. Rip would go fine and then opening it in PgcEdit would give this error. Then no matter which options I would choose in the succeeding button choices, the end result was always a successful rip (did have to use RipIt4Me "Clean the Vobs" option).

Posted about it here cause I thought it was interesting what PgcEdit did with that error message and all the other error messages it would generate after that (by either clicking yes or no with the options) and then still getting a playable rip at the end.

Anyway, I won't take up anymore time in this thread about this as it seems RipIt4Me is now a dead issue (long live RipIt4Me, it was a damn fine program while it lasted).

[mikenadia]

Happy new year to all.
An issue with deleting simultaneously multiples lines with Goto.


Before deleting
[20 D4 00 09 00 32 00 07] 1 if ( gprm(9) > 50 ) then { LinkPGCN PGC 7 }
[00 D1 00 09 00 28 00 56] 2 if ( gprm(9) > 40 ) then { Goto line 86 }
[00 D1 00 09 00 1E 00 42] 3 if ( gprm(9) > 30 ) then { Goto line 66 }
[00 D1 00 09 00 14 00 2E] 4 if ( gprm(9) > 20 ) then { Goto line 46 }
[00 D1 00 09 00 0A 00 1A] 5 if ( gprm(9) > 10 ) then { Goto line 26 }
[00 B1 00 09 00 01 00 08] 6 if ( gprm(9) != 1 ) then { Goto line 8 }
[30 02 00 00 00 01 00 00] 7 (JumpTT) Jump to Title 1
[00 B1 00 09 00 02 00 0A] 8 if ( gprm(9) != 2 ) then { Goto line 10 }
[30 02 00 00 00 02 00 00] 9 (JumpTT) Jump to Title 2
[00 B1 00 09 00 03 00 0C] 10 if ( gprm(9) != 3 ) then { Goto line 12 }
[30 02 00 00 00 03 00 00] 11 (JumpTT) Jump to Title 3

[00 B1 00 09 00 31 00 68] 102 if ( gprm(9) != 49 ) then { Goto line 104 }
[00 00 00 00 00 00 00 00] 103 NOP
[00 B1 00 09 00 32 00 6A] 104 if ( gprm(9) != 50 ) then { Goto line 106 }
[00 00 00 00 00 00 00 00] 105 NOP
[20 04 00 00 00 00 00 03] 106 LinkPGCN PGC 3

After deleting lines 32 to 75 one at a time ( "Jump to Nowhere").
This looks correct.

[00 D1 00 09 00 28 00 2A] 2 if ( gprm(9) > 40 ) then { Goto line 42 }
[00 D1 00 09 00 1E 00 20] 3 if ( gprm(9) > 30 ) then { Goto line 32 }
[00 D1 00 09 00 14 00 20] 4 if ( gprm(9) > 20 ) then { Goto line 32 }
[00 D1 00 09 00 0A 00 1A] 5 if ( gprm(9) > 10 ) then { Goto line 26 }
[00 B1 00 09 00 01 00 08] 6 if ( gprm(9) != 1 ) then { Goto line 8 }
[30 02 00 00 00 01 00 00] 7 (JumpTT) Jump to Title 1
[00 B1 00 09 00 02 00 0A] 8 if ( gprm(9) != 2 ) then { Goto line 10 }
[30 02 00 00 00 02 00 00] 9 (JumpTT) Jump to Title 2
[00 B1 00 09 00 03 00 0C] 10 if ( gprm(9) != 3 ) then { Goto line 12 }

After deleting lines 32 to 75 simltaneously (multiple select with the "Shift"key and then Delete.
This looks incorrect (lines 3 and 4)

[00 D1 00 09 00 28 00 2A] 2 if ( gprm(9) > 40 ) then { Goto line 42 }
[00 D1 00 09 00 1E 00 42] 3 if ( gprm(9) > 30 ) then { Goto line 66 }
[00 D1 00 09 00 14 00 2E] 4 if ( gprm(9) > 20 ) then { Goto line 46 }
[00 D1 00 09 00 0A 00 1A] 5 if ( gprm(9) > 10 ) then { Goto line 26 }
[00 B1 00 09 00 01 00 08] 6 if ( gprm(9) != 1 ) then { Goto line 8 }
[30 02 00 00 00 01 00 00] 7 (JumpTT) Jump to Title 1
[00 B1 00 09 00 02 00 0A] 8 if ( gprm(9) != 2 ) then { Goto line 10 }
[30 02 00 00 00 02 00 00] 9 (JumpTT) Jump to Title 2
[00 B1 00 09 00 03 00 0C] 10 if ( gprm(9) != 3 ) then { Goto line 12 }

[blutach]

In these types of PGCs, it is easiest to do the following:

1. Change the JumpTTs of the unwanted titles to NOPs (or just delete those lines).
2. Do a Remove Useless Stuff.

Regards

[mikenadia]

Thanks, blutach.
Probably a nice feature of 9.3 because 9.2 Remove useless stuff do not affect those lines.
But that "simultaneous Delete" can lead to unexpected results and I will not use it.

Original:
[00 A2 00 00 00 01 00 00] 12 if ( gprm(0) == 1 ) then { Break }
[20 A6 00 00 00 02 00 02] 13 if ( gprm(0) == 2 ) then { LinkPGN Program 2 }
********** post commands:
[71 00 00 04 00 01 00 00] 1 Set gprm(4) =(mov) 1
[71 00 00 01 00 01 00 00] 2 Set gprm(1) =(mov) 1
[30 08 00 04 01 C0 00 00] 3 (CallSS) Call the VMGM PGC 4, resume cell 1

After " Killing Playback"
[00 A1 00 00 00 01 00 0E] 12 if ( gprm(0) == 1 ) then { Goto line 14 }
[00 A1 00 00 00 02 00 0E] 13 if ( gprm(0) == 2 ) then { Goto line 14 }
[00 00 00 00 00 00 00 00] 14 NOP
[71 00 00 04 00 01 00 00] 15 Set gprm(4) =(mov) 1
[71 00 00 01 00 01 00 00] 16 Set gprm(1) =(mov) 1
[30 08 00 04 01 C0 00 00] 17 (CallSS) Call the VMGM PGC 4, resume cell 1

After deleting simultaneously lines 13 and 14
(line 13 (former line 15) may be bypassed)
[00 A1 00 00 00 01 00 0E] 12 if ( gprm(0) == 1 ) then { Goto line 14 }
[71 00 00 04 00 01 00 00] 13 Set gprm(4) =(mov) 1
[71 00 00 01 00 01 00 00] 14 Set gprm(1) =(mov) 1
[30 08 00 04 01 C0 00 00] 15 (CallSS) Call the VMGM PGC 4, resume cell 1

It will be nice if "remove useless stuff" could remove, when it is safe:
Line X: if"" then Goto Line X+1. (lines 12 and 13 in the "Killing Playback" above subsection).
or Line X: Goto Line X+1

Edit: I do not know if it makes sense or not but in Trace mode, when running the program ("Step"," Next PB" "Run") after having selected FP-PGC, assume that the user wanted to "insert DVD" (resetting of GPRM...). I am using the "Insert DVD" button.

Line 5 in "After Killing Playback" might be difficult to delete, but just in case.
Might be easier to deal with during the "Killing Playback"subroutine.

[20 B4 00 00 00 01 00 02] 5 if ( gprm(0) != 1 ) then { LinkPGCN PGC 2 }
[00 02 00 00 00 00 00 00] 6 Break
********** post commands:
[20 04 00 00 00 00 00 02] 1 LinkPGCN PGC 2

After Killing Playback
[20 B4 00 00 00 01 00 02] 5 if ( gprm(0) != 1 ) then { LinkPGCN PGC 2 }
[00 01 00 00 00 00 00 07] 6 Goto line 7
[00 00 00 00 00 00 00 00] 7 NOP
[20 04 00 00 00 00 00 02] 8 LinkPGCN PGC 2
In the last example, it seems that the duration of the PGC does not go back to 0.00 or 0.01 , the reason being probably that the VOB is used in PGC2, whose command lines are.
********** pre commands:
********** post commands:
[30 08 00 00 01 83 00 00] 1 (CallSS) Call the VTSM Root menu of the current VTS, resume cell 1

PGC2 is a "child" of PGC1 (can only be called from PGC1). They share the same VOB.
As a user, Killing Playback on PGC1 implies "Killing Playback on PGC2" but I agree it can be misleading.
But if If I kill Playback on PGC2 first, the duration of PGC2 is changed to 0.00.
In this case, Blanking all VTST would have put all durations to 0.00.
Also, Killing Playback on PGC1 only will require a Full scan in VOBblanker and "Final Size" will be bigger than "Initial size" on that VOB.
Thanks in advance.

[M_Knox]

9.3 will have a nice feature that will do that (remove "uncalled" commands).

Furthermore, in your example, after deleting lines 13 and 14 at once, the Goto in line 12 should point to line 13, not 14. This is a PgcEdit bug, that will be fixed in version 9.3.

(I hope I haven't spoiled the surprise, r0lZ :) )

[r0lZ]

I confirm that the bug when multi-deleting some GoTo target lines is fixed in 9.3.

There are so many changes in 9.3 in Remove Useless Stuff that I can't say for sure if it will do exactly what you want with your DVD, but it is true that the useless lines are now automatically removed. The GoTo to the next line (and to the next non-NOP and non-target line) are removed, and the commands that cannot be executed due to jumps or GoTos are automatically removed. (In fact, they are first converted to NOP, and another part of the cleanup function removes the useless NOPs. You can opt to keep them if you wish.)

When the pre-commands contain some links inside the PGC (for example a link to cell 2), it is not safe to completely kill playback, especially if there are cell commands, as the cell pointed to by the command can lead to a different PGC via its cell command. PgcEdit refuses to kill that PGC, and instead, it offers to blank the cells. Blank All PGCs has an option to kill only when it's safe (the default), or to kill anyway (dangerous).

Not sure what happens in your last example when you kill PGC 1. PgcEdit cannot kill it completely due to the links, but it should offer to blank the cells. If you accept, the total duration of the PGC should drop to approx 0.5 seconds * the number of cells.
Of course, since the VOB cells are reused in PGC 2, VobBlanker or FixVTS will not remove them, unless you kill also PGC 2.
Note also that when you kill PGC 1, you will end up with exactly the same commands than in your example. But if you run Remove Useless Stuff, the useless GoTo and NOP are removed. Currently, the function is not smart enough to detect that the conditional link is useless too, so you end up with:
[20 B4 00 00 00 01 00 02] 1 if ( gprm(0) != 1 ) then { LinkPGCN PGC 2 }
[20 04 00 00 00 00 00 02] 2 LinkPGCN PGC 2

[r0lZ]

Edit: I do not know if it makes sense or not but in Trace mode, when running the program ("Step"," Next PB" "Run") after having selected FP-PGC, assume that the user wanted to "insert DVD" (resetting of GPRM...). I am using the "Insert DVD" button.
I don't understand your edit. Clicking on the Insert DVD button does what a player should do when a DVD is inserted: it resets everything, and begins the navigation at the FP-PGC.

But note that you can right-click on that button to simulate what a player should do when a DVD is restarted after having pressed the Stop button twice (but not removed the DVD). The player is now in the so called "exit state" and it displays its logo. In that case, it is supposed to do a partial reset of the GPRMs and SPRMs and to begin the navigation at Title 1 instead of the FP-PGC.

Some players can even restart the DVD at a specific title if the user presses a number key on the remote. This is not directly supported by PgcEdit, but it's easy to simulate: right-click on the Insert DVD button, then click on the first pre-command of the title you want to play, and finally run the trace.

[mikenadia]

Duration issue seems to be my issue. Reripped everything and everything is fine.
For the "insert DVD" (just cosmetics): What I wanted to say is that during the " Jump to Main Menu and Bypass intros" procedure, in Trace mode, you go to Main Menu and you "Toogle PGC pre/post breakpoint".Then you should click on "insert DVD", "run" to the menu again before clicking on "Jump to PGC upon insert". If instead of doing that, after "Toogle breakpoint", you select FP-PGC and "run" (wrong procedure), it looks similar (but the GPRM are not reset). Then I do not see any use (my assumption) of "run" from FP-PGC without resetting GPRM.
If my description is still confused, forget it ...:confused:

Thanks a lot for your work, r0lZ ( and watch out the SNOW:)).

Edit: wish list: To have a list of bad commands (coming from a bad rip like all those highlighted in orange command). Because now you have to open the PGC to see them highlighted ( sometimes in a PGC where I will not make any change so I will miss them) and when they are highlighted, it may not be obvious (for casual users) what to do. For example, in a menu , the last cell command (highlighted in orange) was LinkTailPGC. It seems not necessary (because it is the last "cell" command) but that is just a guess. And I do not know what to do. Same thing with "RSM" as a last cell command in another menu ( and highlighted in orange).
May be locate this in an optional "remove useless stuff" for a one-stop procedure and to have the possibility ( for casual users) of letting PGCedit take the decision what to do with them (NOP or delete those "Jump to Nowhere"...)

[r0lZ]

I understand now. It might be useless to start the trace from the FP-PGC without clicking first on Insert DVD, but that's true for any PGC. It is always possible to fool the trace by starting it at a "wrong" point, or by modifying the GPRM values manually. But that can be instructive too, so I haven't disabled the editor in trace mode. The Watch window can even be used to modify the value of any GPRM or SPRM during the trace, just to check what happens with different values.

Of course, when using Jump2PGC, you MUST follow exactly the procedure (at least after having placed the break point), or the result might be unpredictable. However, if you know for sure that changing a register value before calling Jump2PGC is good for you (for example because it preselects your preferred audio or subpic stream), you can do it. But it's at your own risk.


The last cell command(s) are sometimes highlighted only because they are not referenced in the PGC. They are therefore useless (but not necessarily illegal). And the new cleanup removes them too! :-)

I have plans to write a (limited) verifier to summarize the errors detected by PgcEdit. But it's an enormous work, and unfortunately, the way the bad commands are highlighted now is not compatible with that, as it suppose that the PGC is currently loaded in the editor. I can reuse some parts of my code, but the main part of the work is still to do. Sorry, but v9.3 will not have the verifier (unless you prefer to wait one year more!)

[mikenadia]

Thanks,r0lZ.
Really cosmetics. Two commands (2-18 and 19-21) repeated during the "Jump to Pgc upon insert" procedure.
Also lines 10 , 11 and 18 are not there if I do "Clear Useless Set commands "from within "Remove Useless stuff" before" Jump to PGC..."
Because of that, gprm(7) and gprm(8) are not considered useless (two " if gprm(?) goto" commands generated by "Jump to PGC" procedure). if I run "Jump to PGC upon insert" before "Removing useless stuff" or the opposite, I end up with equivalent but different results depending which procedure is run first.

********** pre commands:
[00 B1 00 0F 03 FE 00 14] 1 if ( gprm(15:Jump2PGC_control) != 1022 ) then { Goto line 20 }
[71 00 00 0F 00 00 00 00] 2 Set gprm(15:Jump2PGC_control) =(mov) 0
[71 00 00 00 00 FF 00 00] 3 Set gprm(0) =(mov) 255
[71 00 00 01 00 00 00 00] 4 Set gprm(1) =(mov) 0
[71 00 00 02 00 00 00 00] 5 Set gprm(2) =(mov) 0
[71 00 00 03 00 00 00 00] 6 Set gprm(3) =(mov) 0
[71 00 00 04 00 01 00 00] 7 Set gprm(4) =(mov) 1
[71 00 00 05 00 43 00 00] 8 Set gprm(5) =(mov) 67
[71 00 00 06 00 43 00 00] 9 Set gprm(6) =(mov) 67
[71 00 00 07 00 43 00 00] 10 Set gprm(7) =(mov) 67
[71 00 00 08 00 00 00 00] 11 Set gprm(8) =(mov) 0
[71 00 00 09 00 FF 00 00] 12 Set gprm(9) =(mov) 255
[71 00 00 0A 00 07 00 00] 13 Set gprm(10) =(mov) 7
[71 00 00 0B 00 01 00 00] 14 Set gprm(11) =(mov) 1
[71 00 00 0C 00 00 00 00] 15 Set gprm(12) =(mov) 0
[71 00 00 0D 00 00 00 00] 16 Set gprm(13) =(mov) 0
[71 00 00 0E 03 E7 00 00] 17 Set gprm(14) =(mov) 999
[71 00 00 0F 03 E7 00 00] 18 Set gprm(15:Jump2PGC_control) =(mov) 999
[56 00 00 00 04 00 00 00] 19 (SetHL_BTN) Set Highlighted Button =(mov) 1024 (button 1)
[00 00 00 00 00 00 00 00] 20 NOP
[56 00 00 00 04 00 00 00] 21 (SetHL_BTN) Set Highlighted Button =(mov) 1024 (button 1)


line 18 is interesting. I think it's coming from the fact that gprm(15) exists before running the "Jump to PGC" procedure. But it is useless (as well as gprm(7) and gprm(8)) and has been probably reused for Jump2PGC_control.
It may be interesting to do "Find uncalled PGCs" before "Clear useless Set commands" in the "remove useless stuff". The " Find useless gprm Set commands" does not take into account whether the PGC are called or not (I do not know if it should consider useless commands as per v9.3?). Getting very complex.
Other combination might even be more effective.

[r0lZ]

Normally, PgcEdit uses a unused GPRM for Jump2PGC. If it cannot find one, it asks the user to select one, and resets it to 0 (in line 2). Then, it generates the Set commands to set the values of the GPRM as they were after the trace. Line 18 does this for GPRM 15. The command is duplicated because GPRM 15 was in use when you have applied Jump2PGC. I agree that line 2 is useless, but it is inserted anyway because it's necessary when the GPRM is unused.

The fact that commands 19 and 21 are repeated is normal. The highlighted button must be button one when the DVD is inserted (given the result of the trace before applying Jump2PGC) and therefore PgcEdit has to insert that command to be sure that the correct button will be pre-selected. Line 19 accomplishes this. (OK, button one is theoretically the default button when the DVD is inserted and therefore the command is not needed, but PgcEdit inserts the command anyway as it could be button 2, for example.)
Line 21 was probably the original pre-command of the PGC, before applying Jump2PGC. It is still there, as if the nav returns to that PGC, it must be executed. (It's why the first line inserted by Jump2PGC is a Goto line 20, to skip the Jump2PGC stuff and execute the original commands.)
I agree that in this case, the Goto could go to line 19, and in that case, lines 20 and 21 become useless. But again, the button could be different in the Jump2PGC stuff and in the original commands, and checking if some commands are useless is too difficult to do when applying Jump2PGC. You can modify the commands manually if you wish.

IMO, it is always preferable to do a cleanup before applying Jump2PGC, for the reason you have discovered. The job is better, as Jump2PGC does not insert useless Set commands, and the GPRMs that are only read are removed and become really unused, giving more choices for Jump2PGC.

I've tried many combinations of the cleanup functions to obtain the best result. But there is no perfect solution, as the best order depends of the authoring of your DVD. IMO, the current order work well in most cases, but I agree that it is sometimes useful to apply the cleanup twice. The things that have not been cleaned up during the first run are usually removed during the second one. In your example, the GPRMs used only in uncalled PGCs will be removed as the PGCs in which they are initialized are removed. (Note that IMO applying Find uncalled PGCs is useless, as that function doesn't remove automatically the commands. But Delete Uncalled PGCs is much more useful from this point of view.)

Anyway, as you said, this is only cosmetics. Adding many checks to be sure to generate the more compact code possible is potentially a source of bugs, and I don't want to waste my time to do that. The new cleanup functions are already really powerful, but it is impossible to detect every things that could be simplified.

[mikenadia]

My last comment on the subject. I understand the lack of interest for the many checks that may create bugs but may be incorporating the "Clear useless Set commands" as part of "Jump to PGC " may have advantages. For me, it is irrelevant because I remove useless stuff before. As for efficiency, what about a) NOP unused commands ( get rid of unreferenced cells, jumps and links to void PGCs,other 9.3 unused commands...) , b) Delete uncalled ( PGCs, Titlesets, Menus...: doing first for the ones that can be done with or wtihout sprm(4,5), and then the ones conditional upon sprm(4,5).Do not know about sprm(6,10)) ,c) Clear all useless Set gprm commands , d) clean the code (get rid of NOP...).
a) is supposed to create as many uncalled (PGCs...) as possible.
a) and b) are supposed to create as many useless gprm as possible.
And it is my belief that "Remove Useless stuff" will need to be run only once in all circumstances.
I agree that the "Remove useless" is already powerful enough but "posting" helps me understand and appreciate more and more what PGCEdit is doing.

[r0lZ]

Well, I will not incorporate the Clear Set Commands in Jump2PGC for a simple reason. Many users do not want to modify the commands before having fully analysed and understood the DVD. Personally, I use the cleanup usually before any edits, because I believe it works well, but other users prefer to leave the DVD as unchanged as possible. Anyway, it is easy enough to launch the cleanup manually.

For the order of operations, you're might be right, but since v9.3 introduces some new cleanup options, I'm pretty sure the order is now right. BTW, here are the operations:

Delete Dead Commands
Delete Dead Buttons and BOVs
Delete Unreferenced Cell Commands
Delete Uncalled Titlesets
Clear Useless Set Commands
Clear Jumps to Void PGCs
Remove Useless Menu VOB files
Delete Uncalled PGCs
Delete All NOPs

Note: "Dead" commands are the commands that cannot be executed due to Jumps or GoTos. For example, a command after a unconditional jump and that is not the target of a Goto cannot be executed, and is deleted. A GoTo to the next line (or to the first line after some NOPs) is useless (although not technically dead) and is also deleted. (Note also that these commands are highlighted in purple in the editor pane.)

I agree that Clear Jumps to Void PGCs could be before Delete Uncalled Titlesets, or Delete Uncalled PGCs before Clear Useless Set Commands, but IMO the most important thing is to get rid of as many PGCs as possible, to regain the disc space occupied by their cells. This is why that function must be at the end of the process. (It is followed by Delete NOPs because that operation doesn't change the navigation at all.) Also, when I have decided to adopt that order, I had the speed of the overall process in mind. It is for example important to delete the uncalled titlesets (because, for example, you might have modified the nav to skip a game, usually full of PGCs with many commands), before doing some of the next operations, particularly slow when there are many PGCs and commands.

Anyway, as I said, it is sometimes necessary to apply the cleanup twice to get rid of all useless stuff. Don't worry; the second time, it is usually faster, as there is already less stuff to process.

[mikenadia]

1) one dummy PGC 10 with only one command (pre or post) such as Link PGC 9 and calling commands that are buttons with Link PGC 10 in the same VTSM. Can I just change the button to Link PGC 9 to have PGC 10 uncalled? PGCedit let me do it manually and navigation seems fine.
2) in PGC 10 I have as a pre-command: "if gprm(9)>50 Link PGC 10"
( probably never executed because it is a loop). Should I delete it or keep it as a safeguard?
3) in the menu that was selected for " PGC upon insert" i have two cells commands such as
LinkTopPG and then set ;LinkTailPGC
It is my understanding that the second cell command will never be executed (at least using the Trace, I was not able to have it executed: The LinkTopPG is always executed until I select a Button in that menu (as expected)). Could I just delete it?

Thanks in advance.

[kikatu]

1- If PGC-9 is a dummy-PGC also and only called by PGC-10 simply copy the commands from 9 and paste to 10, PGC-9 will be uncalled. Yes it can be done also as you mentioned.

2- If that's the only Pre-Command seems it can be deleted safely, but if there are "Goto line" & "Set gprm" prior to the "if gprm(9)>50 Link PGC 10" it may be used, if this is the case please post all the pre-commands.

3- In the Trace did you used the skip function to see if it's executed? Also click the VTSM-PCG to see if it's used, e.g. http://i47.tinypic.com/vy723m.png


Cheers!

[r0lZ]

I agree with kikatu, but for point 2, I would like to add that this kind of backward loop might be used to launch another command. For example, a command might check if gprm 9 is 50 and when it's the case it jumps to another PGC. After that command, you might have a command that increment the value of gprm 9, and finally the conditional backward loop. After having incremented the gprm and looped back some times, the first command will be executed.
Anyway, when you ask something like this, please post all commands of the PGC, as kikatu has suggested.

Also, for point 3, the cell command can perhaps be executed when you press the Next Chapter button during the playback of the cell that is just before the one with the cell command.

[mikenadia]

Thank you, kikatu and r0lZ.
I edited my post saying that this was the first pre-command. Actually, it is the same PGC as post #135 in this thread.
Commands for PGC 7.[20 D4 00 09 00 32 00 07] 1 if ( gprm(9) > 50 ) then { LinkPGCN PGC 7 }
[00 D1 00 09 00 28 00 56] 2 if ( gprm(9) > 40 ) then { Goto line 86 }
[00 D1 00 09 00 1E 00 42] 3 if ( gprm(9) > 30 ) then { Goto line 66 }
[00 D1 00 09 00 14 00 2E] 4 if ( gprm(9) > 20 ) then { Goto line 46 }
[00 D1 00 09 00 0A 00 1A] 5 if ( gprm(9) > 10 ) then { Goto line 26 }
[00 B1 00 09 00 01 00 08] 6 if ( gprm(9) != 1 ) then { Goto line 8 }
[30 02 00 00 00 01 00 00] 7 (JumpTT) Jump to Title 1
[00 B1 00 09 00 02 00 0A] 8 if ( gprm(9) != 2 ) then { Goto line 10 }
[30 02 00 00 00 02 00 00] 9 (JumpTT) Jump to Title 2
[00 B1 00 09 00 03 00 0C] 10 if ( gprm(9) != 3 ) then { Goto line 12 }
[30 02 00 00 00 03 00 00] 11 (JumpTT) Jump to Title 3

[00 B1 00 09 00 31 00 68] 102 if ( gprm(9) != 49 ) then { Goto line 104 }
[00 00 00 00 00 00 00 00] 103 NOP
[00 B1 00 09 00 32 00 6A] 104 if ( gprm(9) != 50 ) then { Goto line 106 }
[00 00 00 00 00 00 00 00] 105 NOP
[20 04 00 00 00 00 00 03] 106 LinkPGCN PGC 3


BTW, this is the same PGC where I had numerous " Jump to Nowhere".
r0lZ, I followed your advice (as usual) and used the "Jump to FP-PGC" (post #117).

In another movie with a similar PGC
Commands for PGC 3
[20 D4 00 09 00 63 00 04] 1 if ( gprm(9) > 99 ) then { LinkPGCN PGC 4 }
[00 D1 00 09 00 1E 00 44] 2 if ( gprm(9) > 30 ) then { Goto line 68 }
[00 D1 00 09 00 19 00 3A] 3 if ( gprm(9) > 25 ) then { Goto line 58 }

[00 B1 00 09 00 2A 00 5C] 90 if ( gprm(9) != 42 ) then { Goto line 92 }
[30 02 00 00 00 23 00 00] 91 (JumpTT) Jump to Title 35
[30 06 00 00 00 00 00 00] 92 (JumpSS) Jump to First Play PGC
I was wondering if there was a need to cap gprm(9) because if line 1 did not exist gprm(9)=100 would have led to line 92. Or is it the authoring software that there are using. Nothing special in PGC 4.