While experimenting I discovered a very small anomaly that may or may not be significant... Take a movie, any movie, and process it through DVD-RB in "movie only" mode. Now, check that output with FixVTS.exe available at . It will "fix" the IFO files by changing exactly 1 byte. If you run that output through DVD-RB, DVD-RB will change that single byte back again. Run FixVTS.exe on it again, and again that 1 single byte is changed... Normally I would assume that RB is making the correct choice, but I have used FixVTS.exe extensively and found it to be very strict with spec compliance I am really curious in this case as to what that 1 byte is about. This should be very easy to reproduce, but let me know if I should upload an example IFO or you need any other info.
If you can tell me what byte it is I can tell you what's right.
--------------------- 2001 Pewter Formula Firehawk Hard-Top (1 of 3 for 2001) Need to update the website! 1997 Byzanz M3/4/5 "Penny" First pic @ her new home 04-22-07, more to come May 2008 after 5% tint and Zaino Detail
...I don't know how to answer that. I became aware of the difference by comparing the files with the old DOS tool FC.EXE (I am a DOS guy from way back and old habits die hard I guess). It reports the difference, but I don't know how to correlate that with what part of the IFO it is located in. Does that make sense to anyone but me? Can I post just the "movie only" IFO files from an RB processed commercial DVD, or does that break a rule?
Depending how the IFO is constructed, in movie only mode, that is usually a byte in the time map table, which reflects that's table's ending byte. 0x0004 of VTS_TMAPTI Rebuilder's simply says it has 4 fewer entries in the time map. Check it out in . Perhaps there are repeated entries at the start or end. If so, they are usually harmless. Be nice to know which is correct. Regards
Does your diff program give you the first difference, or all the differences? It's hard to imagine that the two tables would have different end byte, but no differences inside of them... Jeanl
@jeanl - FC reports all differences, and in this case there is exactly 1. More specifically, when RB's "version" of the IFO is opened with IFOedit, the "End byte of VTS_TMAPs table is 10567 (00002947h). When FixVTS.EXE's version of the IFO is opened, it reports 10571 (0000294bh). I have done a byte-by-byte compare of every other file in the VIDEO_TS folder and they are all identical. When burned with either IFO the disks play just fine in all my players so this is probably not a big deal; its just like blutach said in some post of his I just read somewhere "...the quest for perfection and all that". Thanks to all for the help.
More info: The RB version has this in the VTS_TMAPTI section (reported by IFOEdit): [00000000] Number of VTS_TMAPs 1 [0001] [00000004] End byte of VTS_TMAPs table 10567 [00002947] [00000008] Time map 1: start byte 12 [0000000c] [0000000c] Time unit (in seconds) 4 [04] [0000000e] number of entries in time map 2638 [0a4e] [00000010] Entry 1: at sector 1157 [00000485] (edited to remove a bunch of stuff I don't understand - last line is below) [00002944] Entry 2638: at sector 3091458 [002f2c02] The FixVTS.EXE version has this in the VTS_TMAPTI section (reported by IFOEdit): [00000000] Number of VTS_TMAPs 1 [0001] [00000004] End byte of VTS_TMAPs table 10571 [0000294b] [00000008] Time map 1: start byte 12 [0000000c] [0000000c] Time unit (in seconds) 4 [04] [0000000e] number of entries in time map 2638 [0a4e] [00000010] Entry 1: at sector 1157 [00000485] (edited to remove a bunch of stuff I don't understand - last line is below) [00002944] Entry 2638: at sector 3091458 [002f2c02] Looks to me like one of them is wrong about where the last byte actually is but I lack the knowledge to figure out which... @jeanl - It just "clicked" in my little pea brain who you are (author of FixVTS.EXE). Hi!
@DVD-RBNewbie Nice meeting you, too :) The answer is in practical terms, there is no difference. The last time map entry ends at 0x2947 The one with FixVTS also has its last entry ending at 0x2947 but pads out the end (this probably reflects the original authoring of the DVD). Regards