ImgBurn2 Verify Failure: Curious as to Why ?

[Seeker47]

This has happened to me a few times -- I think only with DL backups. (Using only Verbatim MIS DL blanks.) This is after most-recent-versions FabDecrypter rips, then closely following the steps prescribed in the ImgBurn2 guide -- setting the layer break with 32K gaps 'n all. I'm not sure there is any other consistent factor, other than ImgBurn showing only Average-rated candidates for the layer break position, or perhaps the next highest rating over Average. Burns were done at either 2.4x or 3x for the 6x rated Verb DLs, with a Pioneer 108 burner.

There were sometimes multiple points of Verify failure (CRC mismatches ?), which might have coincided or begun with the layer break area -- but I'm not sure. In most of these cases where the Verify Pass "failed", it looks to me like it must have been some nitpicky technical failure that has little practical importance: most of these backups play just fine, with no evident defect. So, what does this all mean ?

[VegasBud]

Seeker47,

Verify compares the data actually on the burned disk with the source material that was theoretically just written to the disk. If they aren't identical, Verify fails.

The layer break is the point at which the data switches to being written on the second layer instead of the first layer. It isn't part of the data, and doesn't change the data, just where the data is being written. Consequently, the layer break doesn't directly affect Verify.

The layer break choice could influence whether a disk can verify, however, if the data is disproportionately distributed between the layers (much more is written to the first layer than the second) which moves the layer break (and the data on either side of the layer break) closer than necessary to the error prone outer edge. Since you're using Verbatims, that shouldn't be a problem, but it might have a significant effect when using lesser media.

Is a verification failure "some nitpicky technical failure that has little practical importance"? Maybe yes, maybe no. All it takes for verification to fail is one bit of one byte to be different from the source material. Even if only one bit is in error, depending on which bit of which byte it is, you could get anything from a slight color shift of one pixel for one frame of video, to a complete failure of the disk to work.

Each person has their own standards and goals, so you should decide for yourself how (or if) a verification failure should be handled. Personally, I sleep better at night if everything I burn verifies correctly.

[JohnnyBob]

When I get a verify error, I just toss the disc and burn another. I've never tried to play bad burns. I suspect some of them would play, for example when the verify error occurs at the 99% point, but I don't know.

If you have a Lite-On or Benq available, scan the discs with something like Nero CD-DVD Speed to get a better idea about your disc quality and burn quality. Otherwise we're just guessing.

Also, if you have 4x, 6x, or 8x burn speed available for those MKM001 discs, try it. Sometimes faster is better. I've burned all of my MKM001 MIS/MII at 4x with less than 1% failures with the MIS, 5-10% failure rate with the MII. Recently, I've quality scanned some of those burns with Nero CD-DVD Speed and all look pretty good. The MIS scan somewhat better than MII but both play OK.

[MOVIEGEEK]

The verify feature is buggy and Lightning UK has confirmed it.I personally don't use it,either the disc works or it doesn't.

https://forum.videohelp.com/topic339464.html

[Grain]

There's nothing buggy with the verify function of ImgBurn at all. If you have AnyDVD enabled, IT causes the verify issues. Turn off AnyDVD and verify works perfectly.

[JohnnyBob]

The verify feature is buggy and Lightning UK has confirmed it.I personally don't use it,either the disc works or it doesn't.

https://forum.videohelp.com/topic339464.html

I read that link, and my understanding is that Lightning UK did not confirm it. I believe he said that as far as ImgBurn is concerned, a verify error means there's an error on the disc. However he also said there are other possible causes for a verify failure such as interfering software and hardware/memory failures. So a verify failure means the disc might contain an error, and what is missing here is the probability that it contains an error. My Lone Ranger hunch is that probability on the order of 95%+, and I understand that several of you (who have given up verifying altogether) would disagree.

It might be possible to determine better whether it actually contains an error if the various burning softwares such as ImgBurn and Nero would allow multiple verify scans, but insofar as I've seen, they only do it once then it can't be repeated. Or, in theory if the data is on the hard drive, you should be able to insert the disc again and compare it with different/appropriate software. Is there any software that can do that?

[VegasBud]

JohnnyBob,

You may be interested in a study conducted by the NASA Planetary Data System available here, in which they used a DVD-CATS system at NIST for reference, and CD-DVD Speed. In respect to using CD-DVD Speed, while they "feel that the scans still present a good picture of the overall quality of the disc", they did note that "the CD-DVD Speed Disc Quality test does not check every sector on the disc, but only samples sectors." That doesn't mean CD-DVD Speed isn't useful, but it does make for less comprehensive testing than the bit for bit checking that ImgBurn's Verify function uses. It's an informative article if you like CD-DVD Speed, with the pros and the cons.

[VegasBud]

How accurate is ImgBurn's Verify function?

It's as accurate as your hardware/drivers are. There isn't anything on the software end to interfere with accuracy. You just read a block of data from the source material on your hard drive, read the same block of data from the burned disk, and compare the two.

If you want to manually check on ImgBurn, hit the F6 key to turn on debug mode. In the Verify section of the log it will list the two points (source and target) where the problem occurred and the data itself (so you can verify the mismatch with your own eyes).

[dontasciime]

The verify feature is buggy and Lightning UK has confirmed it.I personally don't use it,either the disc works or it doesn't

What an odd thing to say.

The disc either works or it does not. thats 50/50 I do not like those odds for burning, for winning the lottery and lots of things in life 50/50 odds are pretty good.

Not much good finding out 5 months later when you are relying on the data integrity for say a backup of your Xp Pro install disc to find that your getting errors all over the place because the cab data being extracted is not 100%.

Obviously you burn, if it says successful most of the work has been done, until you then verify to make certain the data matches 100% hence the function of verify

Buggy it is not or was it ever confirmed

[MOVIEGEEK]

Many people(including myself) have found it to give false readings.
My point is I am not going to throw away a disc because it's missing a few bits of data,if you want to throw away discs in search of nirvana then that's your business.

[mats.hogberg]

when you are relying on the data integrity for say a backup of your Xp Pro install disc to find that your getting errors all over the place

All you'd have to do at that point, is make a new backup, isn't it?

/Mats

[lordsmurf]

Nero, ImgBurn ... pretty much any "verify" features I've ever seen is not to be trusted. It reports bad discs as good, and good discs as bad. What a waste of time. Run a real test, if you want one (transfer rate, surface scan, etc).

[Seeker47]

I personally don't use it,either the disc works or it doesn't.

This is more in line with my own observations. Offhand, I think there were only one or two instances where the 'Verify Failed' DL backup was messed up in some detectable way.

Grain -- I have never used AnyDVD.
VegasBud -- thanks for the tip re Debug Mode. I will try that, the next time this question comes up. I was just guessing in regard to the layer break having some involvement. I think with this last incident, the first error showed up at 364xxx, which might have been about halfway.

What it all sort of reminded me of (perhaps spuriously) was making partition image backups. (The particular software used is probably irrelevant here.) What you should do there is boot off the program CD, and not touch the partition being backed up again until after the imaging and the Verify. If the OS accesses the partition in between and changes the Time / Date stamp of just one file, or updates one byte in the bootsector, the image won't be judged as being identical. There may be no significant functional difference, but with something as important as a boot partition, you wouldn't want to take that risk.