CRC/SHA-1 Mismatch

[adric]

If I take an ISO and burn it to a DVD with ImgBurn and then create an ISO from that DVD, the crc/fsum of the original ISO and the newly created ISO are not the same. I would have thought the ISOs would be identical. Any reasons why this is not the case?

 

Thanks ...

Edited November 12, 2012 by adric

[LIGHTNING UK!]

Drives sometimes round up the amount they burn to the disc so it's a multiple of the ECC block size (16 sectors).

 

So even if you just want to write 2 sectors worth of data to the disc, it'll come out looking as if all 16 have been used. The 14 at the end will just be filled with zeros or whatever the drive wants to put there.

[adric]

That's interesting because if I take the new ImgBurn ISO and try and use it with Microsoft's Win7 USB/DVD Download Tool, I get invalid ISO. The original ISO that I burned the DVD from works fine.

http://www.microsoftstore.com/store/msstore/html/pbPage.Help_Win7_usbdvd_dwnTool

http://images2.store.microsoft.com/prod/clustera/framework/w7udt/1.0/en-us/Windows7-USB-DVD-tool.exe

Edited November 12, 2012 by adric

[LIGHTNING UK!]

What happens if you mount the ISO in a virtual drive program or open it in IsoBuster?

 

Are the files not then accessible in Explorer or visible in the IsoBuster main window?

 

Do you have logs of the burn / read operations?

 

I'd only expect the 2 files to differ by up to 15 sectors worth of data (15 * 2048) and those differences would be at the very end of the larger image.

[adric]

I can see the actual files when using WinRAR or ISOBuster main window. 7-zip File Manager (9.20) only shows the special README.TXT and a Bootable_NoEmulation.img (I don't see this .img file with the other progs) On the original ISO, 7-zip shows the actual files just like WINRAR and ISOBuster main window.

ImgBurn.log

Edited November 12, 2012 by adric

[LIGHTNING UK!]

This is problem when drives do what you're experiencing.... the UDF spec says there should be an 'anchor' in the last sector and if they add dummy data after that point, the last real data sector is no longer the last physical sector!

 

So anything that only looks for it in the last sector will fail to find it and just give up.

 

Going by your log...

 

I 12:39:10 Source File Sectors: 1,285,381 (MODE1/2048) - Original ISO

 

I 13:04:59 Source Media Sectors: 1,285,392 (Track Path: PTP) - Burnt disc

 

... if you were to remove (11 * 2048) bytes from the end of the new ISO created from the burnt disc (via a hex editor or whatever), it would match the original one exactly.

 

When ImgBurn builds ISO files from scratch, it always makes sure their size is a multiple of 16 (or 32) sectors so this kind of problem doesn't happen.

[adric]

Is there an option one could enable in in ImgBurn to not fill the ISO out with the (11 * 2048 or whatever) bytes when creating the iso from the DVD and would that not solve this particulat problem?

 

Maybe I'm misunderstaning. What did my drive do wrong burning the orignal ISO?

Are you saying it did not write an 'anchor' on the DVD?

Edited November 12, 2012 by adric

[LIGHTNING UK!]

It's not ImgBurn that's doing the filling/padding, it's the drive.

 

I send it X sectors worth of data to burn, it's burning X+11 so the total count is a multiple of 16. I have no control or say in the matter.

 

I'm saying it wrote the anchor (as that's part of the data I told it to burn), but it then added another 11 sectors worth of padding.

 

The last sector on the disc is then just one of the padding sectors and NOT the UDF anchor like it's meant to be.

 

Anchors can be in 3 places though, so even if the last one isn't there, programs could still check the other 2 positions. Even though another of those 2 would also be invalid (last sector - 256), the first one (sector 256) should be fine. For some reason, Microsoft's tool doesn't seem to want to use that one.

 

Here's a bit of info on UDF anchors.

 

http://www.cnwrecovery.com/manual/UDFAnchorVolume.html

[adric]

Now I get it. Thanks for the explanation.

Edited November 13, 2012 by adric

[LIGHTNING UK!]

The ECC block padding issue has always been there if you write to DVD+ (plus) format discs.

 

It was never an issue on DVD- (minus) discs though.... except some newer drives have even started doing it on those now too!

 

Maybe if you've got some DVD-R or DVD-RW discs you could try it and see what happens?

[adric]

You are right ... I used a DVD+. I will try with a DVD- and let you know. I also have a DVD burner in my laptop

that I could use to see if it behaves the same way as the LG external drive.

 

If -R or -RW reduces the risk of the problem I encountered. then I guess it's time to switch to those.

 

Thanks again..

Edited November 13, 2012 by adric

[adric]

Sorry for taking so long to get back to you on this. I never got around to getting some -R Discs to test with. Anyway, I reran my tests using a Verbatim DVD-R disc and the original iso and the DVD have identical CRCs. I then took the burned DVD and created a new iso from that and the CRC for the new iso is also identical. Your diagnosis of the problem was right on the money. I'm sticking with -R/-RW from now on.

 

You mentioned that some of the newer drives are even starting to use ECC block padding with -R media. Is there any way to tell if a burner does this from the specs to avoid me going out and buying the wrong one?

 

Thanks