Sidestream84 Posted June 17, 2007 Posted June 17, 2007 (edited) 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 Posted June 17, 2007 Posted June 17, 2007 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 Posted June 17, 2007 Author Posted June 17, 2007 Ah, makes sense. Thanks for the quick response.
blutach Posted June 17, 2007 Posted June 17, 2007 The 16k is basically positioning the data on the next ECC boundary. Nothing to worry about. Regards
Recommended Posts