PgcEdit v0.4 [Archive] - Page 11

lamster

30th January 2005, 05:14

I tried loading a VIDEO_TS directory and saving it without making any changes, then did a binary compare of the original IFOs with what was saved. There were a few changes.

The DVD was Harry Potter & the Prisoner of Azkaban (region 1). VTS_02_0.VOB and VTS_03_0.VOB are both of size 0.

There were 2 changes in VIDEO_TS.IFO, in the Video Title Set attribute table:
VTS_2 Video Attributes of Title (VTSTT_VOBS) from x4e80 to 4e90.
ditto for VTS_3.

In both VTS_02_0.IFO and VTS_03_0.IFO, the start sector of VTSM_VOBS was changed from 0 to 8.

r0lZ

30th January 2005, 11:40

Originally posted by lamster
I tried loading a VIDEO_TS directory and saving it without making any changes, then did a binary compare of the original IFOs with what was saved. There were a few changes.

The DVD was Harry Potter & the Prisoner of Azkaban (region 1).

There were 2 changes in VIDEO_TS.IFO, in the Video Title Set attribute table:
VTS_2 Video Attributes of Title (VTSTT_VOBS) from x4e80 to 4e90.
ditto for VTS_3.Strange. Could you verify the video attribute in VTS_02_0.IFO and VTS_03_0.IFO in VTSI_MAT table, at offset 0x200? They must match the attributes in VIDEO_TS.IFO.

[EDIT:] The streams attributes of the VTSI_MAT table are correctly copied to the VMG_VTS_ATRT table when the DVD is saved. For consistency, this must be done. It's not a PgcEdit bug, but an authoring error in your original DVD, fixed by PgcEdit! :)

VTS_02_0.VOB and VTS_03_0.VOB are both of size 0.

In both VTS_02_0.IFO and VTS_03_0.IFO, the start sector of VTSM_VOBS was changed from 0 to 8. This is normal. It a VOB file exists, even an empty file, the start sector of VTSM_VOBS must point to the VOB file. This pointer is calculated by the internal Get VTS Sectors function when the DVD is saved. If you delete the empty VOBs, the pointer will be 0.

[EDIT:] Another little authoring bug in your DVD, also fixed by PgcEdit! :)

r0lZ

30th January 2005, 11:45

PgcEdit 0.4.9 released.
Added the "DVDShrink Streams Remapping" macro to check if the DVDShrink option "Logical remapping of enabled streams" may be safely used in full disc mode with the current DVD.
Added a button "ISO639 language codes" in the Trace's Virtual Player Setup GUI to show the valid language codes.
The PGC breakpoints are now cleared when a new DVD is loaded, but still not when the same DVD is reloaded (including after a restore backup).
Burn DVD: Added an option to mount the ISO image using Daemon-Tools.
Burn DVD: Added a confirmation dialog if the ISO image already exists.
Burn DVD: The VobBlanker_backup folder is now automatically excluded of the ISO image, like the PgcEdit_backup folder.
Burn DVD: Miscellaneous enhancements and little bug fixes.
Burn DVD Bug fixed: The abort button did not kill the mkisofs process in the standalone exe.
Burn DVD: Free disk space was wrong on Win 9X and on foreign Win 2K/NT/XP.
Note: The free disk space is not tested anymore on Win 95/98/ME/SE!
Shortcut to select all the Trace output changed to Control-Shift-A to avoid a bug with Control-a.
Also, look at the homepage. There are updated and new guides...

blutach

30th January 2005, 12:42

Brilliant r0lZ - many thanks.

However, using the DVD Shrink remapping I get the following error:

can't read "used": no such variable
can't read "used": no such variable
while executing
"if {!$used} {
for {set vts 1} {$vts <= $:: pgcs(numvts)} {incr vts} {
for {set ttn 1} {$ttn <= $:: pgcs($vts,numpgcs)} {incr ttn} {
set used [s..."
(procedure "::macros::check_streams_remapping" line 9)
invoked from within
"::macros::check_streams_remapping"
(menu invoke)
Any clues what this is?

Regards

r0lZ

30th January 2005, 13:59

Obviously, it's a bug!

I will post immediately a new version...

r0lZ

30th January 2005, 14:34

PgcEdit 0.4.9.1 released.

This is a last minute bugfix for 0.4.9. It fixes the bug in the DVDShrink Streams Remapping macro, found by Blutach.

If you downloaded PgcEdit 0.4.9, please download the update now. Sorry for the inconvenience.

2COOL

31st January 2005, 00:54

r0lZ,

Just so people can better navigate in your growing thread, you should place hyperlinks to the threads that you posted new versions in your first post.

If I wanted to look for stuff on 0.4.6, I would have to manually search the whole thread looking for its starting point. It's at 26 pages now!:eek:

r0lZ

31st January 2005, 10:15

OK. Done (http://forum.doom9.org/showthread.php?s=&threadid=85329&perpage=20&pagenumber=1#post569497). :)

2COOL

31st January 2005, 19:41

:thanks:

blutach

1st February 2005, 00:09

From VobBlanker 1.6.0.4 changelog:

"Change: VobBlanker_backup is now created in the same folder than VIDEO_TS, instead of inside VIDEO_TS, due strange behaviour in Nero if a VOB exists in backup folder"

Might you need to change the burning exemptions in PgcEdit to ignore this folder too? Otherwise, might it result in VobBlanker_backup being created in the ISO image in the root directory?

Regards

r0lZ

1st February 2005, 09:08

No. The backup will be excluded, regardless of the folder it is located in. The exclusion is done by filename, without the path.

Surf

1st February 2005, 15:07

Hi guys & dolls,

This' what I faced last night with v 0.4.9.1

mkisofs log for DVD "explicit XXX"
From: "F:\SHRUNK_XXX"
DVD-TEXT General Name: ""
Provider ID: ""
Number of VTS: 3
Output file: "G:\XXX.ISO"
Volume label: "XXX_vol_12" (i made them up :D)

2 [main] mkisofs 1256 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
818 [main] mkisofs 1256 open_stackdumpfile: Dumping stack trace to mkisofs.exe.stackdump
****** ERROR returned by mkisofs! ******

Ran out of time to investigate....

2COOL

1st February 2005, 19:24

http://img183.exs.cx/img183/9008/image0101my.gif

Can we have a 1-click automated blanking option to do this? Ideally, at time of detection dialog.

r0lZ

1st February 2005, 20:01

Obviously, it's a mkisofs problem. Maybe your DVD has something illegal that makes mkisofs crash. Or you found a mkisofs bug.

Anyway, I can't do anything. I'm not the author of mkisofs. Sorry.

Originally posted by Surf
Hi guys & dolls,

This' what I faced last night with v 0.4.9.1

mkisofs log for DVD "explicit XXX"
From: "F:\SHRUNK_XXX"
DVD-TEXT General Name: ""
Provider ID: ""
Number of VTS: 3
Output file: "G:\XXX.ISO"
Volume label: "XXX_vol_12" (i made them up :D)

2 [main] mkisofs 1256 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
818 [main] mkisofs 1256 open_stackdumpfile: Dumping stack trace to mkisofs.exe.stackdump
****** ERROR returned by mkisofs! ******

Ran out of time to investigate....

r0lZ

1st February 2005, 20:05

Originally posted by 2COOL
http://img183.exs.cx/img183/9008/image0101my.gif

Can we have a 1-click automated blanking option to do this? Ideally, at time of detection dialog. I'll see what I can do. But that may be difficult: when this dialog pops up, the DVD is not already totally loaded, therefore it may be difficult to apply the Blank Out function at this time.

[EDIT:] Done. The dialog is now a yes/no requester asking if you want to delete the VOBs, and remove the references in the IFOs.

blutach

2nd February 2005, 00:04

AFAI can see, r0lZ is warning here about Nero's rubbish. I have burned a couple of disks with 4.9.1 and there are no problems.

Just click on OK. If you want little 10k stubs, do it before the burn - but instead, if you have turned on the burned with 32k gap option, PgcEdit will insert a 16k "pad" (with the stub, the pad will be 11k).

If you are a Nero user (AIPU - figure that acronym out! :) ), just say OK when Nero whinges.

Regards

blutach

2nd February 2005, 00:08

@r0lZ - thanks for the info re VobBlanker_backup.

@everyone - a tip: If you enter a name for the disk under Utilities --> Set DVD-Text General Name, when it comes to burning, all the names are already filled in. This is very sweet! The text you enter doesn't even need to be upper case or have underscores. Try it!

Regards

r0lZ

2nd February 2005, 00:37

Note that the last version do not impose to type upper case characters anymore in the label field. mkisofs allow to use any character in the label. But, as the label may be used on some systems as the mount directory, illegal characters in a filename (like /\*) are still prohibited.

2COOL

2nd February 2005, 01:44

Originally posted by r0lZ
[EDIT:] Done. The dialog is now a yes/no requester asking if you want to delete the VOBs, and remove the references in the IFOs. Many thanks my friend!

Surf

2nd February 2005, 18:41

Regarding my earlier glitch:

2 [main] mkisofs 1256 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
818 [main] mkisofs 1256 open_stackdumpfile: Dumping stack trace to mkisofs.exe.stackdump
****** ERROR returned by mkisofs! ******

It's my fault, didn't tailor it properly. Sorry, I had a panic attack I supposed. For I just updated to the latest version of nero's, wanting to compare recode with shrinky.

r0lZ, I know u din write IMGtool, I was fishing for advice.:p

r0lZ

2nd February 2005, 23:51

phew! I prefer that!

BTW, it is not needed to have all the ImgTools Classic stuff installed. If you want, you can copy mkisofs.exe and cygwin1.dll in any directory. It should be sufficient.

jsoto

6th February 2005, 14:21

Deleting a cell command updates the command table, but its reference/s in Cell playback are not deleted. May be I am doing something wrong?

Not sure if this can be considered as a bug, it has a lot of implications:

I deleted a cell command which was then uniq in the PGC, but if you are deleting a cell command which is not the last one, all the references should be modified ....
The same if you adds a new one

jsoto

r0lZ

6th February 2005, 14:43

I know. It's not really a bug, but a missing feature. For now, you have to manually edit the command table.
It's on my TODO list...

jsoto

6th February 2005, 21:40

Don't worry. It is rarely needed, and IMHO it is enough to know it.

jsoto

blutach

6th February 2005, 22:34

Instead of deleting the cell command, until this is "fixed" could you change it to a NOP perhaps?

Regards

jsoto

6th February 2005, 22:42

Sure.
But I was trying to completely delete it, you know, HP3 tests, but finally this was not the problem, so changing by a NOP should be fine when you really need to do it.

jsoto

jsoto

6th February 2005, 23:32

Well, next "problem":
- Delete a cell in a PGC (currently in menu domain)

Usually it deletes a program (may be a chapter in titles domain)
So, how can I detect all the related Link commands (i.e. Link to program or link to cell).
Is this problem of "renumbering programs/cells" isolated to the own PGC (in menus, in titles you have the chapter...) or do I need to explore the whole DVD?

jsoto

EDIT: @blutach: Your HP3 has some linkprogram commands :devil:

r0lZ

7th February 2005, 00:14

The delete cell, program and chapter functions are still somewhat experimental. Works fine, but the functions do not check for links to item you deleted.
Also, if you delete a cell or program, you need to arrange the chapters table manually. If a chapter is pointing to a deleted program, the player may crash if that chapter is selected by the user.

For now, to locate the links to the deleted object, you may use the search function. You have to search only in the current titleset, as there is no way to jump directly to a cell, prog or chapter from the VMG, nor from other titlesets.
You may also use the "Go to calling command" function, which will list all references to the current PGC, but without the links coming from the same PGC.
Info -> Calls Cross References may be useful, too.

jsoto

7th February 2005, 00:38

You have to search only in the current titleset, as there is no way to jump directly to a cell, prog or chapter from the VMG, nor from other titlesets.
This is the answer I wanted. Thanks.

But, specifically in menus, and because I'm not an expert on VM, I'd like to know:
- If the deleted object can be called from a button (link program/cell). I suppose yes, weird!
- If the deleted object (cell, program) can be called from other PGC in the same VTS, same (menu) domain.
- If the deleted object (cell, program) can be called from other PGC in the same VTS, titles domain.

EDIT: Well, not only the deleted object, but also the following ones, I need to renumber all the commands

jsoto

r0lZ

7th February 2005, 00:52

I'm affraid it's yes to all questions.
You have to check for Link*Cell, Link*PG, LinkPTT, LinkPGN, LinkCN, JumpVTS_PTT, and all Set* + Link.
Only JumpVTS_PTT can be used outside the current domain. All link commands are allowed only within the current title domain, or within the current menu LU. But you must check the menu buttons and BOVs also. Pitty!

jsoto

7th February 2005, 01:08

I'm asking specifically in menu domains, so I believe we can forget LinkPTT and JumpVTS_PTT. Can we?

And because the rest of the commands should be issued in the same PGC, I believe we can limit the searching to the current PGC + Menu(VOB) buttons in the same PGC (which is enough difficult, BTW). Am I wrong?

Err, Can be BOV in menus? I hope No.

jsoto

r0lZ

7th February 2005, 01:32

Right. This is somewhat simpler.

BOV is the name of the menu buttons when there are located in the title domain. In fact, it's almost exactly the same thing. You may safely ignore them if you want to work only on 'real' menus. But take in mind that some DVD do have all their menus in the title domains, so, you will perhaps want to process them also in the future... I have made the error of considering that BOV are not verry important, and I coded PgcEdit without them in mind. It is a lot of work to add them thereafter.

2COOL

7th February 2005, 10:15

r0lZ,

In regards to kill playback option "Kill playback if there are no cell commands in the PGC" while doing blanking, I came across alot of PGCs with this scenario.

Before:

********** pre commands:
[71 00 00 0D 00 01 00 00] 1 Set gprm(13) =(mov) 1
********** post commands:
[20 04 00 00 00 00 00 04] 1 LinkPGCN PGC 4
********** cell commands:
[20 01 00 00 00 00 00 0D] 1 LinkTailPGC

Is is possible to have the algorithm detect that there is just a single cell command only holding a "LinkTailPGC" command and recommends us to blank unconditionally?

After:

********** pre commands:
[71 00 00 0D 00 01 00 00] 1 Set gprm(13) =(mov) 1
[00 00 00 00 00 00 00 00] 2 NOP
[20 04 00 00 00 00 00 04] 3 LinkPGCN PGC 4
********** post commands:
[20 04 00 00 00 00 00 04] 1 LinkPGCN PGC 4
********** cell commands:
[20 01 00 00 00 00 00 0D] 1 LinkTailPGC

r0lZ

7th February 2005, 11:02

With PgcEdit 0.5 beta, such situation, and some other, are now detected, and the blanking is done, even if the safe option is selected.

Another situation that is now checked is this one: There is only one post command, and all cell commands are equal to that post command. Obviously, it's also safe to kill playback in this case.

Also, more generally, the kill playback is assumed to be safe it there are no cell commands branching outside the current PGC. (In particular, the Link*Cell, Link*Program and LinkPTTN are now ignored.)