IFOUpdate : "Not correctly sized on sector boundary" error

[Chu]

Hello all. I am using the big 3 to resize a DVD, and when using IFOUpdate to merge the Original and Authored DVD's, I get the following error :

ERROR: File: VTS_04_0.BUP is not correctly sized on sector boundary.
ABORTING.

I was scanning this forum, and in the two threads that I found where people ran into this, the cause of the error was that they either mixed up their Original and Authored .ifo's, or they were updating an ifo from the wrong source. I am absolutly sure I am not making either of these mistakes. Also, I have discovered 2 DVD's where I get this error, and it seems to occue /w multi-angled tracks. What else be the problem?

-Chu

[de.lesse.bg]

i had the same a couple times.. can't find a link. had the error also without multi-angles. If you continue with using ifoedit, update sectors a couple times... watch the filesize of the IFO-BUP files... they are increasing much in size. can someone explain this....

ThanX...

[jdobbs]

The length of any DVD-VIDEO file (including IFOs and BUPs) should always be an even multiple of 2048 -- because that is the sector size on a DVD. This error should occur when IFOUpdate's internal sanity check finds a nonconforming file while correcting VTS Sectors.

Note: This has no relationship to multiple angles.

[chadp1a]

I'm getting this same error message when trying to update.

ERROR: File: VTS_01_0.BUP is not correctly sized on sector boundary.
ABORTING


What is the solution to this error message? Do I have to reauthor again?

[jdobbs]

It is an indicator that something has gone wrong. This might occur, for example, when you somehow abort during authoring. It the .BUP file size is not an even multiple of 2048 it is very likely there is a lot more wrong.

[Eyes`Only]

I've found that when this happens, you can just use "Get VTS Sectors" in ifoedit and things usually work OK. No guarantees though, because something is obviously wrong, but it has happened to me before numerous times, and ifoedit's correction worked fine. It would be nice if IFOUpdate had a setting where you can bypass the 'sanity check', so that we wouldn't have to resort to IFOEdit though. I know for a fact that I reauthored correctly and yet the 'sanity check' refused to accept my IFO. I'm assuming this is an error from checking the 'original' IFO, which is copied directly from the DVD, and I didn't strip anything or modify anything because I don't do that as a general rule. So hmm.. the original DVD had an incorrect sector size? Possible, but absolutely nothing I could do about that!

[jdobbs]

I can make it bypass the check, but if anyone complains about coasters I ain't listenin'

[Eyes`Only]

Thanks! Well I for one won't complain. In my eyes, it will be like all the other warnings right? If you check 'disable warnings' that means you don't want to see the warnings. It doesn't mean they don't exist, it just means you don't want to see them, and you don't want to have to click OK or be barred from your activity. The warning can still appear in the log window, along with a big disclaimer if necessary :)

[jdobbs]

Maybe it would be better to simply pad the BUP or IFO with 0's out to the next 2048 byte boundary. This could possibly be an exceptionally lame copy protection mechanism. A DVD can't have a file that doesn't fall on a 2048 boundary because that is the basic storage unit size. But you could, I suppose set the apparent file length to something inappropriate. Then when someone tries to directly copy it using DVD->Harddisc->DVD-R, they might get it screwed up somehow.

No matter how many times the girlfriend denies it -- length is important.

That's because when doing "correct VTS sectors" the IFO files of the entire DVD are adjusted because the length of the overall DVD has changed. The pointers in the IFOs/BUPs are based upon the offset in 2048 byte sectors. If it is wrong the DVD will not play back on a standalone unit (but often will playback on a computer -- as it really doesn't use the recorded sector offsets, but computes them before playback).

[jdobbs]

Okay, attached is a new version (v0.74).

Summary:

- Added an option "AutoCorrect IFO/BUP length." For some reason IFO or BUP files copied from a DVD to harddrive occasionally end up with a length that is not positioned on a 2048 byte boundary. That isn't consistent with DVD requirements. With this option checked, IFOUpdate will add filler bytes to the end of the file.

- Added an option to print the contents of the status box. Nothing fancy -- it just outputs directly to the default printer. This might be helpful in debugging problems.

Note: Whoops. I forgot I wasn't a moderator in this forum. Eyes, can you approve the attachment?

[Eyes`Only]

Thanks, JDobbs!

I have a movie with an illegally sized IFO right now on my hdd that I just completed 2 days ago. 'Bout to test it :)

[Eyes`Only]

Since you're in the mood to make fixes... ;)

Can you/did you fix the VTS_TMAPTI issue? Is it possible to use quantum's solution shown below?
This is not easy, but here goes:

Start with the authored IFO:
1) Open the IFO in ifoedit
2) Go to VTS_TMAPTI
3) Look for the hex value of 'end byte of the VTS_TMAPs table' and record it.
4) Open the IFO in hex editor and find the hex value from step 3. Verify you found the correct one by looking at adjacent hex values in ifoedit.
5) Copy the VTS_TMAPTI table in the hex editor. Use the hex value of the last entry in the table to make sure you have all of it. In the few I've done so far, the end of the table is easy to spot as it's padded with 00's after the end.
6) Now using the original ifo (as ifoupdate calls it) repeat steps 1-4
7) Paste the table from the authored ifo into the original ifo overwriting existing table.

When pasting, it's important not to shift anything up or down. The file size should remain the same. It took me a while to figure out how to paste it correctly using my hex editor (Ultraedit).

This seemed to work fine with "VTS_VOBU_ADMAP is too large to fit" errors. However the one time I had "Unequal VTS_TMAPTI table sizes" the resulting paste overwrote some existing data in the IFO (past the 00's padding) and caused errors.


Also, is the VTS_TMAPTI setting saved now? In past versions I had to remember to set that manually every time because it wasn't saved when I closed IFOUpdate.

[Eyes`Only]

The update worked nicely. Here's the output for Tomb Raider R1:

Starting IFO Update...
- Backed up original file to H :\!TOMB\O\VIDEO_TS\VTS_06_0_BUP.BAK
- New authored IFO has 1 PGCs.
- Original IFO has 1 PGCs.
Updating IFO in STANDARD mode.
- VTS_C_ADT table transferred.
- Audio/Subpicture area of VTSI_MAT transferred.
Completed region-free operation.
New VTS_VOBU_ADMAP is too large to fit. VTS_TMAPTI not transferred
- Processing VTS_PGC_0
- Copied Color Table
- Copied Audio/Subpicture Tables
File has been updated...
Incorrect filelength for VTS_03_0.BUP. Corrected.
Incorrect filelength for VTS_03_0.IFO. Corrected.
Incorrect filelength for VTS_04_0.BUP. Corrected.
Incorrect filelength for VTS_04_0.IFO. Corrected.
Incorrect filelength for VTS_07_0.BUP. Corrected.
Incorrect filelength for VTS_07_0.IFO. Corrected.
Checking VMG_PTT_SRPT start sectors.
- Title #1 [VTS_06] changed from 466574 to 466578.
- Title #13 [VTS_04] changed from 146623 to 146625.
- Title #14 [VTS_04] changed from 146623 to 146625.
- Title #15 [VTS_04] changed from 146623 to 146625.
- Title #16 [VTS_07] changed from 2070603 to 2070607.
- Title #17 [VTS_07] changed from 2070603 to 2070607.
- Title #18 [VTS_04] changed from 146623 to 146625.
- Title #19 [VTS_05] changed from 367756 to 367760.
- Title #20 [VTS_08] changed from 2197081 to 2197087.
Checking Title Sets SECTOR entries.
- VTS_02_0.IEO: LAST_SECTOR Old: 116908 New: 46166.
- VTS_03_0.IEO: LAST_SECTOR Old: 224310 New: 99830.
- VTS_03_0.IEO: VTSTTVOBS Old: 12 New: 13.
- VTS_04_0.IEO: LAST_SECTOR Old: 501978 New: 221134.
- VTS_04_0.IEO: VTSTT_VOBS Old: 16 New: 17.
- VTS_06_0.IEO: LAST_SECTOR Old: 2560197 New: 1604028.
- VTS_07_0.IEO: LAST_SECTOR Old: 308140 New: 126479.
- VTS_07_0.IEO: VTSTT_VOBS Old: 11 New: 12.
VTS Sector correction completed.
Beginning region-free operation...
- Checking VIDEO_TS.IFO
- Checking VTS_01_0.IFO
- Checking VTS_02_0.IFO
- Checking VTS_03_0.IFO
- Checking VTS_04_0.IFO
- Checking VTS_05_0.IFO
- Checking VTS_06_0.IFO
- Checking VTS_07_0.IFO
- Checking VTS_08_0.IFO

[jdobbs]

I don't think I knew there was at VTS_TMAPTI issue. What's the current setting doing wrong?

[Eyes`Only]

Well, 2 things.

1) It says that the VTS_TMAPTI couldn't be transferred as you can see from the log above.

2) It doesn't save the setting. It's unchecked every time you start your app even if you left it checked when you closed it.

[2COOL]

Originally posted by Eyes`Only
1) It says that the VTS_TMAPTI couldn't be transferred as you can see from the log above. Here's a workaround for this without having to use IFOupdate. I found this out while trying to come up with updating the Time table during my ReJig backup project. Of course, you would have to have the same number of cells.

- Replace your new VOBs with your old ones.
- Open IFO in question with IFOedit
- Go topside and go to VOB Extras / Create New IFOs
- With everything checked as is, browse to a empty destination folder. Press OK.
- Keep all streams and press Strip it button.
- When done, replace your old files with these new ones.
- Get VTS Sectors

VTS_TMAPTI is updated and IFO sectors corrected. ;)

[jdobbs]

However the one time I had "Unequal VTS_TMAPTI table sizes" the resulting paste overwrote some existing data in the IFO (past the 00's padding) and caused errors.

"Unequal VTS_TMAPTI" is a bad way of calling out the error... sorry. What that really means is that the receiving IFO doesn't have enough space to hold the source's table. Not much I can do there except possibly insert a sector -- but that would require that I change all the pointers after it. I'll leave that for now...

As for this one:

VTS_VOBU_ADMAP is too large to fit. VTS_TMAPTI not transferred

I can force it to update VTS_TMAPTI anyway (I'll add a switch) -- but my experience has been that it can be dangerous to transfer the VTS_TMAPTI without the VTS_VOBU_ADMAP... Strangely enough, though, I can't remember why...

[Eyes`Only]

You're the Guru here. If you say it shouldn't be done, then I can trust that. What 'could' happen in your experience if the VTS_TMAPTI was transferred without the VTS_VOBU_ADMAP? Is there a way to extend the VTS_VOBU_ADMAP? If there's a workaround or way to make it work, that would be preferred. I'd love to know other's experiences with just copying the VTS_TMAPTI. I wonder if any of them had problems?

[jdobbs]

I think I'm going to just bite the bullet and do it the right way. I'll put in code to shift the entire IFO out and make room for any needed additional sectors. Expect to see it sometime this week. I want to make sure it doesn't screw anything else up...

[Eyes`Only]

@JDobbs: Not meaning to rush to bother you in any way (especially around the holidays) but did you ever finish the version you were working on?

[jdobbs]

Sorry, I got distracted on another project (its a bear). Give me a little longer.

[jdobbs]

Attached is a new version of IFOUpdate (v0.75), Changes:

- Per request from Eyes Only, added capability to transfer VTS_TMAPTI and VTS_VOBU_ADMAP tables that are longer in the newly authored file than in the original IFO (destination) file. In order for this to happen you must select "Adjust VTS_TMAPTI and ADMAP Sizes" from the options menu. Please note this option is only available and effective when "VTS_TMAPTI Table Transfer (Time Map)" has also been selected.

- The options "Adjust VTS_TMAPTI and ADMAP Sizes" and "VTS_TMAPTI Table Transfer (Time Map)" are now kept persistent between program runs (it is now kept in the .INI file).

Just a warning to anyone who decides to try this... THE NEW FEATURE HASN'T BEEN TESTED. I don't have any files that cause the overruns to use for testing, but I've decided to post it anyway. I looked through the code pretty carefully, though, so it should work. Let me know if you run into any problems.

[Eyes`Only]

Thanks JDobbs. I'm sure people will give this a thorough test run.

[MLS]

Thank you! Very much appreciated :)

/MLS

[Zeul]

@jdobbs

could you confirm that this latest release when run from commandline does not now have the message boxes popping up, asking update **ifo, set region code etc.

thanks
Zeul

[Abnormal1]

Hi,
I have a small question about "Adjust VTS_TMAPTI and ADMAP Sizes"

Will it be okay to select the "Adjust VTS_TMAPTI and ADMAP Sizes" option even when the VTS_TMAPTI error does not occur(assuming there are no bugs). Or is there a chance that it could cause problems with the IFO.

Thanks
Abnormal

[jdobbs]

Yes. You can leave it on. Here's what it does:

1. If the authored IFO's TMAP table is too long to fit, moves the remainder of the IFO out the number of 2048 byte sectors needed to make it fit.

2. Copies the authored TMAP table into the space it just created.

3. Loops through the offset table in VTSI_MAT and adds the block offset to any entries that fall after the one corrected.

4. Moves the VOBU_ADMAP table -- since it falls at the end of the IFO, it just extends it if it is too long.

5. If the file is not an even multiple of 2048 after the action, it is padded to meet spec.

Since this action changes the size of the VTS's IFO and BUP -- and the length of these files are used in offset calculations, you definitely will have to correct VTS sectors in the event the table is extended. If you have "Autocorrect" on -- it happens anyway.

[Abnormal1]

Thanks alot for that jdobbs that was helpfull.

Hopefully I can now use Adjusted Cell mode for all my backups as I dont have the Patients for the Big3 when you have to use demux by Vobid.

Abnormal

[RB]

jdobbs, thanks a bunch for the update. The new functionality appears to work just fine (tested with The Green Mile).

However, now unlike in the previous versions, the two options "Transfer VTS_C_ADT Table" and "Copy Color Table in each PGC" don't remain checked between program runs.

Also, there's a problem with Adjusted Cell Mode and multiple angles (this happened in v0.72 too). If you keep angles and save Chapter Files in Adjusted Cell Mode (didn't check the other modes), you get incorrect chapter files because IFOUpdate counts each angle as a separate chapter/cell (chapters are "off" by the lenght of additional angles after the first angle point(s)). To get correct chapter files, you have to check "Ignore Angle cells" before saving chapter files and uncheck that option before updating IFOs. Maybe this can be corrected in one of the next versions.

[jdobbs]

However, now unlike in the previous versions, the two options "Transfer VTS_C_ADT Table" and "Copy Color Table in each PGC" don't remain checked between program runs.
Hmm... I'll take a look at that later today -- don't you hate it when you fix one issue and just cause another one...
Also, there's a problem with Adjusted Cell Mode and multiple angles (this happened in v0.72 too). If you keep angles and save Chapter Files in Adjusted Cell Mode (didn't check the other modes), you get incorrect chapter files because IFOUpdate counts each angle as a separate chapter/cell (chapters are "off" by the lenght of additional angles after the first angle point(s)). To get correct chapter files, you have to check "Ignore Angle cells" before saving chapter files and uncheck that option before updating IFOs. Maybe this can be corrected in one of the next versions.

Another interesting one. I'll look at that too.

[jdobbs]

could you confirm that this latest release when run from commandline does not now have the message boxes popping up, asking update **ifo, set region code etc.

I haven't paid a lot of attention to the command line options as I'm adding/modifying capabilities (I don't use them) -- guess I need to put in a special message box interface that avoids the extraneous output during command line execution.

[Trahald]

--------------------------------------------------------------------------------
However, now unlike in the previous versions, the two options "Transfer VTS_C_ADT Table" and "Copy Color Table in each PGC" don't remain checked between program runs.
--------------------------------------------------------------------------------

yeah.. noticed that too.. seams the setting is saving in the .ini.. but its not getting read back when the program is initialized

[jdobbs]

However, now unlike in the previous versions, the two options "Transfer VTS_C_ADT Table" and "Copy Color Table in each PGC" don't remain checked between program runs.
Fixed this in the attached (v0.76) version. Stupid error, I apparently inadvertently set the default at startup for this menu item to unchecked -- and then when reading from the INI I only looked to see if it needed to be set off. Duh...

[Zeul]

I haven't paid a lot of attention to the command line options as I'm adding/modifying capabilities (I don't use them) -- guess I need to put in a special message box interface that avoids the extraneous output during command line execution.

i look forward to this, thanks for your time.

Zeul

[jdobbs]

@Zeul

I went through the code and found that all the warnings are already suppressed in command line mode (by the "Disable Warnings" menu option) so I was scratching my head wondering why you were still seeing them. Then it hit me. When recognizing that I am operating in command line mode I simulated a click on that option to suppress messages.

Whoops! That means that if you had it set already (the "NoWarnings" flag is set to "1" in the INI file) -- it would be reversed and warnings would again occur. Then the exact opposite would happen on the next run, etc...

I've fixed this in the attached version.

jdobbs

[jdobbs]

@RB
Also, there's a problem with Adjusted Cell Mode and multiple angles (this happened in v0.72 too). If you keep angles and save Chapter Files in Adjusted Cell Mode (didn't check the other modes), you get incorrect chapter files because IFOUpdate counts each angle as a separate chapter/cell (chapters are "off" by the length of additional angles after the first angle point(s)). To get correct chapter files, you have to check "Ignore Angle cells" before saving chapter files and uncheck that option before updating IFOs. Maybe this can be corrected in one of the next versions.

Okay... I've looked at this and the chapter output routine specifically doesn't add the length of the cell when it is an angle and and the "Ignore Angle Cells" option is checked -- but does when angles are kept. The idea of "Ignore Angle Cells" was to support instances when someone would pull out a single angle and reauthor -- and the "angle" cell pointers in the IFO could be fixed to point to the same cell regardless of the angle chosen, making playback correct from any angle.

But, if you kept the angles (just demuxed for example) -- the length of the angle should (it would seem) be added so the chapters would fall at the correct point (e.g. in the Maestro, CCE, and IFOEDIT) -- because if the frames were there, the offset needed to be taken into consideration when setting chapter points.

So I guess I'm confused... if I write the chapter files without leaving the additional length for the angles, I would think the frame count would be off in CCE or Maestro...

Can you give me a little more info as to how you use this? Maybe I just don't understand...

[jdobbs]

@RB

Which checkbox are you setting when printing the chapters? Maybe this is why I'm confused...

[jdobbs]

Got a bugfix release...

January 4th, 2004 (v0.78)

- Bugfix. When the length of the INI changed as a result of actions enabled in v0.75 -- the Last_Sector_of_VTSI was not changed in the INI. Fixed.

Attached file has been corrected...

[RB]

Originally posted by jdobbs
But, if you kept the angles (just demuxed for example) -- the length of the angle should (it would seem) be added so the chapters would fall at the correct point (e.g. in the Maestro, CCE, and IFOEDIT) -- because if the frames were there, the offset needed to be taken into consideration when setting chapter points.

OK, I see where you are confused. The point is that you really have to reauthor multi-angle movies by VobID. You can't just demux/encode the entire M2V on the PGC level ... at least I never tried that and doubt it will work. So, for example in Maestro, for an IFO that looks like this

...
[Ch 18] [Pg 18] [Cell 18] [V/C Id: 1/18] : time: 00:01:54.03 / 25 fps [Pos: 01:06:46.14] [Frames: 100164]
[Ch 19] [Pg 19] [Cell 19] [V/C Id: 2/ 1] (Angle 1): time: 00:03:49.11 / 25 fps [Pos: 01:10:36.00] [Frames: 105900]
[Cell 20] [V/C Id: 3/ 1] (Angle 2): time: 00:03:49.11 / 25 fps [Pos: 01:10:36.00] [Frames: 105900]
[Ch 20] [Pg 20] [Cell 21] [V/C Id: 4/ 1] : time: 00:05:43.14 / 25 fps [Pos: 01:16:19.14] [Frames: 114489]
...

you have to lay out your video assets on the time line like this:

+--------------+--------------+--------------+
| VOBID_01.mpv | VOBID_02.mpv | VOBID_04.mpv |
+--------------+--------------+--------------+
| VOBID_03.mpv |
+--------------+

So when creating the ADJUSTED_MAESTRO.CHP file, for the multi-angle parts, you must record only the cells of one of the VobIDs that make up the angles, not all.

[jdobbs]

Got it. I'd actually put the code in to get around multiple angles as opposed to supporting them... The idea was to pull the video out by PGC, and then make all the angles follow the same sequence.

It should be easy enough to fix.

[RB]

Thanks jdobbs. The same applies to the creation of the ADJUSTED-CCE chapter files, of course.

Also, I think I found another problem with Adjusted Cell mode.

I just had to reauthor a title set that looks like this (it's the Extras VTS_02 from The Mummy R2):

PGC_1 (program chain): [Title(TTN): 1] [00:47:53.02 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 2,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 2/ 1] : time: 00:47:52.02 / 25 fps [Pos: 00:47:52.02] [Frames: 71802]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:47:53.02] [Frames: 71827]

PGC_2 (program chain): [Title(TTN): 2] [00:00:37.12 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 3,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 3/ 1] : time: 00:00:36.12 / 25 fps [Pos: 00:00:36.12] [Frames: 912]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:37.12] [Frames: 937]

PGC_3 (program chain): [Title(TTN): 3] [00:03:22.03 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 3,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 3/ 3] : time: 00:03:21.03 / 25 fps [Pos: 00:03:21.03] [Frames: 5028]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:03:22.03] [Frames: 5053]

PGC_4 (program chain): [Title(TTN): 4] [00:00:53.03 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 3,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 3/ 5] : time: 00:00:52.03 / 25 fps [Pos: 00:00:52.03] [Frames: 1303]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:53.03] [Frames: 1328]

PGC_5 (program chain): [Title(TTN): 5] [00:00:13.12 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 4,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 4/ 1] : time: 00:00:12.12 / 25 fps [Pos: 00:00:12.12] [Frames: 312]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:13.12] [Frames: 337]

PGC_6 (program chain): [Title(TTN): 6] [00:00:26.11 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 4,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 4/ 3] : time: 00:00:25.11 / 25 fps [Pos: 00:00:25.11] [Frames: 636]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:26.11] [Frames: 661]

PGC_7 (program chain): [Title(TTN): 7] [00:00:13.10 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 4,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 4/ 5] : time: 00:00:12.10 / 25 fps [Pos: 00:00:12.10] [Frames: 310]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:13.10] [Frames: 335]

PGC_8 (program chain): [Title(TTN): 8] [00:00:08.05 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 5,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 5/ 1] : time: 00:00:07.05 / 25 fps [Pos: 00:00:07.05] [Frames: 180]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:08.05] [Frames: 205]

PGC_9 (program chain): [Title(TTN): 9] [00:00:36.01 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 5,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 5/ 3] : time: 00:00:35.01 / 25 fps [Pos: 00:00:35.01] [Frames: 876]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:36.01] [Frames: 901]

PGC_10 (program chain): [Title(TTN): 10] [00:00:05.15 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 5,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 5/ 5] : time: 00:00:04.15 / 25 fps [Pos: 00:00:04.15] [Frames: 115]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:05.15] [Frames: 140]

PGC_11 (program chain): [Title(TTN): 11] [00:00:17.20 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 6,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 6/ 1] : time: 00:00:16.20 / 25 fps [Pos: 00:00:16.20] [Frames: 420]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:17.20] [Frames: 445]

PGC_12 (program chain): [Title(TTN): 12] [00:00:41.20 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 6,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 6/ 3] : time: 00:00:40.20 / 25 fps [Pos: 00:00:40.20] [Frames: 1020]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:41.20] [Frames: 1045]

PGC_13 (program chain): [Title(TTN): 13] [00:00:11.02 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 6,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 6/ 5] : time: 00:00:10.02 / 25 fps [Pos: 00:00:10.02] [Frames: 252]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:11.02] [Frames: 277]

PGC_14 (program chain): [Title(TTN): 14] [00:00:22.15 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 7,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 7/ 1] : time: 00:00:21.15 / 25 fps [Pos: 00:00:21.15] [Frames: 540]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:22.15] [Frames: 565]

PGC_15 (program chain): [Title(TTN): 15] [00:00:46.15 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 7,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 7/ 3] : time: 00:00:45.15 / 25 fps [Pos: 00:00:45.15] [Frames: 1140]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:46.15] [Frames: 1165]

PGC_16 (program chain): [Title(TTN): 16] [00:00:17.06 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 7,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 7/ 5] : time: 00:00:16.06 / 25 fps [Pos: 00:00:16.06] [Frames: 406]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:00:17.06] [Frames: 431]

PGC_17 (program chain): [Title(TTN): 17] [00:02:15.17 / 25 fps] (Programs: 2) (Cells: 2) (uses VOB-IDs: 8,1)
[Ch 01] [Pg 01] [Cell 01] [V/C Id: 8/ 1] : time: 00:02:14.17 / 25 fps [Pos: 00:02:14.17] [Frames: 3367]
[Ch 02] [Pg 02] [Cell 02] [V/C Id: 1/ 1] Layer Br.: time: 00:00:01.00 / 25 fps [Pos: 00:02:15.17] [Frames: 3392]

If you look hard enough, you'll notice that there are several unused cells. Cells 2 and 4 of VobId 3,4,5,6 and 7 are not referenced in the IFO. So I broke everything out by Cell ID, reencoded and authored in Maestro, ignoring the unused cells. I checked the newly authored IFO to make sure it has the right number of cells and cell playback times match exactly.

I then used IFOUpdate 0.78 to update IFOs with the following options checked:

- Transfer VTS_C_ADT Table
- Copy Color Table in each PGC
- VTS_TMAPTI Table Transfer
- Adjust VTS_TMAPTI and ADMAP sizes
- AutoCorrect VTS sectors
- AutoAnalyze Original IFO
- AutoCorrect IFO/BUP length

The process completed wihout errors and the disc burned and played without problems, but I noticed something in IFOEdit. When I open the updated VTS_02_0.IFO in IFOEdit and simply hit the "Save" button, I get the following warnings:

The file position does not match the offset for table: ID_VTSM_C_ADT
The file position does not match the offset for table: ID_VTSM_VOBU_ADMAP
The file position does not match the offset for table: ID_VTS_C_ADT
The file position does not match the offset for table: ID_VTS_VOBU_ADMAP
The IFO endsector does not match the file size

Could it be because of the tables somehow still referencing the unused cells? Anything you could do about it? I reauthored at least three other titles with IFOUpdate 0.78 (there were no unused VobID's/Cells) and never had this problem.

[RB]

jdobbs, are you still following this?

I have now seen this issue with more titles, even simple, single-PGC ones. Seems like IFOUpdate doesn't properly update some offsets when transferring tables.

BTW, this can be corrected in IFOEdit by just letting it correct the IFOs (in VOB Extras, check "Correct original IFO files" and uncheck everything else). I noticed that this usually produces a smaller IFO. Only thing is that IFOEdit messes up here when there are multiple angles, see http://forum.doom9.org/showthread.php?s=&threadid=68280#post425217

[Abnormal1]

Hi,

I thought I would just mention that I have recived the error "The file position does not match the offset for table .." aswell.

I was backing up animatrix which was the first film that I had the VTS_TMAPTI error.

I tried the IFOEdit solution that you suggested and that seems to have worked But i am not sure.

The reason I say this is that when i play it back in powerDVD everything works except seeking as it will only seek to the begining of a Chapter.


Thanks
Abnormal1

[jdobbs]

RB,

Pls check your PM...

jdobbs

[RB]

jdobbs, thanks for following up! You've got mail.

[jdobbs]

The process completed wihout errors and the disc burned and played without problems, but I noticed something in IFOEdit. When I open the updated VTS_02_0.IFO in IFOEdit and simply hit the "Save" button, I get the following warnings:

RB,

After a quick look I think I know what this is -- I'll need to test a little, but if I'm right, it really shouldn't affect your output and the resulting IFOs are fine. What happens is that the authored IFO has a TMAPTI length of 8548 bytes -- occupying 5 sectors. But the size of that table in the newly authored IFO is only 7100 bytes -- occupying only 4 sectors. IFOUpdate sees there is plenty of room and copies the newly authored table. The means, though, that there is a wasted sector between the end of TMAPTI and VTSM_C_ADT -- and all the following tables. It will play alright -- but IFOEDIT calculates the real space needed and catches the waste. Gotta hand it to Derrow -- he didn't leave a lot to chance.

I knew IFOUpdate did this -- but kinda' filed it and forgot it... what I'll do in the next version of IFOUpdate is insert a subroutine that looks for wasted sectors and adjusts the lengths. It really should do that to be 100% correct anyway.

jdobbs


Added note: The same thing is happening on the VTS_VOBU_ADMAP -- the last table. When IFOEDIT saves, it recognizes the wasted space at the end and it shortens the file, but doesn't change the "Last Sector" byte at offset 0x1C --> resulting in the "The IFO endsector does not match the file size" error. That could cause problems, so I don't think I'd trust the resulting file. This would also be fixed with the note above.

[RB]

Thanks jdobbs, looking forward to the next release! You are right, the burned disc plays just fine without any issues in both WinDVD and my standalone. Until now it was just that when I needed to edit the updated IFOs in IFOEdit to remap some audio/subpicture streams etc., IFOEdit would barf and as you noted, save an invalid IFO (you basically got in an endless loop with "Get VTS sectors" afterwards).

@Abnormal1:
You are right, letting IFOEdit correct the IFOs results in valid IFOs and everything is fine except for seeking in software players. Noticed this too. This doesn't happen when you use IFOUpdate, so I guess the next IFOUpdate version will solve all the issues.

[jdobbs]

Maybe I should think about putting something in to remap streams...

[RB]

You are reading my mind :) Yeah, that would be great. Some thoughts...

The "Copy Audio and Subpicture Tables" option would become a radio option of "Copy Audio and Subpicture Tables" and "Adjust/Remap Audio and Subpicture Tables". Each PGC in the authored IFO would have to have at least the same number of streams as in the original IFO, you then would simply loop through the PGCs and assign the stream IDs from the authored IFO .... won't work in adjusted cell mode, unless I'm missing something.

Also, a bit of warning regarding detecting the number of audio/sub streams in "original IFOs". I usually first run things through InstantCopy to strip streams and compress menus. I noticed that in these IC-stripped IFOs, IFOUpdate always still detects the original number of streams, although I stripped audio/subs in IC. From what I can tell by looking around in IFOEdit - VTSI_MAT, that's because IC only adjusts "Number of streams in VTSM_VOBS" but not "Number of streams in VTSTT_VOBS" (you can see that in the IFOs I sent you, they were all processed by IC). Maybe other OC tools have the same problem.

[RB]

While we are at this, what about an option to transfer (or should this be a default actually?) the video attributes like VBR/CBR, resolution, aspect ratio etc.? For instance, sometimes I do resize extras to 352x576 so it looks better at very low bitrates.

And speaking of this, have you thought about updating VIDEO_TS.IFO? I see it lists the video attributes, subs/audio streams and number of chapters for each title as well. I know IFOEdit adjusts VIDEO_TS.IFO when stripping things, but for instance IC does not... so is it even absolutely necessary?