I've read through so many threads that debate the merits of the various ripping modes in EAC. However, now that I've been tearing through my CD collection and ripping, I realize that I just don't have the time to rip everything in secure mode, without caching and no C2. Doing so usually results in speeds of 0.3 and getting one disk ripped a night. With about 600 - 700 CDs, this could take some time.

Like I said, I've read many topics on this, but have yet to find a definitive answer.

Anyway, my question is: Is burst mode with test & copy a "quality" way to rip? I make sure that CRCs do match. However, will I still get the quality that I hear on the disk?

It seems to me that, if a test CRC matches a copy CRC, then the test rip matches the copy rip, but it doesn't necessarily mean that the copy matches the quality of the music on the CD.

If secure mode means I won't have unneccesary noise in my final result, then I'll deal with it. But, if the same noise-free rip can be achieved with burst test & copy, then I save a ton of time and headaches.

thanks,
-horror

As long as you have identical crc's secure copy isn't really necessary in my opinion. You would have to check the log files each time though.

A ripping speed of 0,3 is really slow by the way. You don't have another cdrom player around? It could make a whole lot of a difference.

Unfortunately, I don't. I'm even using my work laptop because my home computer is in bad need of replacement (EAC wouldn't even recognize my drives).

Actually, you don't even need to open the log file to check the crc's. After clicking ok out of the extraction window, look at the crc column in the layout and make sure it says "ok" instead of "#". But you should always keep the log anyway for future reference.

I use T&C burst, I've yet to have a rip with matching CRCs that sounds bad. It has said possible timing errors though, but when I reripped those tracks in secure mode, the CRC was the same, and it still sounded fine...

Thanks for the feedback. Cool to hear other (real users') experience with EAC.

I've since started ripping in Burst, Test & Copy. The results sound great. If there were a difference, then I don't hear it. The best part is that the conversion of my CD collection is happening much, much faster.

Like Firon said, if I get any errors or unmatching CRCs, then I just re-rip in secure mode.

Thanks again...

The typical ripping error causes a click or a bleep in the sound - very obvious when you hear it. So you should be fine

Just one more reply... horrorbiz, your reasoning is correct. T&C in burst mode is as good as T&C in secure mode if all the CRCs match. When I used to use EAC, I would do a T&C in burst mode and would then do a T&C in secure mode for the tracks with unmatching CRCs. (T&C in secure mode might be too much... especially if your drive does 0.3x!).

Just make sure the cache setting and "can overread lead-in/lead-out" are correctly configured.

p.s.: are you ripping to a lossy codec or to a lossless codec? If you have the space available, consider a lossless encoder. You will want to shoot yourself if after a couple of months you regret the lossy codec configuration you choosed. You won't be able to go back... you will have to re-rip your whole collection...

As others have said, T&C Burst is fine so long as your CRCs all show OK.

For those that show # I found it worth just doing a Test only on the track(s). For some reason nearly every single one would then OK the CRC. Maybe it's just my drive, but it saved me a lot of time when I realised. The very occasional track that still gave # for the CRC I would then rip secure. For troublesome tracks that still wouldn't rip cleanly I found it worth trying Burst mode again, but with Error recovery (f9 - Extraction) at High.

If you still can't get a CRC match then listen to the time samples indicated for the errors - you might be happy with what they sound like anyway.

Out of around 300 CDs I only had a couple that I couldn't get an acceptable rip from - every track full of skips and hi volume squawks (they were undamaged on both sides, so I don't know why). I had a handful of individual tracks that wouldn't give a CRC OK but still sounded fine. Just one of them had an audible imperfection and that was a drop-out a fraction of a second long, which is not going to hurt my ears or speakers, so nothing to worry about - to me.

I'm not clear from your post if you have C2 (f10 - Extraction Method) selected or deselected. EAC thought I should have it selected, but I got 0.1x speeds for secure. With C2 deselected I got 4-12x depending on CD condition. As I understand it, deselecting C2 even if your drive does support it, does not stop EAC getting a secure rip.

Actually, to be REALLY sure check "Accurate Stream", check "Caches audio" and uncheck C2.

Of course, you check "Accurate Stream" if it is supported by your drive.

You uncheck "Caches audio" ONLY if you know for sure your drive does not cache audio.

You uncheck C2 if your drive does not support it OR if your drives supports it but you don't trust the implementation of it on your drive.

For what it's worth, I decided to trust the implementation of C2 on my Plextor 708UF (a 708A really) and use Plextools. Couldn't be happier....

Actually it's right the contrary : selecting C2 when your drive supports it will not guarantee EAC to give a good rip

Radetzky: Thanks for the heads up. After doing a little research, I decided to rip to FLAC, so from what I've read, I understand that this should be sufficient to archive my collection. Also, it leaves my options open in the future to convert back to .wav and re-burn with no loss of quality (in the event that the original disk gets ruined).

Finally, I am assuming that, when I do need to rip in secure mode, it is ok for me to leave the caching option UNchecked. EAC detected that my drive does NOT cache audio data and I figure I can trust it because otherwise, I would always get a track quality of 100% (which I don't) and never have re-reads occur

Absolutely.

To summarise: If the drive supports it, selecting C2 should speed up ripping, but has been known to actually worsen speed. In which case it is safe to deselect C2 - it is not essential for a secure rip.

You can trust EAC's detection of audio caching, however, checking that a drive caches audio data should never prevent EAC from detecting errors that it can detect with the setting unchecked.

Anyhow, burst with matching T&C CRCs and no reported suspicious positions is every bit as reliable as a rip in secure mode.

Why not use AccurateRip? If it says a rip is accurate from a copy (burst or secure) you needn't bother with a test CRC.

Hmmm... are you sure? I stopped counting the times I read EAC sucks big time at detecting the cache capability of a drive.

Yes, I'm sure.

EDIT: Let me guess, the complaints were from people with drives that Feurio! said cached 37kB?

Can't tell. I just used my memory. I have no references. So because I'm an ass, I challenge what you say. Maybe after my cup of coffee I'll try to find a couple of references.

While you're at it, google what the creator of EAC has to say about it.

That's my observation as well ... a good indication for a caching drive (with EAC reporting that the drive doesn't cache) are repeated sync errors (errors from re-synching because EAC makes the drive perform a read overlap in secure mode as well) without reported read errors (which only emerge from comparing data chunks).

That's how I figured that -usefua doesn't work in my system environment.

Crap. After reading this again in JeanLuc's response, I realized that I misunderstood this earlier.

It is entirely possible to have a track quality of less than 100% for drives that cache audio data with the setting unchecked. I have three drives that cache audio data and all of them will attempt re-reads even with the cache setting unchecked. This isn't to say that the re-reads will result in success.

Due to my experiments with EAC, the re-reads in that case should be carried out very fast ... this is another indication of cache usage.

Yes, my experience has shown the same thing.

Have you ever encountered a Read Error in this circumstance or only Sync Errors?

I second that. AccurateRip is great, we should also advertise it more in our guides... i'll see what i can do.