Bug with Layer Break Flag setting on ISO burns

[fordman]

I finally burned my first dual layer ISO file that didn't have a .MDS file associated. The image was created by CloneDVD.

 

I used the ISO tool to see what were acceptable layer break points and ImgBurn only indicated that cell 25 was acceptable, though the previous cell would have been preferable for me, as that was the beginning of a scene change with fade out. Cell 25 was during a scene. Judging from the final burned disc which put 57.72% of the sectors in layer 0 (42.28%) and the short time between chapters (avg 5 minutes) it should have been possible to put the flag on cell 24.

 

However, ImgBurn modified the ISO file to insert the flag in the VTS_01_0.IFO and burned fine, and compared fine, so that is not the bug.

 

The bug is that ImgBurn did not make the same change in VTS_01_0.BUP, which is supposed to be indentical to VTS_01_0.IFO and used in case VTS_01_0.IFO cannot be read for some reason. I recommend that this change be implemented in future releases.

 

I was alerted to this difference by creating CRCs of the files on the original image mounted as a drive and also for the modified image mounted as a drive. By doing this, I found that the CRCs of TWO files differed between the original and modified images:

 

VTS_01_0.IFO (as desired with the flag inserted, but VTS_01_0.BUP remained the same as original)

 

AND

 

VTS_01_3.VOB

 

Now, why did ImgBurn modify the VTS_01_3.VOB file? The video where the layer break flag corresponds to is actually contained within VTS_01_4.VOB, but even then there is no need to modify a VOB at all when setting a layer break flag - correct?

 

Here is the file compare log between the .SFV CRC files for both images:

 

***** Files_Image_Orig.sfv

VTS_01_0.BUP 2A4C6EE0

VTS_01_0.IFO 2A4C6EE0

VTS_01_0.VOB C7EBDAE0

***** FILES_IMAGE.SFV

VTS_01_0.BUP 2A4C6EE0

VTS_01_0.IFO B7667004

VTS_01_0.VOB C7EBDAE0

*****

 

***** Files_Image_Orig.sfv

VTS_01_2.VOB 145425D8

VTS_01_3.VOB 0EB4222A

VTS_01_4.VOB ABF4D22F

***** FILES_IMAGE.SFV

VTS_01_2.VOB 145425D8

VTS_01_3.VOB C62DF9EB

VTS_01_4.VOB ABF4D22F

*****

 

So, is ImgBurn actually corrupting my video files when it modifies the .ISO image?

I've attached zip files with the IFO and BUP files from both the original and modified images. However I cannot of course include the VOB file, though I would be curious to find out what change was made to it...

 

Thanks,

fordman

 

EDIT: I did some more research and found the the ImgBurn modified ISO had changed the VTS_01_3.VOB quite dramatically! Beginning at address 08E15000 the VTS_01_03.VOB had large sequences of bytes changed - mostly from actually values to 00 (null)! This is not good, so I will likely extract the ISO files and burn with a program like RecordNow Deluxe 7.3 to ensure I have an uncorrupted copy. For example, here is an example of one such range, and I even truncated this one for brevity's sake (The first column is the hex address, the second is the byte value in the original VOB at the address, and the third column is the ImgBurn modified value):

 

08E16814: 81 00

08E16815: 00 01

08E16817: 0B 2D

08E16818: 30 00

08E16819: E0 01

08E1681A: 33 00

08E1681B: 8C 2E

08E1681C: 1F 00

08E1681D: 20 01

08E1681E: 69 00

08E1681F: 2B 2F

08E16820: 23 00

08E16821: 16 00

08E16822: DC 00

08E16823: 09 00

08E16824: 27 00

08E16825: EC 00

08E16826: AE 00

08E16827: 07 00

08E16828: 55 00

08E16829: 62 00

08E1682A: 33 00

08E1682B: 37 00

08E1682C: 56 00

08E1682D: 4E 00

08E1682E: 51 00

08E1682F: FC 00

08E16830: 3C 00

08E16831: 79 00

08E16832: CD 00

08E16833: 06 00

08E16834: E6 00

08E16835: 0D 00

08E16836: 42 00

08E16837: 5F 00

08E16838: 67 00

08E16839: 5A 00

08E1683A: BE 00

08E1683B: 55 00

08E1683C: 9F 00

08E1683D: 5D 00

08E1683E: 41 00

ModdedImage_VTS.zip

OrigImage_VTS.zip

Edited February 4, 2006 by fordman

[fordman]

I used the ISO tool to see what were acceptable layer break points and ImgBurn only indicated that cell 25 was acceptable, though the previous cell would have been preferable for me, as that was the beginning of a scene change with fade out. Cell 25 was during a scene. Judging from the final burned disc which put 57.72% of the sectors in layer 0 (42.28%) and the short time between chapters (avg 5 minutes) it should have been possible to put the flag on cell 24.

 

OK, I saw LIGHTNING UK!'s post regarding the placement of layer breaks in his post here:

 

http://forum.imgburn.com/index.php?s=&show...findpost&p=8192

 

and looking at VTS_C_ADT in IfoEdit, I see that the start sector (+1) of cell 25 is evenly divisible by 16. How important is this, though? I burned the files from the original image with RecordNow Max Deluxe 7.3, and it chose cell 23, whose starting address (+1) is NOT evenly divisible by 16. Is this important because sectors are only allocated in a layer by groups of 16? I've never had an issue with layer breaks created by RecordNow Deluxe... In addition, I've noticed that pressed DVDs don't necessarily have the break on a cell which begins on an address that is a multiple of 16 sectors.

 

By the way, beside modifiying the VTS_01_0.IFO and VTS_01_0.BUP on the recorded disc to include the layerbreak flag, RecordNow left the rest of the files identical to the originals, as has been my experience in the past. What really amazes me about this program is that it does this on the fly without even having to modify the original files on your hard disk. Those remain without the flag information.

 

Perhaps Imgburn would be best served by following this approach, i.e. don't modify the actual ISO file itself, but rather make the layer break flag changes "on the fly" like RecordNow Max does. Of course that would make any image verification fail afterward...

Edited February 4, 2006 by fordman

[LIGHTNING UK!]

ImgBurn doesn't touch the VOB file, not sure why you found that it does.

 

As ImgBurn only burns ISO files (at the moment anyway), it's not possible for it to pad out the files in a way that cell 24 would have landed on a sector divisible by 16.

 

This 'sector divisible by 16' thing is an absolute must so far as being compliant with DVD-Video specs. Call it the number 1 rule if you like.

 

I could have sworn the BUP file is modified too btw. Something as basic as that is not something I'd miss out!

[LIGHTNING UK!]

Ok, I double checked my code and I honestly do update the IFO and BUP. I knew I wouldn't forget something like that!

 

I still have no idea where your VOB file changes are coming from but I can assure you it's not intentional if it does indeed turn out to be ImgBurn's fault.

 

In order for me to try and reproduce any potential issues ImgBurn may be having with your ISO, I'll need you to use my little grab5m program and send me what's essentially enough of the image (5 meg!) for me to look at the filesystem and recreate anything I need to.

 

You can download it from here http://download.imgburn.com/grab5m.zip

[LIGHTNING UK!]

Ah hah... found the problem

 

Whilst calculating the position to seek to within the file, the number must have been defaulting to using a 32bit integer rather than a 64bit one - which the result was being stored in.

A large number would have overflowed a 32bit integer variable - as is the case for a BUP file because it's normally much later on in the disc. (large LBA value * sector size is > max value a 32bit int can hold)

 

That would indeed be why you were finding random data changes in your vob. The new BUP would have been written to whatever (incorrect) file position the program had calculated, overwriting what was there originally.

Thanks, this has now been fixed.

[ron spencer]

thanks LUk....does this mean I should wait to do the same type of burns? Is a new version in the offing?

[LIGHTNING UK!]

This only effects ISO's without MDS files and without a layerbreak flag already in the IFO - so basically, only DL images made by 'dumb' programs!

 

A 1.2.0.0 release has been on the cards for some time now... I just like to make sure I've caught/fixed most the problems. Sometimes these things take a while to find their way out of the woodwork

[ron spencer]

awesome....thanks for the clairification....drooling for new version but take your time

[lfcrule1972]

Ah hah... found the problem

 

Whilst calculating the position to seek to within the file, the number must have been defaulting to using a 32bit integer rather than a 64bit one - which the result was being stored in.

A large number would have overflowed a 32bit integer variable - as is the case for a BUP file because it's normally much later on in the disc. (large LBA value * sector size is > max value a 32bit int can hold)

 

That would indeed be why you were finding random data changes in your vob. The new BUP would have been written to whatever (incorrect) file position the program had calculated, overwriting what was there originally.

Thanks, this has now been fixed.

 

 

I was just going to say the same........

 

[LIGHTNING UK!]

Here's an easy version for you lfc

 

Take an 8bit value. The largest number (unsigned) that it can hold is 255.

 

1111 1111 in binary = 255. (Rightmost 1 is worth 1, 2nd is worth 2, 3rd worth 4, 4th worth 8, 5th worth 16, 6th worth 32, 7th worth 64, 8th worth 128 = giving us 128 + 64 + 32 + 16 + 8 + 4 + 2 + 1 = 255)

 

Now if I add 2 to 255 we get 257, yeah.

 

257 is represented as

 

1 0000 0001 in binary.

 

You'll notice we now have 9 bits. That's no good because were's only doing the calculation in 8.... so lets forget about that 9th one!

 

Now we have

 

0000 0001

 

Well that represents 1. So basically, our calculation of 255 + 2, when using a single 8bit variable for storing the answer, equals 1!

 

What was happening for the layerbreak stuff was basically the same as that only on a larger scale.

[kevdriver]

Exactly Boss, I was going to explain that very caculation to lfc myself...................

[lfcrule1972]

I understand that thanks boss - why did you knock off the far left 1 and not the far right 1 tho ?

[LIGHTNING UK!]

because things work from right to left in binary, not the normal left to right

 

Think of like you've got 9 discs and 8 drives. You don't put disc 9 in first do you, you put disc 1 in first - meaning disc 9 never gets a drive

[fordman]

Ah hah... found the problem

 

Whilst calculating the position to seek to within the file, the number must have been defaulting to using a 32bit integer rather than a 64bit one - which the result was being stored in.

A large number would have overflowed a 32bit integer variable - as is the case for a BUP file because it's normally much later on in the disc. (large LBA value * sector size is > max value a 32bit int can hold)

 

That would indeed be why you were finding random data changes in your vob. The new BUP would have been written to whatever (incorrect) file position the program had calculated, overwriting what was there originally.

Thanks, this has now been fixed.

 

OK, just checking back in after being away for awhile. I understand what you say here, and it appears that it both explains why my VOB was changed, and why the BUP was NOT changed - correct? The BUP was not changed because the changed version was buried in the VOB file that was altered? Meanwhile the original ISO file had the unaltered BUP file contents past the address space for the VOBs?

 

So, it appears there is no reason to use the grab5m program now?

 

I guess I need to do some more research about the multiple of 16 sectors for the layer break flag issue. I can point out various places where originally mastered DVDs do not comply with this, and as I said RecordNow Deluxe 7.3 does not pick flag positions that correspond to this, yet it changes layers flawlessly, even on older players which would have a problem with the lack of a layer break flag....

 

Sorry I left you hanging on this. I got busy with other things, and when I didn't see your usual quick reply, I figured it might take some time to work it out. As you can see, I am a bit obsessive about verifying my data backups before erasing the original files...

 

fordman

[lfcrule1972]

because things work from right to left in binary, not the normal left to right

 

Think of like you've got 9 discs and 8 drives. You don't put disc 9 in first do you, you put disc 1 in first - meaning disc 9 never gets a drive

 

 

Thanks boss.....

[LIGHTNING UK!]

Fordman,

 

Quite right, you don't need to do the grab5m thing now. That truncated address calculation could have meant ANY file got changed (rather than the bup). It might not have even been a file at all, it could have been something in the filesystem.

 

I'd love to see an original disc where the layerbreak isn't on a sector divisible by 16! Not that I've ever really been paying that much attention but I have to say this is highly unlikely.

[fordman]

I'd love to see an original disc where the layerbreak isn't on a sector divisible by 16! Not that I've ever really been paying that much attention but I have to say this is highly unlikely.

 

 

OK, I was just looking at one back when I wrote the original message in this thread. I'll see if I can find it again, or look for others.

 

For the .IFO files I posted in the zips attached to the original message, I looked and saw that ImgBurn chose cell 25 as the layer break flag point (a integer multiple of 16 sectors), while RecordNow Deluxe chose cell 23 (not an integer multiple). Meanwhile my preference would have been cell 24 because of a scene change between cell 23 and 24. Anyway, can you confirm my math that RecordNow Deluxe chose a cell that does not conform to DVD-VIDEO specifications? Also, do you have a handy link to this rule? I'm only asking because I may pursue this with Sonic so that they can fix their program to make it compliant. Though I haven't had trouble with layer changes written by RecordNow up through this point, it would be nice to be confident in it's results!

 

Thanks for your excellent detective work! I'll give you feedback if you release a new version that overcomes this issue.

[LIGHTNING UK!]

Were you just burning the exact same ISO and not the raw VIDEO_TS files?

 

If you were burning the files, recordnow could just pad the filesystem so 23 could have been correct. If it was dealing with the ISO directly, ImgBurn should have also picked up cell 23 as being valid if indeed it was (and you'd have been presented with a nice little selection box). You can't really manipulate the ISO once it's been built, so recordnow max should also have gone for 25 as it was the only valid one.

 

The only way to tell for sure if RecordNow was ok to use cell 23 is to look at the disc it burnt, find the offset for the VTS set (in terms of LBA of VTS_xx_1.VOB - use IsoBuster or something) containing the layerbreak and then the offset of cell 23 within that VTS. This can be found using IfoEdit.

 

From the original IFO files, Cell 23 starts at LBA 1637074 (offset from sector 0 in VTS_xx_1.VOB).

 

1637074 (mod) 16 = 2

 

So, if my calculations are correct VTS_xx_1.VOB start LBA (mod) 16 must equal 14.

Only then will Cell 23 fall on an LBA where it (mod) 16 = 0.

 

The rule for layerbreaks is in the DVD Video specs - or at least the double layer recording version of them. I don't have them.

The info was passed onto me by someone and backed up by what I'd read elsewhere (mainly on the gear mastering site)

 

However, a quick search on google finds the following:

 

http://www.gearsoftware.com/support/docume...mbreakpoint.cfm

http://www.mediachance.com/dvdlab/Helppro/layerbreak.htm

[fordman]

Were you just burning the exact same ISO and not the raw VIDEO_TS files?

 

If you were burning the files, recordnow could just pad the filesystem so 23 could have been correct. If it was dealing with the ISO directly, ImgBurn should have also picked up cell 23 as being valid if indeed it was (and you'd have been presented with a nice little selection box). You can't really manipulate the ISO once it's been built, so recordnow max should also have gone for 25 as it was the only valid one.

 

The only way to tell for sure if RecordNow was ok to use cell 23 is to look at the disc it burnt, find the offset for the VTS set (in terms of LBA of VTS_xx_1.VOB - use IsoBuster or something) containing the layerbreak and then the offset of cell 23 within that VTS. This can be found using IfoEdit.

 

From the original IFO files, Cell 23 starts at LBA 1637074 (offset from sector 0 in VTS_xx_1.VOB).

 

1637074 (mod) 16 = 2

 

So, if my calculations are correct VTS_xx_1.VOB start LBA (mod) 16 must equal 14.

Only then will Cell 23 fall on an LBA where it (mod) 16 = 0.

 

The rule for layerbreaks is in the DVD Video specs - or at least the double layer recording version of them. I don't have them.

The info was passed onto me by someone and backed up by what I'd read elsewhere (mainly on the gear mastering site)

 

However, a quick search on google finds the following:

 

http://www.gearsoftware.com/support/docume...mbreakpoint.cfm

http://www.mediachance.com/dvdlab/Helppro/layerbreak.htm

 

Yes, I burned the raw files with RecordNow Deluxe, not the ISO image. To be exact, I re-extracted the original ISO image (deleted the one modified by ImgBurn) and mounted that in a Alcohol 120% virtual drive, and added the "raw VIDEO_TS files" directly from the virtual drive. Since RecordNow does not need ot modify the original files, this works quite nicely without the unnecessary step of extracting the files from the ISO.

 

So, perhaps you are correct that it padded the burned disc to make it's selection of cell 23 valid. I'll attempt to verify it by the method you suggest. I also need to refer to the DVD-VIDEO specs and get smarter on that. You are way over my head on some of the things you are referring to. In particular, I need to check try to recall some of my math courses for notation like (mod), which I think means the remainder from an integer division...

 

Thanks again - it looks like your algorithm for choosing the cell for the flag is correct and compliant, and we managed to catch a math error for this type (ISO without flag nor .MDS) of image. I will try to verify that RecordNow is correctly padding to be compliant!

[fordman]

Were you just burning the exact same ISO and not the raw VIDEO_TS files?

 

If you were burning the files, recordnow could just pad the filesystem so 23 could have been correct. If it was dealing with the ISO directly, ImgBurn should have also picked up cell 23 as being valid if indeed it was (and you'd have been presented with a nice little selection box). You can't really manipulate the ISO once it's been built, so recordnow max should also have gone for 25 as it was the only valid one.

 

The only way to tell for sure if RecordNow was ok to use cell 23 is to look at the disc it burnt, find the offset for the VTS set (in terms of LBA of VTS_xx_1.VOB - use IsoBuster or something) containing the layerbreak and then the offset of cell 23 within that VTS. This can be found using IfoEdit.

 

From the original IFO files, Cell 23 starts at LBA 1637074 (offset from sector 0 in VTS_xx_1.VOB).

 

1637074 (mod) 16 = 2

 

So, if my calculations are correct VTS_xx_1.VOB start LBA (mod) 16 must equal 14.

Only then will Cell 23 fall on an LBA where it (mod) 16 = 0.

 

OK, Lightning UK!

 

I have verified by looking at both versions of the subject DVD (burned ISO with ImgBurn 1.1.0.0 and burned files with RecordNow Deluxe 7.3), that both match your example calculation above using the MOD of the LBA divided by 16.

 

Yes, the VTS set did start at a different point on the RecordNow version, so that's why it chose a different layer break point.

 

My mistake was in thinking that the start sector addresses listed in the VTS_C_ADT were physical LBAs on the disc, instead of the offsets from the beginning of the VTS that they actually are. That's why I thought I could just divide the start sector (+1) for a cell by 16 to see if it was evenly divisible to aid in finding an appropriate cell for the layer break flag. This misconception is also why I thought I had seen actual original master DVDs written the same way.

 

So, all is right with the DVD burning world - ImgBurn's algorithm for choosing the flag is correct, and so is RecordNow Deluxe's!

 

Thanks for the layer break education. I would now know enough to go back and manually set a layer break with the DVDD utility - before this, I was clueless on how to set an appropriate one, so I used to burn ISOs without MDS files blindly with DVDD before I realized I was not ensured of getting an appropriate layer break to corresponding to a flag. That's when I began just extracting the files and using RecordNow.

 

Once ImgBurn is fixed to take care of the math overflow problem, I expect ImgBurn will be making perfect copies with appropriate layer breaks from these ISOs!

 

Thanks again,

 

fordman

Edited February 18, 2006 by fordman

[LIGHTNING UK!]

If you're manually setting the layerbreak position, ImgBurn will behave the same way as DVD Dec and the maths overflow problem doesn't even come into play.

 

I'm hoping to release 1.2.0.0 tomorrow.

[fordman]

If you're manually setting the layerbreak position, ImgBurn will behave the same way as DVD Dec and the maths overflow problem doesn't even come into play.

 

I'm hoping to release 1.2.0.0 tomorrow.

 

After writing that, I realized that ImgBurn also has this ability to enter the number of Layer 0 sectors. However, after burning a few backups and watching the progress windows state where layer 1 was starting, I think I might still have trouble translating the position of the layer break flag in the main VTS title set to the actual physical location on the disc in terms of Layer 0 sectors, so I still need to do more homework on this.

 

Also, I would imagine that entering this manually would only be helpful for those ISOs that have no MDS file, but already DO have a layer break flag in the main VTS. For an ISO with no flag set, it would merely instruct ImgBurn where to physically put the break, but it would not alter that IFO/BUP files to point to it. Is this correct? If so, then the automatically functionality built into ImgBurn to do all this is indispensable...

 

Thanks for the awesome utility - looking forward to 1.2.0.0!

 

By the way, did you ever see my PM concerning a donation? I'd like to send one if you can help me work around the electronic payment means for the reasons I stated...

[LIGHTNING UK!]

Your best bet is to just rebuild the ISO using PgcEdit and have it pass the correct layerbreak LBA to ImgBurn.

 

An ISO without a layerbreak flag in the IFO is unlikely to have a cell in the right place for ImgBurn to add one.

 

I don't recall seeing a PM, no. That said, I cannot really help beyond Paypal or Nochex anyway. I appreciated the offer though

[fordman]

Your best bet is to just rebuild the ISO using PgcEdit and have it pass the correct layerbreak LBA to ImgBurn.

 

An ISO without a layerbreak flag in the IFO is unlikely to have a cell in the right place for ImgBurn to add one.

 

I don't recall seeing a PM, no. That said, I cannot really help beyond Paypal or Nochex anyway. I appreciated the offer though

 

Thanks for the recommendation. I do use PGCEdit for preparing video files for burning in file mode, but I have yet to build an ISO with it.

 

Your second sentence confused me a bit. That type of ISO is what began this thread. It was an ISO made by CloneDVD, which had already stripped out the layer break flag, but ImgBurn was able to find an appropriate cell and made the right change on the .IFO, but of course the calculation problem caused other issues.

 

I had PM'ed you about sending a certified check or something because I've head my credit card number used fraudulently twice here in the U.S. Once someone opened a PayPal account with my credit card info, but had all correspondence sent to an e-mail account that I didn't know about. Another time it was a local merchant. Both times, I had to fight to get my money back, and PayPal actually tried to refute/rebutt the chargeback! On the phone they admitted that because of the nature of the product and other circumstances it was an obvious fraudulent transaction, but their credit card department tried getting back the money my bank had charged back anyway! They were going for what they assumed would be the path of least resistance. Each time, it appears that my CC info was used by a dishonest employee at a vendor I do business with, and stores my CC info for recurring monthly charges.

 

So, I refuse to do business with PayPal and I'm reluctant to send my credit card info overseas, figuring it would be even harder to recover a fraudulent charge. I had proposed sending a bank certified check or money order to you via a post office box or other address, and using whatever name or business name you could use to cash it.

 

I really enjoy your utility and it has made my life easier, so I'd hate to not say thanks by making a donation.

 

 

fordman

[LIGHTNING UK!]

Sorry, I tend to just remember the post I'm replying to rather than all the details mentioned earlier! My brain runs out of space otherwise

 

It's stupid of CloneDVD to go to the trouble of building a nice DL ISO and then not inserting the layerbreak flag in the IFO - hence it was probably just a fluke that a cell landed on a nice LBA.

On the other hand, if CloneDVD really does do it nicely, you should have a word with Olli and get him to change how it works.