.iso checksum does not match source

[Digitoxin]

When creating an .iso image from a DVD, the checksum of the .iso image does not match that of the DVD. I confirmed this by starting with an .iso image. Burning it to a DVD and then creating a new .iso from the DVD I just burned. The checksum of the original .iso and the DVD match. The checksum of the second .iso file is different. Why is imgburn modifying the .iso image and not creating an exact image of the DVD?

[LIGHTNING UK!]

What did you burn it to? DVD-R or DVD+R?

 

What type of disc was it in the first place? Video, data etc

 

What drive do you have? Copy + paste the disc info from the panel on the right when you're in Read mode with that disc in the drive.

[Digitoxin]

I burned to DVD+R. It is a data disc. I did some more experimenting and tried 2 other programs to create an .iso from the DVD. UltraISO produced an .iso with a different checksum than the DVD. MagicISO is able to create an .iso with a checksum matching the DVD. I also tried with an original store bought DVD (My Windows 7 DVD) with the same results. The .iso created with imgburn has a different checksum than that of the DVD. MagicISO created an .iso with a matching checksum. I'm going to do a comparison of the two .isos to see what imgburn is changing in the image. I'll post my results here.

 

 

What did you burn it to? DVD-R or DVD+R?

 

What type of disc was it in the first place? Video, data etc

 

What drive do you have? Copy + paste the disc info from the panel on the right when you're in Read mode with that disc in the drive.

[LIGHTNING UK!]

You can only burn images that are a multiple of 16 sectors to DVD+R and have them kept 100% the same.

 

If they're not, the drive will automatically pad the last ecc block (16 sectors) on the disc.

 

So... if you burn 17 sectors to a DVD+R, it'll actually show up as 32 sectors (check the disc info on the right yourself!) - which will be what's then read back (not the original 17) - and there you have your difference.

 

When ImgBurn is used to 'build' an image, it always makes sure the size is a multiple of 16 sectors and that's why.

[Digitoxin]

I'm not sure if this is the what is causing the problem in my case. I start with an .iso file. I'll use an .iso downloaded from MSDN as an example. Microsoft provides a SHA1 and CRC32 hash for each .iso. The .iso matches both hashes. I then burn the .iso to a DVD+R using imgburn. If I check the disc itself, the hashs still match that of the original .iso. If I extract the disc back to an image using MagicISO, the new .iso image has the correct hashes. If I extract the .iso using imgburn, the new .iso has incorrect hashes. If imgburn is padding the image when writing it to the DVD+R, wouldn't the hashes of the disc itself and of the .iso that MagicISO creates also be incorrect?

 

You can only burn images that are a multiple of 16 sectors to DVD+R and have them kept 100% the same.

 

If they're not, the drive will automatically pad the last ecc block (16 sectors) on the disc.

 

So... if you burn 17 sectors to a DVD+R, it'll actually show up as 32 sectors (check the disc info on the right yourself!) - which will be what's then read back (not the original 17) - and there you have your difference.

 

When ImgBurn is used to 'build' an image, it always makes sure the size is a multiple of 16 sectors and that's why.

[LIGHTNING UK!]

It depends on how magiciso is reading the disc. It might just rely on file system info rather than asking the drive how big the disc is.

 

Switch to read mode and copy + paste the disc info from the panel on the right.

 

You should (in theory anyway) see that the number of sectors on the disc doesn't match the number in the ISO you downloaded.

 

The number shown under the file system heading might do though.

 

p.s. ImgBurn isn't doing the padding, your drive is.