Burning an image vs contents of Disc

[Sidestream84]

Sorry if this was answered somewhere already, I tried doing a search and read the FAQ and couldn't find it (maybe I wasn't using good search terms?).

 

I just got my first +DL media for a dual layer burner I've had for quite some time, and I noticed the data that was written to the disc is 16KB larger than the original ISO I burned it from. When creating a new ISO from the copy, that ISO is also 16KB larger (exactly: 16,384 bytes).

 

Both the ISO and the new disc show the layer break at "Layer 0 Sectors: 1,692,416 (50.31%)" (which was already set in the original and has "SPLIP No"). I noticed the log says:

I 03:07:17 Device MD5: 67f46d07c34d1eb6663e8625d5fd5b28

I 03:07:17 Device (Padded) MD5: a29c28f48adcf4679a092153ebae8326

I 03:07:17 Image MD5: 67f46d07c34d1eb6663e8625d5fd5b28

 

and that's consistent with my tests... the original ISO's MD5 does match that when I test it, and if I re-rip the burned copy, that ISO's MD5 matches what "Device (Padded)" Says.

 

So my question is, where is the extra 16KB coming from? I didn't see anything in Write preferences that sounded like it would add padding, and I assumed the 32KB IFO/BUP padding (in "Build") wouldn't apply to already existing ISOs (am I wrong?). I'd prefer to be able to have an "exact" copy, but it's not a big deal if there's some reason for it.

 

Thanks

Edited June 17, 2007 by Sidestream84

[mmalves]

From ImgBurn's changelog:

• Added: An alternative 'Padded' MD5 calculation for when burning + verifying an image on DVD+R media where the drive automatically pads the image so the last sector is divisible by 16.
  

As you an see, it's the drive that does this, not ImgBurn.

[Sidestream84]

Ah, makes sense. Thanks for the quick response.

[blutach]

The 16k is basically positioning the data on the next ECC boundary. Nothing to worry about.

 

Regards