Burned Image Padded with 16kb

[Mabel]

I suspect I've found a bug in Imgburn that has been around from the start, and is not related to one version nor OS, nor hardware. I've had the error infrequently and randomly, over several versions of 2.x, Win XP and Win7.

 

When burning a bootable DVD, the verify option finds no errors. However, when copying the ISO back to disk, it is 16kb longer than the original ISO used to created the DVD.  This oddity can depend on the type of blank used. A DVD-RW does not suffer this error, but a DVD-R does. The extra bytes are added to the end of the ISO. Using unix tools, truncating the ISO to the correct length yields the  correct checksum.

 

The extra 16kb causes problems with writing the ISO to a bootable USB stick, as the recorded fs length in the ISO header is not the same as the true file length.

 

An example ISO with this problem is the Win8.1x64 install DVD from MS.

  File: en_windows_8_1_x64_dvd_  <remove spaces>  2707217.iso

SIZE: 3899295744 byte

SHA1: BC2F7FF5C91C9F0F8676E39E703085C65072139B

 

(Search for the SHA1 on various torrents.)

 

Any comments?

 

[Mabel]

After experimenting with CDBurnerXP, this problem seems to be a part of windows, both XP and Win7, rather than the 3rd party burning app.

 

Writing and reading with CDBurnerXP produces exactly the same problem. The re-read file is 16kb too long. No real issue for optical disks, but USB apps like YUMI, will fail to work with these appended ISO files.

 

I've repeated this experiment with k3b in Linux, and there were no problems at all. So, H/W issues on my computer can probably be dismissed.

[Mabel]

I've made some progress here.

The ISO+UDF file as supplied by MS is not compliant. It is not a multiple of 16kb, and does not have the last anchor sector. When burning to a DVD+R, ImgBurn pads out the DVD to the 16kb boundary and sets the last anchor sector. It does not reset the the total filesystem length variable.

 

When burning the same non-compliant file to a DVD+RW, ImgBurn does not appear to do the end padding, and the total length is the identical to the ISO file.

 

If a padded ISO is retrieved from media, the actual file length can be larger than what is recorded in the filesystem.  This ISO will not work correctly with apps, such as YUMI, that write the ISO to a bootable USB stick. If the ISO is truncated back to the original length, then YUMI will work fine.

Edited April 14, 2014 by Mabel

[LIGHTNING UK!]

The padding is nothing to do with the program, your drive is doing it.

[Mabel]

My concern is extracting the ISO from DVD, and using it with other apps. My ISO apps all complain and exit when confronted with the length inconsistency.

 

For the above example, the length recorded in the ISO header is 15 sectors shorter than its real length on HDD. Once the file is truncated to this length, then all the apps are happy to work with it.

 

Perhaps a good way around this is for Imgburn to truncate any extracted ISO file to the exact sector count, as recorded in the header. It could issue a warning if any of the truncated bytes are not 0x0, ornot  a UDF anchor, as appropriate.  The logical sector size  in the header should be used, rather than just assuming it is 2k.

Edited April 14, 2014 by Mabel