Question burn DVD ISO end-of-disc padding

[BitBasher]

I've burned a few DVD's recently of some linux distros in order to try them out.

When I get the .ISO file, I check it's MD5 digest to ensure the ISO file is good.

After burning the ISO to DVD-R using Nero 7, I ran IsoBuster to see if the burned DVD has the same MD5 signature. It didn't. :(

I discovered that ALL my ISO files once burned to DVD-R seem to be rounded up to the nearest 16-sector (32K) multiple. That is, there is more data on the DVD at the end than what was in the original ISO file. This of course causes the resulting MD5 digest of the DVD media to be incorrect.

As a double check, I extracted one of my burned DVDs (using IsoBuster) then I "removed" the extra padding sectors at the end of the image file and then re-ran the MD5 check. When I do this, then I get an MD5 match. This means the disc was burned OK but with extra sectors at the end.

My question is, what is adding these extra padding sectors (Nero or my LiteOn DVD drive)? Also, can I disable this feature so that a burned DVD has the EXACT number of sectors that were present in the ISO file?

Thanks,
Bit.

[LIGHTNING UK!]

If you're using DVD+R media, the drive always pads to the nearest 16 sectors and there's nothing you can do about it. Use DVD-R media instead.

ImgBurn actually quotes real MD5 + padded MD5 values in it's log when burning / verifying so this ISO Busters step could be done away with.

[BitBasher]

Thanks for the reply!

I am using DVD-R media. I guess there's a possibilty that Nero is doing this padding, even though it's not DVD+R media and I'm writing an ISO file.

I read somewhere that on DVD video discs the VOB files (or their sections?) need to be 32K aligned. I'm wondering if Nero is doing padding at the end of the disc even though it's mastering an ISO - it might be a minor bug.

Anyways, I'll give ImgBurn a shot and see if I still get end-of-disc padding. If I do, then maybe my LiteOn drive is doing it (booo). The two MD5 digests reported from ImgBurn sounds way cool - I like it!

Bit.

[kumi]

So that's why I can't get the same hash from some re-ripped DVDs...

@LUK: Is it possible to create an .ISO with ImgBurn/dvddec that is always padded to the nearest 16 sectors? I'm looking for a way to reliably get a hash match from a re-ripped .ISO, no matter if the original had been "ImgBurned" on DVD+R or DVD-R.

[LIGHTNING UK!]

No, it reads the size exactly as reported by the drive.

[holst]

So what's the score with the padding? It's not only zeros is it? How can I reconstruct the padding myself? For instance, what does DVDDecrypter or ImgBurn pad with?

[holst]

Look at this:

Falling down (The "DD" (raw iso image) ends at offset 4441219071)
http://img524.imageshack.us/img524/3848/fallingdownpd9.th.jpg (http://img524.imageshack.us/my.php?image=fallingdownpd9.jpg)

Gladiator (The "DD" (raw iso image) ends at offset 73615421243)
http://img501.imageshack.us/img501/6040/gladiatorfh4.th.jpg (http://img501.imageshack.us/my.php?image=gladiatorfh4.jpg)

There is some kind of "intelligent" data being added to the equation that an ordinary "copy from device" (using windows 'dd') does not get. What the h--l is it? :confused:

[LIGHTNING UK!]

The final sector on a disc with a UDF file system is supposted ot be a backup 'anchor' - which is all part of the FS.

If the actual image didn't end on a sector divsibile by 16 and you burnt to DVD+R media, I'm sure the drive would just pad with zeroes.

Of course if you're using UDF, that's very bad because the anchor is supposed to be the last sector.

When ImgBurn builds and image (i.e. from 'Build' mode), it ensures the size is divisible exactly by 16 and that the last sector is indeed an UDF backup anchor.