PgcEdit 0.5

[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 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 /?"

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

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 ), 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]

Originally Posted by r0lZ

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]

Originally Posted by zacoz

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]

Originally Posted by 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

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

Originally Posted by jeanl

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:
  

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.

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

Originally Posted by jeanl

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