a burn size anomaly - is ImgBurn 2.4.0.0 buggy?

[JohnnyBob]

While backing up one of my movies...

The movie as ripped to the hard drive is 5.1 GB according to DVD Shrink. It also says 5.1 GB if I hover the mouse pointer over the movie folder in Windows Explorer. I also obtain 5.1 GB as the size if I look at the properties of the VIDEO_TS folder on the hard drive. If I open the VIDEO_TS folder of the burnt disc, there are 5 VOB files each 1 GB, plus a couple of small ones, and that simple method also yields a size of 5.1 GB.

However...

After the movie was burnt with ImgBurn 2.4.0.0 onto a Verbatim DVD+R DL (MIS) disc, the space used on the disc is 6.2 GB, as determined in several ways. Nero CD-DVD Speed reports that the burnt disc uses 6.2 GB of space (and a quality scan looks normal). Also if I look at the properties of my DVD drive with the burnt disc inserted, it says the used space is 6.2 GB.

The movie plays OK.

I haven't encountered this phenomenon before. Where is that extra 1.1 GB coming from? How can this happen? I've checked several other of my recent DL burns and their sizes before/after are normal.

Is the recent 2.4.0.0 version of ImgBurn buggy? It usually works OK, but has behaved strangely with a couple other burns too. For example it refused to verify one of my burns, because it couldn't read the disc ID (it said), which has never happened to me before. That movie plays fine, nevertheless. And in another instance when I started to burn a disc, it said my settings were wrong, and asked if I wanted them to be adjusted. That never happened to me before either.

So I'm thinking about reverting to the prior ImgBurn 2.3.2.0 version which had no such problems with several hundred successful burns over the past year. Anybody else?

[redwudz]

I haven't noticed any problems. I've burned a couple of DL discs and about 10 single layer discs, Vebatim and TY, with ImgBurn 2.4.0.0 and they all came out fine.

[Jim44]

Maybe this explains it(?):
http://forum.imgburn.com/index.php?showtopic=5973&view=findpost&p=62564

Dunno - 1.1GB does seem like a lot extra.

I've only burned about 6-8 discs so far with 2.4.0.0 and they've been OK as well.

[JohnnyBob]

Thanks for the info. So the answer is... DVD+R media must have a total number of sectors which is divisible by 16, else padding is required and is automatically inserted by the drive (not the software). I suppose that is true of each layer on a DL disc.

I reinstalled the prior version of ImgBurn and soon discovered that it's not a problem with the new 2.4.0.0 version. The prior 2.3.2.0 version reports the data the same way... It is a layer break-related phenomenon. Depending on which layer break I select, the image size can be a lot bigger than the total file size. The total file size is 5,469,771,776 bytes for this movie. With the most extreme layer breaks selected, the image size can range from 5,470,420,992 bytes to 8,521,383,936 bytes. So that's up to a 3 GB difference

Apparently this has been happening all along. I probably wouldn't have noticed it here except the size difference was pretty obvious via a Nero CD-DVD Speed scan, which I just recently started using.

[VegasBud]

JohnnyBob,

That's correct. The layer break choice can have a large effect on the disk space required. In ImgBurn, the leftmost column in the layer break selection window ("LBA") shows the logical block address of the item before and after being shifted so it falls in the layer break window. The second column ("Padding") is the distance (in sectors) that point had to be shifted to become usable as a layer break. Since a sector is 2048 bytes, multiplying the padding figure by 2048 will give you how many bytes of additional disk space will be required to use a given point as the layer break point.

You probably hadn't noticed it before because you were previously working with much larger source material sizes, which wouldn't allow that much padding.

Since a disk becomes harder to read as the data approaches the outer edge, the less padding used, the less potential playback problems. I always check the lowest padding choice first, and then move up to more padding if necessary to get a visually pleasing layer break.

Of course if the padding is low for a given choice, but the third column ("%") is skewed far from 50/50 (50% is on the first layer, 50% is on the second layer), you end up with the same problem as large amounts of padding.

That's why layer break selection is part science, part art...and why no computer algorithm can replace the human touch.