Size of DVD Contents smaller than actual ISO Size

[aritchie]

Hi Support,

We're using ImgBurn to create our ISO images for our product, and this seems to be fine.

 

I have a question about a discrepancy between the file size of the ISO image and the size of the DVD (burnt from that ISO image) in Windows Explorer. In all the instances I've checked, the Windows Explorer reported size of the DVD is smaller than that reported for the ISO image. If I open the DVD in either ImgBurn or ISOBuster, or rip the DVD using ImgBurn or ISOBuster, then I see/get exactly the correct size which matches the original ISO.

 

However, a colleague of mine is using a tool called MagicISO to rip the DVD's I send to an ISO image (don't ask why they can't just take the ISO I created) and the ISO that this creates has a size identical to the one displayed by Windows Explorer. If I then compare the ISO I created with the ISO created by MagicISO, I see that the only difference is that the ImgBurn ISO contains additional zero-byte padding at the end of the image. All files/directories within the ISO images are present and correct.

 

This causes us a problem because the MD5's generated for both ISO's are different (because of these additional bytes).

 

Can you explain why they are being added and is there a way to disable the adding of these bytes or, alternatively, make the reported DVD size agree with the ISO size? (I suspect that MagicISO is using the content size to rip just that number of bytes rather than whatever other parameter gives the full image size and - whilst I think that is probably wrong - I'm not sure I can dissuade them from using it in favour of ImgBurn as they have actually purchased a license for it and have been using it successfully for 5yrs).

 

As an aside, is there any way, or tool, to look at what information is being recorded in the DVD Header, with respect to these size parameters?

Regards,

Andrew

[LIGHTNING UK!]

Are you actually 'building' the ISO with ImgBurn or just burning one that something else has created?

 

ImgBurn always 'builds' images that are a multiple of 16 sectors (1 ECC block on DVD) in size. This is because burning to DVD+R always pads in this way - and that's a drive thing which cannot be disabled.

 

Burning 'non multiple of 16 sectors' size images to DVD+R also causes MD5 issues when reading the disc back, hence my reason for ensuring the image is a multiple of 16 sectors in the first place.

 

Explorer doesn't list the physical size of the disc, it lists the size of the file system. Which file systems are present in the image you've got/are creating?

 

When ImgBurn reads a disc, it uses the physical size as reported by the TOC / track information... I guess MagicISO uses the file system size.

[aritchie]

> Are you actually 'building' the ISO with ImgBurn or just burning one that something else has created?

 

Yes, we're using ImgBurn to create the ISO's.

 

> ImgBurn always 'builds' images that are a multiple of 16 sectors (1 ECC block on DVD) in size. This is because burning to DVD+R always pads in this way - > and that's a drive thing which cannot be disabled.

>

> Burning 'non multiple of 16 sectors' size images to DVD+R also causes MD5 issues when reading the disc back, hence my reason for ensuring the image is a

> multiple of 16 sectors in the first place.

 

I suspected it might be something like this. How big is a sector? i.e. what's the maximum size that could be added as padding?

 

> Explorer doesn't list the physical size of the disc, it lists the size of the file system. Which file systems are present in the image you've got/are

> creating?

 

We create an imgae with ISO9660 (plus extensions) + Joliet + UDF v1.50. MagicISO doesn't appear to give you the option for any filesystems so I suspect it would only create ISO's with Joliet (and hence probably only looks at the Joliet related info - based on your comments above). If there isn't an option to turn off the adding of these sectors (as we typically use DVD-R discs) then I think the only option I have (if I can't persuade them to use ImgBurn) is to try and persuade them to take the ISO image I create rather than, as now, burning this to DVD, sending them the disk and them ripping it back to an ISO.

 

Thanks again (and nice to see the new version of ImgBurn and the option you added to disable the halting of more than 1000 warning messages :-).

Edited March 16, 2010 by aritchie

[LIGHTNING UK!]

Well, if you're building it in Mode 1 format, a sector is 2048 bytes. At most, there would be 15 'padded' sectors so that's 15 * 2048 = 30720 bytes.

 

The thing is, if you're using UDF then the last sector is an anchor and it can't just be missed off (it would fail UDF tests) - regardless of what the ISO9660 or Joliet file systems report for the size (they wouldn't include the anchor (or the padding before it) as it's not part of them). So if that's what MagicISO is doing, it's doing it wrong!

[aritchie]

> Well, if you're building it in Mode 1 format, a sector is 2048 bytes. At most, there would be 15 'padded' sectors so that's 15 * 2048 = 30720 bytes.

 

Yes, we're using Mode 1 format.

 

> The thing is, if you're using UDF then the last sector is an anchor and it can't just be missed off (it would fail UDF tests) - regardless of what the

> ISO9660 or Joliet file systems report for the size (they wouldn't include the anchor (or the padding before it) as it's not part of them). So if that's what

> MagicISO is doing, it's doing it wrong!

 

Wow - didn't expect an answer that quick! I'll need to read up about the UDF anchor. If I were on a system that mounted/used the UDF filesystem on the disk, what would be the ramification of not having the anchor? Would it fail to display or read the last file or would if have problems with the whole disk?

Edited March 16, 2010 by aritchie

[LIGHTNING UK!]

Luckily, there are 2 anchor points (or 3 if you fancy it).

 

Sector 256, last sector - 256 and last sector.

 

I personally don't bother with the 'last sector - 256' one.

 

They're the first thing you look for when parsing the file system really. So if damaged, you're stuck (unless you fall back to 'bodge' parsing at common addresses).

 

Of course by 'stuck' I mean the UDF file system is unreadable. The OS would then fall back to Joliet I guess.

 

All of that is beside the point though, it shouldn't be dropping those sectors in the first place.

[aritchie]

Thanks again.

 

Do you know of any tools that could perform validation of the ISO image or disk to know whether it could give rise to problems (without actually having to find a system on which the disk actually fails)?

 

I'm trying to remember which of the OS platforms we support actually mount the UDF filesystem by default - might be Linux or Solaris. If it's Solaris then it wouldn't support Joliet (only RockRidge - don't know if it would fall back to ISO9660 either) so they might be suitable test systems but if there is some tool I could run to check an image, then that might be easier.

Edited March 16, 2010 by LIGHTNING UK!

[LIGHTNING UK!]

Nope, but I'm sure there must be something - probably something a mastering plant would use. ($$$$)