PgcEdit 0.5

[blutach]

Hmmm. In my SONY (and my NAD), the stripped streams are not there. Software players are a bit different - they can show a stripped stream but greyed out.

But your player is the one with problems and I don't doubt you have them. Have you tried using logical remapping off and then in PgcEdit disabling (not removing) the "placemarkers". Note: Not all players will like this. For example, my NAD is very picky - it likes the streams enabled or else it gets "stuck" when cycling through. The SONY, on the other hand, couldn't care less.

But as I said before, PgcEdit can do all this easily for you. If you choose logical remapping on - and I'd run PgcEdit's DVD Shrink streams remapping macro first to see if it will work - you can reprogram the menu buttons. If you leave it off, you can reorder the streams in the PGC Editor and reprogram the buttons.

Regards

[r0lZ]

Originally posted by selyb
Excellent work with the menu button editor :-D
with the removal of other programs to do that work i figgered it was time to donate ;) Thanks!

BTW, is this the place for feature requests?Yes, but I will not work as heavily as before during the springs and summer. I have some other projects.

Is it possible to blank a single title or cell?
ive noticed that sometimes when i kill the playback of a pgc, i get a message asking if i want to remove the cells but i havent figured out when/why i get this message No, it's not possible, as PgcEdit doesn't process the VOBs. The only things it does is to append a blank cell at the end ot the current VOB, or replace the whole VOB by a single blank cell. Use VobBlanker to do that kind of processing.

Normally, Kill Playback just changes the pre commands of the current PGC to inhibit the playback.
However, when killing playback in the menu domain, there is an option to remove the references of the cell in the IFOs. The PGC will become a dummy PGC. The cell is not physically removed from the VOB, but is not referenced anymore in the IFOs (unless the same cell is reused in another PGC). If you load the DVD in DVDShrink, you will see the removed cell in the unreferenced material section.
The main advantage of this option is that you may load the DVD in VobBlanker, and process it directly, without having to manually mark the cell for removal. VobBlanker will drop the unreferenced cells automatically (or, with the new V2, replace them with a blank cell, if you wants so).
Also, if you use IfoEdit's Strip VOB ID function, the unreferenced cells will be automatically unselected in the GUI. (But IfoEdit is unable to strip a single Cell ID: it must strip the whole VOB ID or nothing.)
Unfortunately, it is not possible to implement the 'remove references' option in the title domain, because a dummy title is illegal.

[CoNS]

Originally posted by blutach
But as I said before, PgcEdit can do all this easily for you. If you choose logical remapping on - and I'd run PgcEdit's DVD Shrink streams remapping macro first to see if it will work - you can reprogram the menu buttons. If you leave it off, you can reorder the streams in the PGC Editor and reprogram the buttons.Yep, I think I know how to reorder the streams in PgcEdit (Logical remapping off) the way you mean, but I'm not quite sure. And I'm not sure at all how to reprogram the menu buttons.

That's why I previously asked zacoz in this thread if he could make a quick/small guide on how to do it, as he mentioned that he had done it succesfully.

[r0lZ]

Originally posted by CoNS
Ok, so IfoEdit does it somewhat differently then? But still it's done under the VOB Extras function in IfoEdit?

Does IfoEdit have an option for fixing the stream order, or does it try to do it automatically in all instances of stripping audio/subs?IfoEdit strips the streams, and reorder the streams IDs in the VOBs, and remove the streams from the IFO tables, but, as far as I know, it doesn't fix the VM commands, so, the streams selected via commands will be wrong.

I haven't followed the discussion in other threads about loosing cell commands in IfoEdit when stripping audio/subs. Is correct that IfoEdit is safe to use for stripping audio/subs in all cases where the PGC does not have cell commands? (what about pre/post commands?) And if the PGC has cell commands, you can still use IfoEdit for stripping if you remember to copy the cell commands back into the output disc afterwards by using PgcEdit or a similar program?No, IfoEdit is not always safe. It doesn't copy the cell commands numbers, and, also, it changes the cells type flags. Pre and post commands are not concerned, however.

Hmmm r0lZ, as this stream reorder issue apparently pops up quite often among users, and as DVDShrink and IfoEdit don't work well in this matter, you could maybe consider making a macro in PgcEdit to fix it correctly? I know it's not easy to do, but what do you think? With the menu editor in place, you could need a new challenge? ;) Unfortunately, it's not possible to automate this task. If you strip the streams in another program (say with DVDShrink with streams remapping ON), I will have no way to know which were the original streams refered to by the VM commands.
Furthermore, if an indirect SetSTN command is used somewhere, it's verry difficult to know where and how to change the GPRM, so that it will reference the right stream number.
However, you may do it relatively easily manually: locate the indirect SetSTN commands with the search function of PgcEdit, and note the GPRM they use. Then, goto Trace mode, set a breakpoint to all GPRMs used by SetSTN, and launch the trace. When the playback will stop, you must change the value assigned to the GPRM to reference the right stream.

The problem may be that the reordering/remapping of streams must be conducted in connection with the stripping of audio/subtitle streams itself to make sure that the buttons point to the correct streams afterwards? Maybe a combined function to strip audio/subs and reorder/remap would be something for jsoto to implement in VobBlanker instead? Right. But, as explained above, it's not easy to do if you have indirect SetSTN commands. Also, you will need to process the whole DVD, to be sure that all SetSTN in menu buttons will be processed.

[blutach]

@CoNS

Programming the menu buttons is the same as changing a command in the Editor. You just click on the button concerned and click underneath the menu display to bring up the same sort of VM command editor that you are already familiar with.

Suppose you had a subtitle stream originally mapped as stream 10 (which would be 9, since they start at 0). This is how your button would be programmed:

[51 00 00 00 C9 00 00 00] 1 (SetSTN) Set Sub-picture stream = 9, on (Note: There might be also be commands to highlight button numbers or links to other PGCNs/programs/cells).


Now, if you remapped this to stream 3 (which would be 2) you would simply change the button to:

[51 00 00 00 C2 00 00 00] 1 (SetSTN) Set Sub-picture stream = 2, on It's easy to see which stream is which as the Domain stream attributes for the movie title will tell you by country code.

Hope this helps and is what you were after.

Regards

[r0lZ]

Originally posted by CoNS
So that's why we have different approaches to this issue: For you it workds fine in your standalone. You don't see the stripped streams. For me, however, I still see the empty streams when I cycle through the streams with my remote on my standalone Sony, and I don't like that! This is why I've added the Macro -> DVDShrink Stream Remapping function. At least when it's safe, you may use the remapping, and still have working menus.

[CoNS]

@r0lZ: Yep, I use your macro alot. Very helpful. But it still leaves the problem unsolved when the macro says that the "Logical Remapping" option in DVDShrink should not be used...

And then when the button editing comes in! (if your not keen on the idea of making a macro that can do this, too!?!).

Thanks for explaining the button editing, blutach. Only, the examples you describe with buttons having SetSTN commands are actually the cases where the option in DVDShrink CAN be used... How do I edit the button commands when they are the same for all buttons, i.e. LinkTailPGC? This is when the "Logical Remapping" option in DVDShrink cannot be used.

[r0lZ]

Just search for SetSTN commands in the PGCs...

[CoNS]

Sorry for being such a dumbass nOOb! But just to make sure that I get it right:

A. If my button commands are the "SetSTN" type, I can either

1) use DVDShrink's logical remapping option (that's what PgcEdit's macro checks for, right?) and it'll do the button command remapping for me, or

2) I can strip the audio/subs without using the option in DVDShrink and then manually reorder the streams in PgcEdit and manually edit the SetSTN button commands (what blutach suggested)

B. If my button commands are the same ("LinkTailPGC" type), I cannot use DVDShrink (PgcEdit's macro will tell me this, too). I can then either

1) Strip the streams in DVDShrink with the logical remapping option on, and then fix the stream numbers in the PGC commands (where it reads the button number and determines the corresponding stream number with SetSTN), or

2) Strip the streams in DVDShrink with the option off (or use VobBlanker for audio stripping, or any other program that can strip audio/subs by replacing the stream with a blank/empty stream, i.e. DVD-Rebuilder), then reorder the streams in PgcEdit, as blutach described above, and then finally fix the stream numbers in the PGC commands (where it reads the button number and determines the corresponding stream number with SetSTN)

Right?

BTW, how does IfoEdit's VOB Extras strip function fit into the above?

[r0lZ]

Originally posted by CoNS
Sorry for being such a dumbass nOOb! But just to make sure that I get it right:

A. If my button commands are the "SetSTN" type, I can either

1) use DVDShrink's logical remapping option (that's what PgcEdit's macro checks for, right?) and it'll do the button command remapping for me, or

2) I can strip the audio/subs without using the option in DVDShrink and then manually reorder the streams in PgcEdit and manually edit the SetSTN button commands (what blutach suggested)Of course, you can do it manually. But why?

B. If my button commands are the same ("LinkTailPGC" type), I cannot use DVDShrink (PgcEdit's macro will tell me this, too). No. PgcEdit checks if there are indirect SetSTN commands somewhere in the DVD (including in the menus and BOVs).
Indirect commands do use GPRMs as arguments, not constant values. It's therefore not possible to change them to use the right stream number.
The fact that the button commands are all LinkTailPGC is not, per se, a problem. Normally, in this case, the post commands are used to check which button has been highlighted, and the corresponding action, wich may be a direct or indirect SetSTN, is executed.

I can then either

1) Strip the streams in DVDShrink with the logical remapping option on, and then fix the stream numbers in the PGC commands (where it reads the button number and determines the corresponding stream number with SetSTN), or

2) Strip the streams in DVDShrink with the option off (or use VobBlanker for audio stripping, or any other program that can strip audio/subs by replacing the stream with a blank/empty stream, i.e. DVD-Rebuilder), then reorder the streams in PgcEdit, as blutach described above, and then finally fix the stream numbers in the PGC commands (where it reads the button number and determines the corresponding stream number with SetSTN)

Right?Right. If uou used the streams remapping option, keep in mind that you must leave the direct SetSTN commands as they are. They have been fixed by DVDShrink. You must only change the values assigned to the GPRMs used by the indirect SetSTN commands.

BTW, how does IfoEdit's VOB Extras strip function fit into the above? IfoEdit does the stripping without fixing the commands (ie same as streams remapping off), but with the well known bugs in the cell table. Don't use it for streams stripping!

My method is this one:
I check if the DVDShrink streasms remapping is safe. Then, I strip the streams always with the streams remapping option ON! If the option was not safe, I search for the indirect SetSTN in the PGC and in the button commands. I note the GPRM numbers used. Then, I search for that GPRMs, and, when a constant is assigned, I change the value of the constant. But things may be even more complicated if the GPRM is used for several different purposes in the DVD, or if the GPRM is assigned the value of another GPRM.

The trace function is also useful to find out where the values must be changed: just run the trace until you reach the audio or subpic menu, then break it, and single step until you find the right assignment.

[CoNS]

Thank you very much for your answer. The whole thing is much more clear to me now after reading yours and blutach's views on it.Originally posted by r0lZ
Of course, you can do it manually. But why?Exactly! But that's what blutach described if I'm reading his reply correctly.

EDIT: Could you give an example on how to edit the indirect SetSTN commands? Is it exactly what 2COOL described in his guide about removing aspect ratio/language selection menus v3.0 (page 2)?

[r0lZ]

Suppose you have this SetSTN:

(SetSTN) Set Audio stream = gprm(1)

You have to search for a gprm(1) assignment. It may be a line like this one:

Set gprm(1) =(mov) 3

You have to replace the 3 by the number of the new stream. If, for example, stream 3 was French before the strip, and french is now stream 1, then change the 3 to 1. (Keep in mind that the streams are numbered starting at 0!)

The method is a little bit more complex for subpic streams, as the subpic number is ored with 0x40 (decimal 64) to turn it ON. So, the avove example become:

(SetSTN) Set Sub-picture stream = gprm(1)
and
Set gprm(1) =(mov) 67
(because stream 3 turned on is value 3 + 64)

[CoNS]

Ok, thanks. But what is the connection between the button command in these cases (LinkTailPGC) and the PGC commands? How does the PGC commands know which button is pressed?

And would it be possible to make a macro in PgcEdit to do the job automatically in selected PGCs? (search for the indirect SetSTN commands, correct the gprm values etc.?)

[selyb]

Originally posted by r0lZ
Normally, Kill Playback just changes the pre commands of the current PGC to inhibit the playback.
...
Unfortunately, it is not possible to implement the 'remove references' option in the title domain, because a dummy title is illegal. [/B]

Understood.

A feature i would love to see implemented is multiple backup folders
maybe a 'create a New backup' button and the ability to restore to any of those restore points

what i do now is save, close pgcedit, rename the backup folder, and reopen pgcedit

thanks again for a wonderful piece of work :)

[jeanl]

I believe you don't have to quit pgcedit. You can rename the backup folder, and then hit the "reopen" button...
EDIT: NO! That does not work! Sorry! I remembered wrong...
jeanl

[r0lZ]

Originally posted by selyb
Understood.

A feature i would love to see implemented is multiple backup folders
maybe a 'create a New backup' button and the ability to restore to any of those restore points

what i do now is save, close pgcedit, rename the backup folder, and reopen pgcedit

thanks again for a wonderful piece of work :) That's alerady done! V0.5.2 will have a new File menu item: Incremental Backup, that does just that. It renames the last PgcEdit_backup with an extension with the modification date and time of the folder, and then saves the IFOs in a new PgcEdit_backup.

[r0lZ]

Originally posted by CoNS
Ok, thanks. But what is the connection between the button command in these cases (LinkTailPGC) and the PGC commands? How does the PGC commands know which button is pressed?LinkTailPGC jumps to the post commands of the current PGC. Here, the value of the SPRM 8 (highlighted button number) is copied in a GPRM, and that GPRM is tested (with IF statements) against constant values, and the action is carried out.
Use the trace function on any DVD authored this way to understand the logic.

And would it be possible to make a macro in PgcEdit to do the job automatically in selected PGCs? (search for the indirect SetSTN commands, correct the gprm values etc.?) As I said before, no. It's impossible to know which stream must be remapped to which one, and the GPRM used by the indirect SetSTN may be also used for another purpose somewhere else. The human brain is necessary to figure out all the possible situations.
A good guide on that matter will be useful. But I will not write it myself, as I'm to busy with the programmation of PgcEdit, and my english is too bad. Sorry.

[selyb]

Originally posted by r0lZ
That's alerady done! V0.5.2 will have a new File menu item: Incremental Backup, that does just that. It renames the last PgcEdit_backup with an extension with the modification date and time of the folder, and then saves the IFOs in a new PgcEdit_backup.
http://forum.cdfreaks.com/images/smilies/4/bowdown.gifhttp://forum.cdfreaks.com/images/smilies/4/bowdown.gifhttp://forum.cdfreaks.com/images/smilies/4/bowdown.gifhttp://forum.cdfreaks.com/images/smilies/4/bowdown.gif

[blutach]

Blanking VMGM

This error message:

error renaming "E:/Working_Copy/VIDEO_TS.VOB" to "E:/Working_Copy/PgcEdit_backup/VIDEO_TS.VOB": permission denied
error renaming "E:/Working_Copy/VIDEO_TS.VOB" to "E:/Working_Copy/PgcEdit_backup/VIDEO_TS.VOB": permission denied
while executing
"file rename -force -- [file join $::dvddir $name] $backupdir"
invoked from within
"if [file exists [file join $::dvddir $name]] {
catch {file delete [file join $backupdir $name]}
file rename -force -- [file join $::dvddir $..."
invoked from within
"if $back {
if [file exists [file join $::dvddir $name]] {
catch {file delete [file join $backupdir $name]}
file rename -force -- [file j..."
invoked from within
"if $::utils::blankout_movevob {
if {! [file exists $backupdir]} {file mkdir $backupdir}
set back true
if [file exists [file join $backupdir $..."
(procedure "blank_out_remove_vobs" line 36)
invoked from within
"blank_out_remove_vobs $vtsnum $type"
(procedure "blank_out_PGCS_blank" line 3)
invoked from within
"blank_out_PGCS_blank $vtsnum $type $::utils::blankout_killpb"
("black" arm line 2)
invoked from within
"switch $::utils::blankout_type {
"rem" {
blank_out_PGCS_remove_menu $vtsnum
}
"black" {
blank_out_PGCS_blank $vtsnum $type $::utils::..."
(procedure "::utils::blank_out_PGCS_GUI" line 192)
invoked from within
"::utils::blank_out_PGCS_GUI"
(menu invoke)Regards

[blutach]

Further to previous post.

DVD was Chronicles of Riddick R4. Had much unreffed material in VMGM, which I think is part of copy protection.

IfoEdit helped by removing the unreffed mat and PgcEdit works fine now - blanks it easily.

If you want to see the original VIDEO_TS.VOB I can upload it to www.yousendit.com (115Mb).

Regards

[r0lZ]

The error is straightforward: PgcEdit cannot rename the VIDEO_TS.VOB file to move it to the backup directory.
It's not a PgcEdit bug, although PgcEdit should intercept the I/O error and display a warning instead of the standard error dialog.

This error may have several causes. The file may be write protected, or may be in use by another program. Sometime, Windows is the guilty: if the source or target folder is opened on the desktop, Windows locks the file for a short time to update the file informations in his display. If the move command is issued just at the same time, the file cannot be moved.

Anyway, I will add my own processing of this kind of errors, so that you will have the choice to retry, abort or ignore the error.


PS. I don't think the copy protection of this DVD is related to the error message. However, I'm interested to have a copy, as such copy protected DVDs are not yet available here, in zone 2. I'll be happy to learn a bit about the method. Maybe I can do something in PgcEdit, too...

[blutach]

I don't think it was copy protection either because we haven't seen ARccOS in R4 either. I just think that it was a VIDEO_TS.VOB with several unreferenced cells, which IfoEdi tfixed straight up (trimmed it from 115Mb to 260k).

Anyway, coming from a DVD Decrypter rip, the structure protection would be omitted.

Regards

[r0lZ]

What I mean is that the error is in no way related to the contents of the VOB file.
The error occured when PgcEdit issued the Tcl command to move the original file in the PgcEdit_backup folder, before blanking the whole titleset. This command is similar to the 'rename' DOS command. It was impossible to move the file because the permission was denied. This is strange, as VobBlanker don't set the Read Only flag on the ripped files. So, this is probally a 'file in use' problem. Are you sure that no programs were running at the same time, possibly using the VOB? Or maybe the PgcEdit's preview?

Another possibility is that the rip was done by another user, and the user who blanked the VOB doesn't have write permission on the original files. But I suppose that you've done the whole process under the same login. Don't you?

[blutach]

No, I was the only user, and I don't believe the preview was on, or PowerDVD had and handle on the files.

If I see the issue again, I will report it. Log it as a non-bug, OK.

Regards

[hf]

Originally posted by r0lZ

Anyway, I will add my own processing of this kind of errors, so that you will have the choice to retry, abort or ignore the error.


I don't know if you were going to add error checking for just this
one case or add it everywhere, but it would be good to add the ability
to retry when making backups after editing buttons (when it says
the vob hasn't been backed up and asks if you want to). I have
several times accidently left PowerDVD paused on a menu and then
get this error when trying to save.

[zacoz]

Originally posted by r0lZ
...A good guide on that matter will be useful. But I will not write it myself, as I'm to busy with the programmation of PgcEdit, and my english is too bad. Sorry.
@r0lZ: Your english is better than you may think - based upon your posts that I've seen anyway. Always understood what you were saying, grammatically wise that is, not always the actual content under discussion.

@CoNS: Thanks for all your questions about this issue while I've been away. The resulting answers help clear up in my mind the "other" scenario's that I hadn't seen so far (thanks to our resident guru's). Will try to squeeze in some work on a guide over next week or so. I imagine that it will need some review, correction & critique from you all to make it to the ranks of a good guide.

[r0lZ]

Thanks.
I may proofread your guide if you wish (not for the english syntax, of course. ;))

[r0lZ]

PgcEdit 0.5.2 beta 2 is here.
(Beta 1 was only an internal release)

I have used the demo version of the Tcl DevKit to improve and optimize the code. As many lines of codes were edited manually, it is possible that I've introduced some new bugs. This is why I prefer to release a beta prior to the final release.

See the history (in the help menu, not on the site) to see the other changes.

You may download the beta, as usual, only via the "All Versions" link of the PgcEdit homepage at VideoHelp (http://www.videohelp.com/~r0lZ/pgcedit/).

[blutach]

Thanks r0lZ - a very extensive change list!

What functions exactly should we be testing for the "optimised code"?

Regards


The Bugcatching Department :)

[r0lZ]

Almost everything has changed. In fact, I have learned with the DevKit that a certain type of syntax is faster.
So, I changed all 'expr' commands (when an expression is evaluated, including simple expressions like incrementing a counter), and many 'if' expressions (when a boolean variable or procedure is checked).
I think that approx one thousand lines were changed, everywhere in the code. I have also changed some lines for other reasons, to avoid potential bugs, or simply to clean up the code.

Unfortunately, the error is human. So, I may have misplaced an edit, or 'fixed' a line in a wrong way. The current version should therefore be used with caution. But, normally, it should work, even better, and a little bit faster than v0.5.1.

The speedup (if any) may probably be noticed in functions that does a lot of calculations and/or tests, but without disk accesses, like the search, or the 'Find unused GPRMs'...

[CoNS]

Ahhh, the subtitle colour import/export function... Thanks, r0lZ :)

When I load a disc in v0.5.2beta2, the menu button scanning at startup is somewhat slower than in version 0.5.1. (I've tried to load the same disc in both versions)

Also, when starting v0.5.2beta2 the first time, an empty subfolder named "--" is created in the PgcEdit directory, next to the "bin" folder?

And a very, very small detail: In the "About" window you mention MPUCoder twice, but spelled differently.

Finally, I have a problem with a specific disc which might be a bug in PgcEdit (or more likely just me not understanding how it works!). The disc has a menu PGC that consists of two cells. In the main window in PgcEdit it says that the PGC has 10 buttons, and in the PGC editor, it says that each of the two cells has 5 buttons. However, the first cell is a warning still pic with no buttons when previewed (and played in my software player), whereas the second cell is the main menu of the disc with 5 buttons. When I select the PGC in the main window in PgcEdit and show the menu buttons, the same menu (from cell 2) is displayed no matter if cell 1 or 2 is selected by me. I can send you the ifos and the menu vob if you like.

EDIT: When I remove the first cell and go back to the main window in PgcEdit, the playback time of the PGC has changed but it still says 10 buttons. When I save the disc, close PgcEdit and reload the disc, PgcEdit now says 5 buttons only...? :confused:

[r0lZ]

Originally posted by CoNS
Ahhh, the subtitle colour import/export function... Thanks, r0lZ :) Oh, yes, in beta 3, I've just added import and export of the color palette in RGB as a text file (same syntax as mpucoder's muxman project file). You may also import directly from a muxman project file... and from an IFO. If you import from an IFO, the first title PGC is used.

When I load a disc in v0.5.2beta2, the menu button scanning at startup is somewhat slower than in version 0.5.1. (I've tried to load the same disc in both versions)That's normal. Now, PgcEdit checks for multiple sets of buttons in each cell. The same is true for BOVs, but there, you have an option.
I will try to optimize the load time...

Also, when starting v0.5.2beta2 the first time, an empty subfolder named "--" is created in the PgcEdit directory, next to the "bin" folder? Noted, and fixed. Thanks!

And a very, very small detail: In the "About" window you mention MPUCoder twice, but spelled differently.Right. Changed both occurences to 'Mpucoder'.

Finally, I have a problem with a specific disc which might be a bug in PgcEdit (or more likely just me not understanding how it works!). The disc has a menu PGC that consists of two cells. In the main window in PgcEdit it says that the PGC has 10 buttons, and in the PGC editor, it says that each of the two cells has 5 buttons. However, the first cell is a warning still pic with no buttons when previewed (and played in my software player), whereas the second cell is the main menu of the disc with 5 buttons. When I select the PGC in the main window in PgcEdit and show the menu buttons, the same menu (from cell 2) is displayed no matter if cell 1 or 2 is selected by me. I can send you the ifos and the menu vob if you like.Note that sometime, the menu buttons are invisible, or displayed only at the verry end of the cell. In this case, PgcEdit will show the end of the cell in the buttons viewer, and you will not notice the difference with the next cell.
But I'll look into it. So, yes, please send me the IFOs and the VOB cells.

EDIT: When I remove the first cell and go back to the main window in PgcEdit, the playback time of the PGC has changed but it still says 10 buttons. When I save the disc, close PgcEdit and reload the disc, PgcEdit now says 5 buttons only...? :confused: I've already noticed some problems with the number of buttons after a cell deletion, or remapping. But I want to rewrite this part completely, so I will probably not fix this problem now...

[blutach]

I know we are in beta 2 testing mode right now, but can I ask for an "add cell" feature which is basically the opposite of the remove cell. This will enable, for example, the re-reference, if desired, of unreferenced material.

Or, should I just forget about this and use AddChapter and the PGC Editor to reference missing cells?

Regards

[lamster]

Found this with 0.5.1; didn't get the next beta yet...

Every time the "Find BOVs" dialog runs, the total number of buttons found is added to the "Found a total of nnn BOVs" message. E.g., if I let it run checking every 20 VOBUs, and it finds 100 buttons, and I then run it again checking every 1 VOBUs, and it finds the same 100 buttons, the message will say that it found 200 BOVs.

[Tobii]

I start PgcEdit and switch on the option "Store PgcEdit_backup into The DVDs Root folders instead of VIDEO_TS ?"... I always get this error:

---------------------------------------
error: can't read "::backupdir": no such variable

can't read "::backupdir": no such variable
can't read "::backupdir": no such variable
while executing
"set old_backupdir $::backupdir"
(procedure "::main::move_backup" line 2)
invoked from within
"::main::move_backup"
(menu invoke)
---------------------------------------

It isn't better, if one only can switch on the option, if the DVD is loaded ?

As well if one wants to deinstall PgcEdit, this error message comes:

error deleting "C:/Dokumente und Einstellungen/Tobi/Eigene Dateien/PgcEdit 0.5.2beta 3/bin/tkimage13.dll": permission denied

[CoNS]

Originally posted by r0lZ
Oh, yes, in beta 3, I've just added import and export of the color palette in RGB as a text file (same syntax as mpucoder's muxman project file). You may also import directly from a muxman project file... and from an IFO. If you import from an IFO, the first title PGC is used.Nice. Very nice indeed. But you keep your newly introduced .clb file format, too, right? I'm trying to convince mpucoder and Paddington to implement support for this file.Originally posted by r0lZ
So, yes, please send me the IFOs and the VOB cells.Will do ASAP. The menu vob is 59.2 mb and contains four LUs with almost identical warnings/menus in four different languages. Do you want the whole thing via yousendit.com or should I extract one of the LUs for you? How do I do the latter? (blank the rest of the LUs using VobBlanker?)

[r0lZ]

Originally posted by blutach
I know we are in beta 2 testing mode right now, but can I ask for an "add cell" feature which is basically the opposite of the remove cell. This will enable, for example, the re-reference, if desired, of unreferenced material.

Or, should I just forget about this and use AddChapter and the PGC Editor to reference missing cells?

Regards That's not easy. It is possible to program an Add Cell easily, but you will be able to add only referenced material.
The problem with unreferenced material is that... it is unreferenced. I have no way to know that it is in the VOBs, and no way to know his length, LBAs, etc...
So, if the user inputs an unreferenced VOB/Cell ID, I will be unable to correctly fix the IFOs. You will need to do a mock strip anyway. So, I prefer to leave this work to IfoEdit, AddChapter or VobBlanker.

Anyway, I don't want to work further in the PGC Editor for now, because I want to rewrite it completely...

[r0lZ]

Originally posted by lamster
Found this with 0.5.1; didn't get the next beta yet...

Every time the "Find BOVs" dialog runs, the total number of buttons found is added to the "Found a total of nnn BOVs" message. E.g., if I let it run checking every 20 VOBUs, and it finds 100 buttons, and I then run it again checking every 1 VOBUs, and it finds the same 100 buttons, the message will say that it found 200 BOVs. Well, it's not really a bug. The total number of buttons is displayed only for feedback, and is not used internally.
It is the sum of the buttons found by the find BOVs GUI. If you want to reset it, just quit the function, and open it again.

[EDIT:] I've changed my mind! Now, the total number of buttons is resetted to 0 everytime you press the Scan button. It's more useful now.

[r0lZ]

Originally posted by Tobii
I start PgcEdit and switch on the option "Store PgcEdit_backup into The DVDs Root folders instead of VIDEO_TS ?"... I always get this error:

---------------------------------------
error: can't read "::backupdir": no such variable

can't read "::backupdir": no such variable
can't read "::backupdir": no such variable
while executing
"set old_backupdir $::backupdir"
(procedure "::main::move_backup" line 2)
invoked from within
"::main::move_backup"
(menu invoke)
---------------------------------------

It isn't better, if one only can switch on the option, if the DVD is loaded ?

As well if one wants to deinstall PgcEdit, this error message comes:

error deleting "C:/Dokumente und Einstellungen/Tobi/Eigene Dateien/PgcEdit 0.5.2beta 3/bin/tkimage13.dll": permission denied Thanks for the report, Tobi. The backup problem should be easy to fix. For now, if you want to change the location of the backup directory, you may edit the configuration file manually, or -maybe- just close PgcEdit after the error, and launch it again.

[EDIT:] Problem fixed now.


The uninstall problem is more complex. I don't know why it happens. Maybe you have to call the uninstall routine after a reboot, so that the dll will not be in use. The tkimgbmp13.dll (not tkimage13.dll, which doesn't exists) is used by the menu buttons viewer to load the background image. So, if you don't use the viewer, you should be able to uninstall PgcEdit without problem.

[EDIT:] No, the dlls in the bin directory are in use when PgcEdit is opened, even if you haven't used the menu viewer. So, the only way to delete the DLLs is to do it manually, when PgcEdit is not running.
I have changed the uninstall routine so that the error message will not be displayed anymore, and added a note asking to remove the bin directory manually.

[r0lZ]

Originally posted by CoNS
Nice. Very nice indeed. But you keep your newly introduced .clb file format, too, right? I'm trying to convince mpucoder and Paddington to implement support for this file.Yes, the raw format is kept. When exporting, you will have to select which file format you want.
When importing, the file format is determined automatically.

Will do ASAP. The menu vob is 59.2 mb and contains four LUs with almost identical warnings/menus in four different languages. Do you want the whole thing via yousendit.com or should I extract one of the LUs for you? How do I do the latter? (blank the rest of the LUs using VobBlanker?) You may strip the LUs with IfoEdit, and remove the cells that are not problematical with VobBlanker. I just need the 2 cells that caused the troubles.
Please verify that the problem is still present after the LUs and cells strips.

[doomer2]

Using 0.5.1, and running the Find BOV's function, some dvds are giving the following error:

Error loading NAV pack from "BLAH.VOB" at sector (LBA) NNNN: NAV Pack identifier not valid. VOB doesn't match the IFOs.

The only option given is "OK". On some dvd's, this happens many times, and it's kindof tiresome to have to continue hitting OK so many times. Can you add an "Abort" button to the dialog, or maybe an "Ignore Errors" button so the scan can continue and will skip the popup about this type of error?

Also, is there any way to get more information on exactly what it doesn't like about the VOBs? I'd like to fix these problems if I can, but don't have a clue where to start looking.

Thanks!

[r0lZ]

Originally posted by doomer2
Using 0.5.1, and running the Find BOV's function, some dvds are giving the following error:

Error loading NAV pack from "BLAH.VOB" at sector (LBA) NNNN: NAV Pack identifier not valid. VOB doesn't match the IFOs.

The only option given is "OK". On some dvd's, this happens many times, and it's kindof tiresome to have to continue hitting OK so many times. Can you add an "Abort" button to the dialog, or maybe an "Ignore Errors" button so the scan can continue and will skip the popup about this type of error?

Also, is there any way to get more information on exactly what it doesn't like about the VOBs? I'd like to fix these problems if I can, but don't have a clue where to start looking.

Thanks! OK. I will try to suppress the messages.

This message is displayed when the infos in the IFOs on the VOB files are wrong. Every VOBU is referenced in the IFOs, and must begin with a Nav Pack. When parsing the VOBs, PgcEdit uses the infos in the IFOs to speedup the scan process. But it cannot handle the VOBs if the infos are wrong.
You should try to do a mock strip (http://forum.doom9.org/showthread.php?s=&threadid=84097&highlight=mock+strip) to fix the problem.

[r0lZ]

PgcEdit 0.5.2 beta 4 is there.

It fixes the problems discussed above.

@doomer2
I've not tested the suppression of the multiple error messages when parsing the BOVs. Please let me know if it works better now.

[CoNS]

Originally posted by r0lZ
You may strip the LUs with IfoEdit, and remove the cells that are not problematical with VobBlanker. I just need the 2 cells that caused the troubles.Ok, I've used VobBlanker only and blanked all other cells than the two in question. I'm sending the blanked menu vob and the ifos via yousendit.com, and you should recieve a mail with a link soon.

EDIT: I'm sending it via normal email to pgcedit(at)tiscali(dot)be... Let me know if you don't receive it.

For your info, VobBlanker also says that the two cells hold 10 buttons. A strange thing, though: VobBlanker says that the VTSM in question has 1 LU which has 6 menu PGCs. PgcEdit says that there're 6 LUs (all English, even though the disc only has Nordic menus).Originally posted by r0lZ
Please verify that the problem is still present after the LUs and cells strips. I've checked and the "problem" is still present (PgcEdit still says 10 buttons, 5 buttons on each cell).

BTW, the disc is "The Adventures of Tin Tin Disc 2" PAL R2, Nordic/Scandinavian edition, just in case you have the disc. Perhaps the Belgian/French version is authored the same way?

[zacoz]

Originally posted by CoNS
BTW, the disc is "The Adventures of Tin Tin Disc 2"
Ah.....This brings back memories. I used to read Tin Tin & Snowy's adventures when I was a kid. I didn't know they had been made into an animated series.

Sorry about the nostalgic off topic post.

[CoNS]

The animated series is quite good, actually... It's for my kids, but it brings back memories for me, too, as I used to read the comic books when I was a kid myself. :)

[r0lZ]

Tintin is a national stardom, here in Belgium! :) But I prefer the books.

I have looked at the stripped DVD you send. Everything seems normal.

1) There is only one LU. Where did you find 5 LUs? All LUs labels are "LU 1 (en)".
The LU code is 'en', but this doesn't matter, as the language code is used only when there are several LUs, to find the right one. If there is only one LU, it will be used anyway, regardless of his code.

2) The "VTSM 1, LU 1 (en), 3 (0:57) 10b." has two cells, with 5 buttons in each cell, giving a total of 10 buttons. Therefore, the number of buttons displayed in the PGC Selector is 10, as it should be.
If you look at the cells list in the PGC Editor, you will see the details of the number of buttons for each cells: cell 1 has 5 buttons, and cell 2, also 5 buttons. That's correct.

3) The first cell has buttons appearing only when the album's covers are displayed. The beginning of the cell is just an intro, without buttons. Therefore, when you enter the menu buttons viewer, the background image displayed under the buttons is the first image found after the buttons are defined. This image is almost the same as the first image of the next cell.
You may use the arrow buttons to select another background image, but if you use the back arrow, you will see the buttons over a wrong background.

4) There is indeed a little bug. The number of buttons in the PGC Selector is not correctly refreshed after a delete cell. It should be 5 instead of 10. But, as I explained before, this has no consequence, and I don't want to work anymore on the old PGC Editor, as I will rewrite it completely anyway.
If you want to see the right number of buttons, save the DVD and reload it.
[EDIT:] I have changed my mind, because it was easy to fix the problem. The total number of buttons is now updated after a Remove Cell.

[CoNS]

Originally posted by r0lZ
There is only one LU. Where did you find 5 LUs?Oops, did I write that? :o You're right, of course!

Originally posted by r0lZ
The first cell has buttons appearing only when the album's covers are displayed. The beginning of the cell is just an intro, without buttons. Therefore, when you enter the menu buttons viewer, the background image displayed under the buttons is the first image found after the buttons are defined. This image is almost the same as the first image of the next cell.Ahh, ok, then I guess it's a bad idea to blank or remove the first cell as I've already done?!! I want to get rid of the warning (the "intro" in the cell), so perhaps I should cut the playback of that cell using VobBlanker instead of removing the cell in PgcEdit? Can VobBlanker do that?

EDIT: Hmmm, when I try playing the disc in my software player after simply removing the first cell, it seems to play fine anyway, with the menu and all?

Usually, these warnings have their own cell, PGC or even VTSM or VTST. This is actually the first time I've seen a warning (playing 17 seconds) being the first part of some video played ending up with a menu - all in the same cell.

[zacoz]

PgcEdit 0.5.2 beta 4 is there. @r0lZ: All 0.5.2 betas seem to be missing. I picked up 0.5.2 beta 2 earlier today but now even it is gone.

[r0lZ]

No, the beta 4 is on the VideoHelp site.
It is not on the other homepages (because on Tiscali, I've reached the size limit, and the homepage in Poland is a mirror of the Tiscali site)