Thread: Burst Test & Copy Vs Secure Copy - the definitive answer

I have been using Test & Copy in Burst mode, using the CRCs as the sole indicator for the rip's accuracy, for a while now. When there's a CRC mismatch I re-rip the disc using Copy in Secure mode. This is especially convenient when there's a big pile of CD's or CDR's to rip.

Based on what I have read in this forum I have adopted the stance that Test & Copy on Burst mode is EXACTLY as secure as Copy in Secure mode. Am I right here? If so, can someone explain how each EAC mode deals with accurate stream, C2 error correction and caching, and how this works out in ripped WAV's of equal quality?

Many thanks.

That is exactly the way I rip my CDs (mainly as my drives all caches, making extraction much slower...)

cu, Andre

what are CRC's?

Originally Posted by ross

what are CRC's?

CRC = Cyclic Redundancy Check = Checksum

CRC is used to compare data and assure data integrity.

In secure mode, EAC calculates a 32-Bit CRC for each read stroke (26 sectors) and then re-reads and compares CRC values.

In test & copy mode (no matter what basic read mode is used), CRC's will be calculated for a test run and the copy run ... EAC will show the CRC's in it's main window, alongside with an 'OK' or a '#' ... the latter indicating that the CRC's from test & copy did not match.

So, this would be the way to go if a track fails to rip without errors in secure mode? That is, switch to burst mode and check 'use CRC check' in compression settings.

I just tried this and it tested and copied OK despite not working in 'secure mode'.

I'm still not entirely sure what the difference is between fast and burst mode, and I'm looking for the next best way to rip from a CD that gives errors in secure mode.

Well, what more can one wish for than approval by the Grand Master of EAC? Thanks for the response Andre, and also for creating this elegant software.

"Floepie": I think it works the other way around: first use Test & Copy in Burst Mode (TCB) and re-rip in secure mode (TCS) in case of non-matching CRCs. This does not guarantee matching CRCs (and thereby a "perfect" rip) either, but at least you know EAC has tried everything it could do to correct any errors.

I had an interesting EAC experience yesterday that I'd like to share. I was ripping a brand new CD that was still sealed when I bought it. First thing I did after removing the plastic wrapper was rip the CD using EAC, i.e. the CD had NEVER been played when I started ripping (now that's what I call "pristine"). TCB mode reported CRCs mismatches on several tracks, so I re-ripped using TCS mode. This took about 4 hours (!), and although EAC did not report any errors, some CRCs still did not match. This is where the Track quality comes in (it was 99,9% on tracks with non-matching CRCs). In case of an error EAC guesses the most probable audio sample and writes it to disk. "Most probable" means the sample is not necessarily constant across the two (i.e., Test and Copy) reads.

OK, thanks for reply. Where do you see the CRC's in the EAC main window? I see nothing different if I check the 'use CRC check'. I've tried this with a few CD's now that will not pass the 'secure mode'. So, I re-rip w/ TCB, and everything seems OK. I see no evidence of CRC's being checked anywhere. ???

Maximize EAC's main window and you will see the "Read CRC" and "Test CRC" column headers in the upper right corner.

Thanks for your replies. Unfortunately, my problem tracks did not pass that either, so I guess I'll just have to make do with the errors, correct?

I'm afraid so. My understanding is that read errors can either be due to physical damage (scratched or dirty discs) or mastering/pressing/burning errors. Perhaps EAC receives a "can't read" flag from the drive in the first case and something like "999" in the second. In my example, where I had a pristine disc, the error must be a mastering issue. BTW, this disc was one in a batch of four pristine discs, all from the same pressing plant; only this one could not be ripped properly.

Maybe the CD you are trying to copy has some protection scheme on it ? Sounds like CDS200 to me ...

Maybe, but how do I know? I retrieved the Native TOC and, as said in my previous post, I ripped four pristine discs (same label, same manufacturer) and only one made EAC cough.

Then you could allow EAC to slow down during the read process or lower the read speed itself (both functions can be accessed via the 'drive options' menu)

JeanLuc, thanks for the tip! I re-ripped the problem disc in TCS mode with the "reduce speed" box ticked and I got matching CRCs.

I came across another interesting difference between TCB and TCS rips. My drive (a Lite-On LTR48246S) can't read into lead-out so ripping in TCS mode with this option ticked typically results in sync errors on the last track of a disc. Hence the "drive can read into LI/LO" option in the drive settings section is always un-ticked.

I was curious to see what happens in TCB mode when the "drive can read into LI/LO" option is ticked. I was expecting non-matching CRCs for the last track, but surprisingly the CRCs *did* match. This suggests that my drive always reports the same flag/signal/data when it is forced to read into the lead-out. I would say that these drive reports are errors, but apparently EAC does not treat them as such.