PgcEdit 0.5

[jeanl]

YOu can say Yes, or No, it does not matter if you don't intend to run vobblanker after that. If you say yes, AND you run vobblanker after that, the cell will be removed from the VOB. But you don't really need that for an FBI warning, because it's a very small cell usually....
YOu'll be surprised to see how fast you learn PgcEdit, the learning curve isn't just with PgcEdit though, it's with the whole entire DVD structure thing. That takes a while, but in a couple month, you'll be swimming in there like a fish in the ocean! ;)
jeanl

[r0lZ]

You've used up all the ctrl and/or alt combinations? Or don't want to use them?Some Ctrl or Alt keys should still be free. But I like the "`" key because the preview is often used, and you don't have to press two keys to launch it.
However, I can add another shortcut as well, for non-US keyboards.

[CoNS]

thx r0lZ, that'd be great!

[Wheelie4]

Thx jeanl. :)

[goonix]

Only a few small issues:

If I use the search function in pgcEdit (0.6beta5) the found command line numbers are wrong, i.e. one more than the real number.

If I search for the word "button" pgcEdit finds all occurences of the word "button" even in button commands. But in many cases, the found button commands are wrong.

Clicking on the "found button" results, pgcEdit opens the menu button window. Sometimes following message is displayed:

Warning: The SPRM 8: highlighted menu button number is out of range!
SPRM 8 button value: 10240 (button 10)
Valid button number range for this menu: 1 to 6

And there are really only 6 buttons.

Additional the displayed button group of the menu button window is not set according to the found button result.


goonix

[zacoz]

If I use the search function in pgcEdit (0.6beta5) the found command line numbers are wrong, i.e. one more than the real number.Tested here using PgcEdit 0.6.7 with same result.
Clicking on the "found button" results, pgcEdit opens the menu button window. Sometimes following message is displayed:
Warning: The SPRM 8: highlighted menu button number is out of range!
SPRM 8 button value: 10240 (button 10)
Valid button number range for this menu: 1 to 6
And there are really only 6 buttons.Tested 2 DVD's here without this problem.
@Goonix: For the Pgc's where you are having this issue does the Pgc Selector indicate 10 buttons or 6 buttons ? Are there multiple Program/Cells involved ?
Additional the displayed button group of the menu button window is not set according to the found button result.Seems that it always opens the Menu Buttons editor displaying Program 1 Cell 1.

[goonix]

@zacoz

The DVD in work is "Mars Attacks! R2"

In the pgc selector pane there are 180 buttons in 55 cells.
The opened menu button editor windows trys to show the correct cell number. But there is a problem counting the cells from 0 or from 1.
After further investigation I found the button command of the "found button" window displays the command of the next cell same button number.
And the 10 buttons error occurs if the next cell has 10 buttons, but the current cell has only 6.

So it is maybe related to the first issue in my above post.


goonix

[zacoz]

That makes sense why i didn't encounter the error - as the DVD's I tested had the same number of buttons in adjacent cells.

Seems harmless (if a little annoying) issue, so r0lZ will probably take a look when he works on PgcEdit next.

He'll also no doubt comment when he takes a break from enjoying the fraction of a life we leave him with. ;)

[r0lZ]

Yes, I already know the problem with the line numbers in the search function, and the related problem with the wrong line being highlited.
I will look at the problem with the menu.
Thanks goonix and zacoz!

[goonix]

Tested with v0.6.0beta6.
Search all function works perfectly now.

Only one very little issue remains:
If I search for a very common word e.g. "link" then sometimes more than 1000 results will be found.
Then the result list is cut at the end. But this seems to be a restriction of Tcl/Tk.
And such search isn't really useful.

Many thanks r0lZ!

goonix

[r0lZ]

If I search for a very common word e.g. "link" then sometimes more than 1000 results will be found.
Then the result list is cut at the end. But this seems to be a restriction of Tcl/Tk.Well, I was not aware of this limitation. Maybe I can change the listing made of buttons to a classic listbox. If I have some time, I will do it. Maybe also the search function will be faster (Most of the time is devoted to building the interface).

[goonix]

The search function is fast enough in my opinion.
And the buttons in the listbox are very useful. Please don't change it!
It doesn't make sense to search for a command with such an amount of findings.

goonix

[r0lZ]

The search function is fast enough in my opinion.I don't think so. If the DVD is very large, and there are many occurences of the search string, it takes ages.
And the buttons in the listbox are very useful. Please don't change it!Too late! I have already changed the GUI. But don't worry: you can still click on the references to jump to them. See v 0.6.0 beta 7 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta7.zip).

[selyb]

is there any difference between the files extracted from the winexe and the files in the source zip?

[r0lZ]

is there any difference between the files extracted from the winexe and the files in the source zip?No, the files are exactly identical. But the behaviour of some parts of the code is different if the app is wrapped. For example, the install submenu is present only when PgcEdit is run from the wrapped exe, under Windows.
Also, some files are not included in some distribs, if they are not needed. In the source zip, all files are present.

[2COOL]

@blutach

PgcEdit's reference manual looks great!

If you are working on an update, can you insert example images of the color coding highlights in Main window, goto calling command dialog, and search log? did I miss anything? Anyways, here's a post (http://forum.doom9.org/showthread.php?p=650383#post650383) for some reference.

[jinjin_jp]

@r01Z
Please consider the function of setting default stream (audio, sutitle) for Re-Authored by DVDShrink (if possible, by others).

A little before I backed up by DVDShrink(Re-Authore), but I've forgot to set the default stream as usual, so I corrected IFO after processes.
Then I thought it would be very useful if possible to set the default stream by PgcEdit.
Even it needs only correction of IFO a little, but it needs to know about IFO a little, if not it needs long time for re-processing of DVDShrink.
I think it is possible to add pre-command of two lines for each title like below,
.....(SetSTN) Set Audio stream = ?
.....(SetSTN) Set Sub-picture stream = ?, on
................< ? is selected favorite>

Sorry to request selfish hope.

[blutach]

@jinjin_jp - you can do this already with the new Jump to PGC Upon DVD Insert macro.

Just trace through your DVD to the main menu and then click on the audio menu and pick the stream you want. Do the same for subpictures. Return to the main menu. The streams you want will be set.

Then execute the macro.

By the way, DVD Shrink remapping streams is not good to do IMHO - see my discussion here (http://forum.digital-digest.com/showthread.php?s=&threadid=45228).

Regards

[r0lZ]

@blutach: jinjin_jp was talking about reauthored movies. You don't have menus anymore.

@jinjin_jp: I think it easy enough to do it yourself. After all, it's only one (or two) SetSTN commands to insert in the pre-commands of the main title.
For me, it's not so simple, because I need to check if the SetSTN command already exists. But maybe I will do that. Not soon, anyway...

[jinjin_jp]

@r01Z
I understood. Surely it is difficult if considering various cases to be checked.

@blutach
About remapping streams I noticed interesting thing in DvdReMakePro which have the function of removing stream after ver.3.
When using this function, "Delete track" is selectable from last stream, but from middle stream "Delete track" is glay out and "Disable track" is only selectable. I think this is the same thought as yours.

[r0lZ]

I don't use DVDReMake anymore ;) , but I believe that it does that this way because it is uable to remap the streams. If you remove a stream (before the last one), the references to the remaining streams are wrong, and remapping them is not easy, especially if there are indirect SetSTN commands somewhere. (Indirect commands = commands using a GPRM instead of a constant value)

[jinjin_jp]

@r01Z
Thanks for adding the explanation.

[blutach]

And yes, sorry gentlemen. I should have read closer. I see now the re-authored.

But jinjin, I think you know you can do this automatically in DVD Shrink.

http://www.dvdshrink.info/guides/forcing_subs.gif

And if you forget, it's only 1 command to add in before the title.

Regards

[r0lZ]

Yes, it's a relatively long work for me for a little advantage.
And I prefer to work on more useful additions, like the new function I just wrote, available in PgcEdit 0.6.0 beta 14 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta14.zip). This function allow you to renumber the Titles in the DVD. I hate these DVD with title 1 being a logo, and with a main movie title number being 2 or more! The new function (Utilities -> Remap Title numbers) takes care of the Jump_TT commands in the VMG, including in menu buttons. Enjoy...

[jinjin_jp]

@blutach
Yes, I know. I've forgot to set default stream this time, so corrected IFO.

[blutach]

OK to both. Goodness r0lZ, v6 won't get released LOL. But I gotta agree. I hate it when title 1 is right down the bottom in VTS 23.

More work on the help file, I guess :(

Regards

[r0lZ]

More work on the help file, I guess :( Only if you want!

I will probably release v6 on july 7, because I have inserted a front page on my site, regarding the pattents european directive. I will remove it and release PgcEdit 0.6 when this page will be obsolete, on july 6.

[blutach]

Tell you what I reckon would be useful:

If you have killed enough material to make whole titlesets unreferenced, then a little utility to pull them out of the structure (as you know, it's only 3 bytes in VIDEO_TS.IFO that need changing), moving the VOBs, IFOS and BUPs to a special backup folder.
Whaddya reckon?

Regards

[blutach]

Only if you want!Has to happen. Will have more time this week.

G'night from here.

Regards

[r0lZ]

If you have killed enough material to make whole titlesets unreferenced, then a little utility to pull them out of the structure (as you know, it's only 3 bytes in VIDEO_TS.IFO that need changing), moving the VOBs, IFOS and BUPs to a special backup folder.Well, it's not really simple. I must check for references to this titleset in the VMG. Only Jump_TT commands are able to call a title by his title number, while there are many commands able to call something in a titleset.
Also, removing the last titleset is relatively simple, but removing any titleset would require to fix the references to the next titlesets.

I think that an unreferenced titleset is not so annoying, because, when blanked, it doesn't use a lot of space, and when playing the DVD, you will not notice his presence.

But I may add a simple Remove Last Titleset function, without checks for references. Is it enough for you?

[lovelegend]

I found a little bug (not sure if it's been reported): For subpicture color lookup table, when I pressed import and choose an IFO file, the color lookup table was changed. However, when I pressed OK, saved the changes and reopened the DVD folder, the color lookup table changed back to the old table. (But it has no problem by using "Copy All" and "Paste All" buttons)

[r0lZ]

Right. Will have a look.

[r0lZ]

PgcEdit 0.6.0 beta 15 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta15.zip) is out.

I have fixed the import color table from IFO bug, and added the function to delete the last VTS in the DVD.
Nothing new in the Burn DL DVD function.

[frank]

After program entry it must be:

# Parse arguments
if {$argc == 1 && ([lindex $argv 0] == "/?" || [lindex $argv 0] == "-h")} {
puts "PgcEdit v $::program_version"
puts "Command line usage:"
puts "> PgcEdit \[\"DVD pathname\"\]"
puts "or"
puts "> PgcEdit \[\"DVD pathname\\any file\"\]"

[r0lZ]

Right. Small bug. I wonder if anyone has already launched PgcEdit with "PgcEdit /?" :)

[zacoz]

Sorry for lateness in mentioning this - I know PgcEdit 0.6.0 final is on horizon. :cool:

PgcEditPreview has always utilised all available CPU Usage (normally 85-99%) - this normally produced output in the range of 20-30 fps. Since PgcEdit 0.5.7 final (which from changelog appears to be when PgcEditPreview 1.9 was implemented) the output has dropped to the range 8-11 fps. :( CPU Usage remains as before.

I know I'm using what's probably considered by most an old system (Pentium III 450MHz 384MB WinXPsp2 :eek: ), however this is a significant drop in speed for no noticable tradeoff in functionality etc (from a user perspective). As I type I'm wondering if it was to do with Linux/Mac compatibility being improved.

@r0lZ / jeanl: Post is to highlight the issue rather than complain. I still use preview - just drag the slider along manually more often, as I can't be bothered waiting for it to play through at slow speed.

[edit: BTW it's the same whether I run PgcEditPreview directly or through PGCEdit]

[blutach]

Well, it's not really simple. I must check for references to this titleset in the VMG. Only Jump_TT commands are able to call a title by his title number, while there are many commands able to call something in a titleset.
Also, removing the last titleset is relatively simple, but removing any titleset would require to fix the references to the next titlesets.

I think that an unreferenced titleset is not so annoying, because, when blanked, it doesn't use a lot of space, and when playing the DVD, you will not notice his presence.

But I may add a simple Remove Last Titleset function, without checks for references. Is it enough for you?It should be. But what I do is this:

Assuming all the latter titlesets are unreferenced, I go into VIDEO_TS.IFO and simply change bytes:
0x003e of VMGM_MAT
0x0000 of VMG_PTT_SRPT and
0x0000 of VMG_VTS_ATRT
to suit my purposes. Isn't this easy enough to implement? Simply ask the user how may VTS's he wants to keep and bingo, out go the rest, with their IFOs,VOBs and BUPs stored somwehere in case of error (prob with an automatic incremental backup).

Regards

[blutach]

Speaking of Preview, has anyone also experienced the interesting effect of buttons from the first VOBU of the next cell sometimes being showed right at the end of a menu "intro" cell?

Regards

[r0lZ]

Version 1.9 of the preview added these functionalities:
- Displays the menu buttons outlines in info mode.
- MFC42.DLL is now dynamically linked with the executable.

Maybe the new exe is spending too many time to look at the buttons. If so, it should be relatively simple to fix that problem.
zacoz, do you use the preview with the info window opened?

Anyway, the Preview is Jeanl's work. I can't fix that myself.

[r0lZ]

@blutach: You forgot that the references to deleted titles must be removed from the VMG_TT_SRPT table. The number of Title Play Maps in this table is not the number of Titlesets!
The Delete Last Titleset function has been implemented in beta 15.

[jeanl]

PgcEditPreview has always utilised all available CPU Usage (normally 85-99%) - this normally produced output in the range of 20-30 fps. Since PgcEdit 0.5.7 final (which from changelog appears to be when PgcEditPreview 1.9 was implemented) the output has dropped to the range 8-11 fps. :( CPU Usage remains as before.
Zacoz. Can you use the preview from an older version and check for sure that it's faster? If that's the case, then we need to investigate! Also, are you sure you're not using the "no overlay mode" (in the Preview menu, the "disable overlay" option)? On my machine, if I disable overlay, things are much much slower. Statically linking mfc shouldn't alter speed at all. The button lookup mechanism is also very fast, so I'm really puzzled.
Jeanl

[jeanl]

Speaking of Preview, has anyone also experienced the interesting effect of buttons from the first VOBU of the next cell sometimes being showed right at the end of a menu "intro" cell?

Regards
Yes, that's a bug, and one that won't be easy to fix (because of the strange way in which DVD2AVI reads the video data and the navpacks). Maybe it's not worth showing the buttons in the preview after all, since PgcEdit does that very well anyway.
jeanl

[r0lZ]

I thought blutach was speaking of menubuttons appearing in the menu buttons viewer of PgcEdit, not in the cell or PGC preview. Blutach, can you confirm?
If it is the case, the Preview.exe is not guilty, and it's probably a bug in PgcEdit. But I can't reproduce it.

[blutach]

I am speaking of seeing buttons in preview mode (not menu preview). Like when you press `

I definitely like the fact you can see them now. This is just a tiny little bug.



As for the deleted titles, when you use IfoEdit to change the number of titles, it automatically deletes the titles from VMG_PTT_SRPT. I guess that why I presupposed this was so easy. I see now, the need to do it manually. No big deal.

Regards

[zacoz]

Zacoz. Can you use the preview from an older version and check for sure that it's faster? If that's the case, then we need to investigate! Also, are you sure you're not using the "no overlay mode" (in the Preview menu, the "disable overlay" option)? On my machine, if I disable overlay, things are much much slower. Statically linking mfc shouldn't alter speed at all. The button lookup mechanism is also very fast, so I'm really puzzled.
Jeanl Preview from PgcEdit 0.5.7b3 and earlier all run faster, whether run from PgcEdit or exe directly (and dragging VOB file onto window).
Direct Draw overlay is not disabled and if disabled there is no noticable difference.
There seems to be no noticable difference whether Info window is displayed or not
Same issue is evident whether PGC being previewed contains buttons or not
MFC42.dll versions located on my system are:
http://lorensmith.customer.netspace.net.au/mfcversions.jpg To test further is it viable to disable the button lookup mechanism and compile to see if that makes a difference ? If so you could 'yousendit' to me or post a link

[r0lZ]

Zacoz, have you updated your hardware (graphic card) or DirectX version?
When I bought my new computer, the preview was slower to start, although the hardware is now most powerful. Using the No Overlay mode solved the problem for me.
I know the symptoms you describe are not the same ones, but the cause may be similar.

[zacoz]

I have recently reinstalled OS (about a week ago), however the issue existed prior to re-install. I have reproduced the problem yesterday and today with pre and post 0.5.7 final versions (fast and slow respectively) - both days testing versions within minutes of each other and in various orders. As mentioned, I've tried with and without overlay option with no resolution.

I'm confident therefore that it's a change in the program that is causing the issue. Of course my system configuration may be somewhat unique in reacting to the change.

System is Pentium III 450Mhz Asus P3B-F MoBo Radeo 9200 SE AGP2x Windows XP Pro sp2 DX9.0c No overclocking or unusual tweaks etc.

[jeanl]

OK zacoz, you convinced me. I need to look into it. I'll compile several versions and send them to you. You should probably remove your email address from the forum, if you don't want to get spammed like crazy. I wrote it down...
Jeanl

[zacoz]

if you don't want to get spammed like crazy....and that would be different from now how ? ........lol (that's very much my spam collecting account already). I should have thought, I could have pm'ed a cleaner email addy to you anyway - doesn't matter.

[jeanl]

Well, I sent you a zip at that address so you'll have to dig it up from the slime!
jeanl