TitleWriter 4.72 - *** Update 31 July 2008, ***

[dirio49]

I have not tried the latest testbed yet, but the one before this failed if you pre-save the ifo with pgcedit.

---------------------------

---------------------------
VIDEO_TS.IFO Error 

 Table Sizes/End Sectors Do Not Match --Not Correctable --  Table sizes are wrong
---------------------------
OK   
---------------------------

Edit: same thing with latest testbed

[FallenAngel]

Dirio_49
The fault lies in all three programs -- 99% in "Squish"
Delete the FP commands in PGCedit before saving then TW won't crash
If you don't do this PgcEdit will perform a faulty fix (It isn't updating table sizes (just table offsets) -- and the errors just compound )

Simplist just not to use PgcEdit to try to fix this -- Or to fix it properly (FP commands)
Or even simplier just let Make Menu do it and eliminate the middleman

[dirio49]

Yep, that did it

Recode has the same problem.

[tetsuro_ja]

Thanks.

I created a DVD compliation having 50 VTSs by using 'New DVD' + 'Import VTST Titles' of PgcEdit 8.3.
I could reproduce 50 VTSs issue (TW Failure) reported by jinjin_jp.
I also confirmed TestBed6_24_4 fixed the 50 VTSs issue.

Regards

[tetsuro_ja]

I tested TestBed6_24_4.

96 movies -- Menus could be created without any trouble
97 movies -- On Menu Creation Error -- Failure
98 movies -- On Menu Creation Error -- Failure
99 movies -- TW disappears without notice when VIDEO_TS.IFO is opened.

** 4 movie thumbnails per page were set in all cases.

Regards

[r0lZ]

Sorry, I haven't noticed this discussion before, and I am a bit confused.

The "too many commands" in a PGC is a well known bug of DVDS***** (and BTW, also of IfoEdit.) I didn't know that the same problem exists in Recode, but it's not surprising.

PgcEdit can't do much more that what it does now. If there are too many commands in the PGC, when you load the DVD, it fixes the number of pre, post or cell commands so that the total number of commands is less or equal to 128, and it updates the end-byte pointer of the command table. When PgcEdit saves the DVD, the PGCs are rebuilt from the commands (and other tables) stored in memory, and all offsets and table length are recomputed accordingly.

In the precise case of the FP-PGC, since there are no post and cell commands, the number of pre-commands is changed to 128, and the pointer to the last byte of the command table is also fixed to (128 commands * 8 bytes per commands) + (4*2 bytes at the beginning of the command table) -1 to point to the last byte of the table = 1023. That's correct.

Then, when the DVD is saved, PgcEdit pads the whole VMGM_MAT table with null byte so that its size is a multiple of 2048, and appends the other tables the same way. The pointers to the tables in VMGM_MAT (aka "VTS sector pointers" in the IfoEdit terminology) are, of course, also updated. (You can verify with IfoEdit that the sector pointer to VMG_TT_SRPT is now 2.)

Therefore, I don't understand that:

If you don't do this PgcEdit will perform a faulty fix (It isn't updating table sizes (just table offsets) -- and the errors just compound )

Which table size is not updated? IMO, everything is correct.

I agree that the PgcEdit fix is not sufficient, because there are two problems in the original DVD.

The first one is that there are more than 128 commands in the FP-PGC. It's illegal (although some players are happy with up to 256 commands.) That's easy to fix, and it's correctly fixed.

The second problem is that with more than a certain amount of commands (probably 97 but I haven't verified that), the whole VMGM_MAT table needs to be expanded to two sectors instead of just one. The second bug of Recode is that the table is not expanded. Therefore, when the next table (normally VMG_TT_SRPT) is created, it overwrites the second sector of the VMGM_MAT table. In other words, the command table of the FP-PGC is truncated. The "start offset of VMG_TT_SRPT" at offset 0xC4 in VMGM_MAT should be 2 but is still 1! It's why the last commands of the FP-PGC are garbage. PgcEdit tries to interpret the data at the beginning of the VMG_TT_SRPT table as FP-PGC commands, and I guess that TW does the same thing, and it's probably why it crashes.

Of course, as the last bytes of the FP-PGC table has been overwritten, the last commands are definitely lost, and it is impossible to recover them. However, it should be possible to verify if the start offset of VMG_TT_SRPT is high enough to include more than 97 commands, and if it's not the case, offer to limit the number of commands in the FP-PGC to 97 instead of 128. This will eliminate the wrong and illegal commands, but the DVD is still damaged anyway, and honestly I'm not sure it's the job of PgcEdit to fix the bugs of the other programs! Anyway, currently, as Angel said, it is possible to delete or fix the wrong commands manually.

I will see if it is possible to do that easily, but I can't promise!

[FallenAngel]

Sorry Rolz --

It isn't updating table sizes (just table offsets)

I meant table commands

What I meant is the result of PgcEdits Save does not result in a playable disk. There is a perception that if "Save" is successful the compiliation is "sound" and playable.

probably 97 but I haven't verified that

This is what i meant when I said 47th movie -- "Squish" creates 2 commands per movie -- and I haven't verified it either

I will see if it is possible to do that easily, but I can't promise!

Same here but the only true way I can see to fix is to delete those commands from the FP and recreate them in multiple Pgc's -- In TW's case the fix is Make Menu. This is more in the authoring realm

[r0lZ]

OK, that was easy to do. PgcEdit limits now the number of commands in the FP-PGC to 97 when the VMGM_MAT table is only one sector long, according to the VTS sector pointer to VMG_TT_SRPT. The garbage is therefore eliminated, but of course, there are still many problems in the FP-PGC commands, since some of the GOTOs are now pointing to non-existent commands.
Therefore, it is recommended to limit the Recode compilations in re-author mode to 49 titles (since each title needs 2 commands except the first one, which needs only one command) unless you are sufficiently experienced to fix the FP-PGC commands manually (or, I guess, if you use TW after.)

[r0lZ]

I meant table commands

Ah, OK, that's right. But since PgcEdit is not dedicated to edit only the DVDs produced by Recode or S*, I cannot assume that I know how to fix them.

What I meant is the result of PgcEdits Save does not result in a playable disk. There is a perception that if "Save" is successful the compiliation is "sound" and playable.

I agree, and have just noticed that problem. I have also changed the error message to warn the user that it has to verify the commands before saving the DVD.

This is what i meant when I said 47th movie -- "Squish" creates 2 commands per movie -- and I haven't verified it either

It's not exactly true.
The first title consumes only one command. Therefore, since it is possible to have 97 commands without problem (I have now verified that), the maximum number of titles in the compilation is 1 + (97-1)/2 = 49. I have just created a dummy compilation with 49 titles, and it works fine.

Same here but the only true way I can see to fix is to delete those commands from the FP and recreate them in multiple Pgc's -- In TW's case the fix is Make Menu. This is more in the authoring realm

OK. I can't do much more neither, as the philosophy of PgcEdit is not to modify the commands without the explicit user consent.
But I could perhaps add a new function in the DVDS* plugin to fix this problem automatically. However, I'm not sure I will do it, as I have other things to do, and, as I said, it's not the job of PgcEdit to fix the bugs of the other programs. Also, I guess that my fix will be incompatible with TW.

[FallenAngel]

Rolz -- Just from a For my information standpoint
Aside from the "fix" I described above (Kill Fp then link Fp to multiple pgc's)-- Do you see another way to handle 99 movie switcher in the VMGM

Also, I guess that my fix will be incompatible with TW.

If it results in a "legal" playable disk TW will happily munch it

[FallenAngel]

Uploaded 6_25

Tetsuro_ja
Tested 6_25 on 97 and 99 seems fine
(99 was a pain -- monkey was sloppy a long long time ago)
Reduced wait time from 3 sec to 2 in setup warning -- insufficient room for streams
Fixed -- Slight bug with the max number streams allowed on setup menu
(limit was max#-1 not max#)

[r0lZ]

Rolz -- Just from a For my information standpoint
Aside from the "fix" I described above (Kill Fp then link Fp to multiple pgc's)-- Do you see another way to handle 99 movie switcher in the VMGM

No! IMO, it is necessary to have at least 2 commands per Title (except for one title) and therefore it is necessary to create several PGCs in the VMGM when there are more than 64 titles.

BTW, I have analyzed my code, and I am currently implementing the fix in the DVDS* plugin, as it's relatively easy to do. I will post it here soon.

[r0lZ]

DVDSh* plugin v2.4, with the fix!

OK, you can download the DVDSh*_plugin v2.4 for PgcEdit here.

• Added the function "Fix compilation with 50 or more Titles" to fix the wrong FP-PGC commands produced by Sh* when there are 50 or more Titles in a compilation made in re-author mode.
  As a bonus, the Title menu button can be used to skip to the next Title.
• Fixed a bug in "DVDSh* Remote Buttons" when there are more than 63 Titles in the compilation and the GoUp button returns to the previous Title.

Note that the fix is incompatible with the function "DVDSh* Remote Buttons". But you can also fix the problem by using "Redo Authoring", even after having applied the fix.

[FallenAngel]

rolx --just tested plugin 99 movies then tw >> MakeMenu everything fine
(though tw needs to delete the menu pgc's --but I've got that covered)
The difference now is the FP commands are legal on entry Hence TW "likes" pgcedits output

My fixVts analysizes commands in the tables kicking the generic "error" message if it detects problems
(I probably should kick a different error -- Pgc command table f^&ked)

[jinjin_jp]

@r0lZ
Thanks for the explanation.
I did several tests according to your explanation.
(Sorry now I noticed Testbed6_25 and DVDSh*_plugin v2.4, I'll test soon.)

When FP has over 97 commands, the error seems to occur.
(98th command of DVDShrink is always incorrect(jump to last title).)
When 49 titles, 97 commands and no problem.
When 50 titles, 99 commands and have the error.
When FP has over 97 commands, VIDEO_TS.IFO increase 2kB after saved by PgcEdit.
When delete FP commands to 97 and save (I tested with 57 titles), VIDEO_TS.IFO doesn't increase and the error doesn't occur.
Even if deleting FP commands, TW's seems not to have the problem because it newly create FP command. So I think I can use DVDSh*_plugin before processisng by TW.

The number of command of TW's output seems to be less or equal to 102, by adding PGC_8 when PGC_7 has more commands.
This 102 commands is legal or not?
The size of VIDEO_TS.IFO doesn't increase after saved by PgcEdit.

Regards.