Help with CD Speed

[Blueshark]

After burning my Data CD's, I check the burn using Nero CD Speed. However, I am wondering how concerned I need to be with the results. Sometimes when using CD Quality Check, I will get one or two errors. Checking with Scandisc, sometimes I will get surface errors and othertimes not. The file check never finds any errors.

I am using Nero Burning ROM for creating CD's (latest version) with my Lite-On LTR48125W. I am using Mitsui Silver Media and I have run the test after burning at 40x and 24x.

TIA

[glock20rocks]

Welcome to the club

I've had very similar problems; the only discs I've found that I can burn at 48x with out any errors are Memorex (with SmartBurn disabled!).

The Fuji 40x and 48x discs produce errors, even when burned at 24x.

Very frustrating...

What speed are you burning your discs at?

[Blueshark]

I have recorded Mitsui Silver at 40x and 24x (with SmartBurn Enabled). I have also recorded unbranded Trusilver at 24x and 12x with similar results.

I was wondering if Nero Burning ROM-Verify and Nero CDSpeed-Scandisc- File Check don't find any problems if I should really be concerned.

TIA

[cfitz]

Keep in mind that the yellow errors are C2 level errors which are fully correctable by the drive as it reads the data. That is why you aren't seeing any errors when you run the verify and file check tests.

Also remember that despite CDs being digital storage media, the actual reading of the data is still, at its core, an analog process. The hardware must make a decision, based on continuously variable reflected power levels, whether a pit or a land is present for each bit that it reads. That decision is a statistical decision, and the actual result can vary from run to run. That is why sometimes you see a yellow error and sometimes you don't.

Next, remember that every disc you burn and read has errors on it, so you can't expect perfection. There is no such thing as an error-free burn. Even when the surface scan shows all green and cd quality shows zero errors, there are actually lower level errors that were corrected and never reported to the Nero utilities. Check some of Ian's most recent reviews. You will see he posts results from the WSES test suite that show a good number of C1 errors even when discs are free of C2 errors:



Finally, a disc that reads with some errors on one drive may read without any errors on another.

In summary, I wouldn't worry too much about one or two isolated yellow errors in CDSpeed tests, although I understand your desire to get a 100% green board. If you get many yellow errors or any red errors, verification errors or file check errors, that is when you need to worry.

cfitz

[glock20rocks]

I (almost) always get a red (unreadable) block on the very end of each disc, but I understand it's just a bug in CDSpeed (?)...hmm, I've never actually DONE a file scan; think I'll try that on the disc's with the red blocks...

[cfitz]

I (almost) always get a red (unreadable) block on the very end of each disc, but I understand it's just a bug in CDSpeed (?)...hmm, I've never actually DONE a file scan; think I'll try that on the disc's with the red blocks...

Yep, sounds like the famous "last sector unreadable" bug. Chances are the disc will pass the file scan with no problems. You might also want to explore the following programs for verifying disc integrity:

http://www.md5summer.org/
http://www.elpros.si/CDCheck/

cfitz

[Inertia]

cfitz,

Thanks for the excellent explanation of CDR recording and playback errors.

Re: the red unreadable block at the end of the CDR on the CD Speed ScanDisc test. This is caused by link blocks left when the recording is done in TAO (i.e., multisession) and is not a defect. This artifact does not appear if the recording is done in DAO. If it does,then it truly is an unreadable sector.

[dodecahedron]

Re: the red unreadable block at the end of the CDR on the CD Speed ScanDisc test. This is caused by link blocks left when the recording is done in TAO (i.e., multisession) and is not a defect. This artifact does not appear if the recording is done in DAO. If it does,then it truly is an unreadable sector.

Inertia, are you sure that there should be no red block when recording in DAO mode?
i seem to recall that i've burned CDs in DAO that had the last block red, and apart from that seemed completely error free!
so i'm not really sure.

You might also want to explore the following programs for verifying disc integrity:

http://www.md5summer.org/
http://www.elpros.si/CDCheck/

cfitz

hey, cfitz, you mention here (and elsewhere) the md5summer program.
as far as i can tell, this program is used for creating MD5 checksums, not for verifying disc integrity.
can it be used for verifying disc integrity too? how?

and by the way, i might add my own strong (very strong!) and wholehearted recommendation of CDCheck! it is an EXCELLENT program!

[Blueshark]

I want to thank everyone for their helpful advice. I think I am a little less paranoid now. But I suppose I still wonder what is the best way to determine when a burn is good or marginal. For example, a Data CD with 625 MB checks fine with Nero Buring ROM Verify (as described by cfitz). A CD Quality check shows 522 errors (%???) and only a few yellow spikes. A Scandisc file check shows no errors (again as described by cfitz). However, a Scandisc Surface Scan shows 0.23% damaged (yellow errors = c2?). I would interpret this as an acceptable burn. But I certainly don't want to go through all of that with every disc! So which is the best method? Is there some sort of threshold when you should toss the disc and redo the burn?

[Inertia]

Re: the red unreadable block at the end of the CDR on the CD Speed ScanDisc test. This is caused by link blocks left when the recording is done in TAO (i.e., multisession) and is not a defect. This artifact does not appear if the recording is done in DAO. If it does,then it truly is an unreadable sector.

Inertia, are you sure that there should be no red block when recording in DAO mode?
i seem to recall that i've burned CDs in DAO that had the last block red, and apart from that seemed completely error free!
so i'm not really sure.

Yes, I'm sure. If you get a red block at the end of a DAO burn it is truly an unreadable sector. This can happen as the extreme outside of a CDR is more subject to mechanical effects like vibration and (especially in CAV mode) records at the fastest speed available. When a CDR is marginally capable of operating at a recorder's fastest speed, a failure at the extreme outside of the burn in the final sectors is often the result.

The red blocks that appear at the end of the burn with burning methods other than DAO will typically disappear and move to the end of the next track as it is added. This can be demonstrated by adding sessions to a multsession disc and watching the red block move to the end as each new session is recorded. The TOC can't read the link blocks at the end of a session and interprets this as an unreadable sector.

This effect is reminiscent of the traditional practice of commercial CD mastering businesses to refuse recordings not made in DAO mode. Because of their link blocks, TAO recordings could be interpreted as full of errors by the reproduction mastering equipment.

Blueshark,

In my opinion, for noncritical home recording, the level of errors that you have described is acceptable. Ideally, there will be no damaged sectors showing, but a few isolated damaged sectors is not a major concern and will be fixed by error correction. If more than a few damaged blocks show up, lowering the burn speed will usually reduce the errors. If there are major spikes with thousands of errors in the quality check, the media may be bad. It's basically a judgement call.

Different media will produce different results, and after testing the capability of each, guidelines can be established. Instead of always trying to burn at the fastest speed, it makes more sense to lower the speed for each media to a level at which errors are minimal or unrecognized (green blocks, no spikes).

If recordings are made with a high percentage of damaged sectors, in addition to the undesirable effect of slow reading, the main hazard is that some sectors will eventually degrade and become unreadable.

[cfitz]

Inertia, are you sure that there should be no red block when recording in DAO mode?
i seem to recall that i've burned CDs in DAO that had the last block red, and apart from that seemed completely error free!

My experience has been that of Inertia's: burn in TAO = red final block, burn in DAO = green final block. However others have sworn to experiences like that described by dodecahedron: a disc burned in DAO shows a red final block, but in all other respects shows absolutely no errors (including bit-wise comparisons of the files). So, I am willing to call the CDSpeed behavior a bug. It is either an actual functional bug (assuming the reports by others are accurate), or it is, if you will allow me to coin a phrase, a "UI design bug" - too many average users are mistakenly lead to believe that something is actually wrong with their CD-Rs because of confusion over TAO and DAO.

hey, cfitz, you mention here (and elsewhere) the md5summer program.
as far as i can tell, this program is used for creating MD5 checksums, not for verifying disc integrity.
can it be used for verifying disc integrity too? how?

Yes it can, in essentially the same way that the CRC option in CDCheck allows verification.

The idea behind both of these methods is to calculate a set of unique signatures for each file that is to be burned in a CD compilation. These signatures (32-bit CRC-32 for CDCheck, 128-bit MD-5 hash for MD5summer) are compact representations of the bits that make up each file, and are designed to change dramatically if even a single bit in the original file changes. Thus, if any file is corrupted by a failing disc, a subsequent calculation of the signature will result in a different signature that does not match the original. This allows you to detect the corruption.

To make practical use of this, you use the program to calculate a signature for every file that is to be burned on the CD-R, and record those signatures in a file. Both CDCheck and MD5summer automate this capability. You then include this signature file in the compilation, and burn the complete CD-R. Your CD-R now contains the actual data files and the additional signature file that lists each data file's signature at the time of burning. At any later time you can re-calculate the signatures of the data files stored on the CD-R, and compare those recalculated signatures to the original signatures. Any difference means that a file has been corrupted. Again, both CDCheck and MD5summer provide automated methods for recalculating and comparing signatures.

One problem with this method in general, of course, is that by the time corruption has been detected, it may be too late to recover. However, it does give one assurance that all is well if the signatures do all match. To detect problems before they become uncorrectable, you need to use a program like CDSpeed’s disc scan or quality check that can detect correctable C2 errors before they become uncorrectable errors. If a disc’s C2 errors significantly increase over time, it is an indication that the disc is degrading and that those C2 errors may eventually become so numerous and severe that they transition into uncorrectable errors and thus, file corruption.

Why would one want to use MD5summer instead of CDCheck? The MD-5 hash is a 128-bit signature, four times as long as the 32-bit CRC-32 signature used by CDCheck. As such, it is exponentially more robust at detecting changes than CRC-32, similar to the way that longer encryption keys lead to exponentially more difficult to crack encryption. There is a very small but finite chance that a file could be corrupted in such a way that the CRC-32 code remains the same, and thus the corruption would go undetected. The chance of the same thing happening for an MD-5 hash is, for all practical purposes, zero.

Is the additional strength of the MD-5 hash a good reason to choose MD5summer over CDCheck? Probably not, at least not for the typical CDRLabs reader. For all but the most stringent requirements, the strength of CRC-32 should be more than sufficient. Also, calculating MD-5 hashes is computationally intensive, so MD5summer takes more time to calculate the signatures and verify the files. Finally, CDCheck has extra CD-R specific comparison and recovery features that MD5summer does not include. However, I do like to mention MD5summer as an alternative and/or adjunct for those who are truly paranoid.

cfitz

[Inertia]

My experience has been that of Inertia's: burn in TAO = red final block, burn in DAO = green final block. However others have sworn to experiences like that described by dodecahedron: a disc burned in DAO shows a red final block, but in all other respects shows absolutely no errors (including bit-wise comparisons of the files). So, I am willing to call the CDSpeed behavior a bug. It is either an actual functional bug (assuming the reports by others are accurate), or it is, if you will allow me to coin a phrase, a "UI design bug" - too many average users are mistakenly lead to believe that something is actually wrong with their CD-Rs because of confusion over TAO and DAO.

"UI design bug". I like it. It's the perfect excuse for a user error or misunderstanding, the CD burning equivalent of "The Devil Made Me Do It".