Jump to content
Sign in to follow this  
adric

Media Used Space does not match ISO size

Recommended Posts

UP until now, when I burned a CD/DVD from an iso file, the sizes were the same. I.e. after burning Win7, the used space and iso file size is the same. I have an iso file and a CD where this is not the case. As far as I can tell, the CD is okay. If I build an iso from the CD, the size of the iso is 1,245,184. If I take that iso and reburn the cd, the used space shows 1,226,752. I don't understand the loss off 18,432 bytes.

 

If I mount the CD with IMGBurn or ISOBuster, they show the same size as the iso. Anyone know what is causing windows to see less on the media in this case?

 

I often use crc305.exe to check the media against its' iso for verification. This is how I noticed the size difference. Windows properties from the CD shows the same size as crc305.

 

Al

Share this post


Link to post
Share on other sites

Windows shows the size of the files, the ISO is obviously more than just files.

 

So what you're seeing is perfectly normal.

Share this post


Link to post
Share on other sites
Windows shows the size of the files, the ISO is obviously more than just files.

 

So what you're seeing is perfectly normal.

 

I'm not sure what you mean by "more than just files". How do I find the "more than just files" data that windows is not seeing?

 

If I build an iso from the CD, should the sizes not be the same?

 

 

Al.

Edited by adric

Share this post


Link to post
Share on other sites

What do you mean 'find it' ? It's not something you can look at in explorer, that's why the size is different.

 

An ISO has a file system an X amount of padding (as well as the file data itself). Windows doesn't take all that into account.

Share this post


Link to post
Share on other sites
What do you mean 'find it' ? It's not something you can look at in explorer, that's why the size is different.

 

An ISO has a file system an X amount of padding (as well as the file data itself). Windows doesn't take all that into account.

 

Okay, if ithat is case, then I don't understand why all my other backup iso files have the same size as their respective CD/DVDs that they were built from. Also, crc305.exe works in sector mode when it is run against a CD/DVD. If there is no corruption, the crc and size of the CD/DVD will match that of the iso..

 

Could the iso burn process possibly be dropping some of the padding from the CD?

That would account for the size difference.

 

Al

Share this post


Link to post
Share on other sites

The only time you might run into something where padding makes a difference is if you burn an image to a DVD+R disc.

 

The drive will always round the total number of sectors up to a multiple of 16.

 

The size ImgBurn reports once the image has been load into Write mode should be the same as the disc info that's reported in the area on the right once the burn has finished. Just ignore what Windows says.

Share this post


Link to post
Share on other sites
The size ImgBurn reports once the image has been load into Write mode should be the same as the disc info that's reported in the area on the right once the burn has finished. Just ignore what Windows says.

 

Yes, that is correct. The problem with ignoring what windows says is that I cannot easily verify the ISO file against the CD/DVD with crc305 if if there is a file size discepancy.

 

Anyway, I did some more checking and it turns out that imgburn added 9 sectors to the end of my data when using 'Create Image File from files/folders. 2048 x 9 = 18432 which is the file size discrepancy that windows does not see. I ran another program to create an ISO from the CD/DVD and it dropped those 9 sectors when it created the ISO which now matches the CD/DVD size that windows reports. The question is whether those nine sectors that were added by imgburn were necessary because they contain hex 00 up until the very last sector which starts with hex 02000200 2F000100 01D7F001 5F020000 00800000 20000000 00800000 30000000 and the rest hex 00

 

Thanks for you time. If you have another suggestion of how to verify an ISO file against an already burned CD/DVD I could switch to that.

 

Al

Share this post


Link to post
Share on other sites

When building an ISO from scratch, ImgBurn will make it a multiple of 16 sectors so it can be burnt to DVD+R without the 'feature' I mentioned earlier becoming an issue.

 

The last sector in a UDF volume is supposed to be an 'anchor' (used when parsing the file system) - which is what you're seeing when you look at it with your hex editor / sector viewer. If ImgBurn hadn't made the image size a multiple of 16 sectors (which is 1 ECC block), when burnt to DVD+R there would be no 'anchor' in the last sector and as such it fails one of the UDF validation checks.

 

I would have mentioned that earlier but I was under the impression you were just using read/write modes - whereby padding/alignment is not my problem.

 

If you want to verify a disc against an ISO, just use ImgBurn's Verify mode - that's what it's there for!

Share this post


Link to post
Share on other sites
If you want to verify a disc against an ISO, just use ImgBurn's Verify mode - that's what it's there for!

 

Blush ... I totally missed that in the drop-down. Sorry....

 

Al

Share this post


Link to post
Share on other sites

This is well interesting, I've been looking for this sort of info for ages. Thanks.

Just to make sure my two bit brain can deal with:

I often get iso's that are much larger than when I look at the video files inside using WinCommander.

Last one had a difference of nearly 10% eg 7.52 vs 6.85 gb.

Can the difference be so much just because of padding?

Share this post


Link to post
Share on other sites

Yes, a lot of padding can be added to align the cell with the layerbreak, and this is all according to the DVD-Video standard.

Share this post


Link to post
Share on other sites

Cheers mmalves, you just took a load of weight of my shoulders. Brasil is it? Did you hear my sigh of relief?

Share this post


Link to post
Share on other sites
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.