I've been ripping my CD collection with iTunes on my laptop's drive. Is there any advantage (in the quality of the resulting AAC files) in using the CD drive in my main computer? Or does using "error correction when reading Audio CDs" make drive differences moot?

Drive should not affect quality when using a secure ripper. I could with itunes though I doubt it.
But you should use a secure ripper as EAC and not itunes to rip.

Only EAC and Plextools are valid ripping programs. If they work well, you can really be sure that the drive doesn't affect the quality in any way. The resulting files will then be bit-identical ("no measurable difference"). In any case, if you're using AAC, ripping quality doesn't matter that much...

Except for copy protected CD's of course... That's another story

What do you mean by this? Do you have something against AAC as a format?

In any case, I fail to see what does AAC (or any lossy) have to do with proper extraction. In my understanding secure extraction simply deals better with scratches or false reads. If any of those occur there'll be an audible glitch regardless the codec used.

A lot of folks around here will not agree with this, but the drive makes a lot of difference. From my experience over the years with several different drives I found that EAC tended to make up for the deficiencies in older drives.

Before I upgraded to a Lite-On 811s I found that certain problem tracks that older drives would rip leaving a loud click in the output with nearly any ripping software would result in a nearly inaudible click with EAC. With the Lite-On I found that there was no audible click at all when using a variety of burst mode rippers. These included foobar2000, dbPoweramp, discjuggler and EAC in the burst mode. When EAC was used in the secure mode it could not complete any problem track within a reasonable amount of time. Did I mention that Lite-On drives cache audio? I only found one ripper that did not do a good job with my drive. It was an early version of Nero 6. I have not tried the more recent versions.

As far as I am concerned the secure mode of EAC is next to useless with drives that cache audio. Furthermore these drives do an excellent job with burst mode rippers that are much faster and easier on the drives as well.

It continues to amaze me that in a community where performance based on actual listening tests is so highly prized that a nearly everyone stays on the EAC secure mode bandwagon in some hope of a bit perfect rip. In my experience these differences were 10 out of 10 easy to spot. Either there was a click (EAC secure mode) or there was not (many burst mode rippers).

Did someone above mention copy protected CD's? They are sickening, but expect to see more of them. Then hardware really makes a difference.

Right, thats why you use Burst Mode test and copy with drives that cache audio. If the CRCs match after the rip you can be as sure as you could with Secure Mode that the rip is perfect. If CRCs on a track don't match you could try Secure Mode, but if that fails (copy finished as opposed to copy ok) I thought it was well known that a Burst mode rip is usually better then a failed secure mode rip.Listening tests are the only way to do things in the inperfect world of lossy compression but CD ripping is another matter all together. There is no need to test if EAC Secure Mode says that the copy is OK or EAC Burst Mode test and copy returns identical CRCs.Thats right, in the world of CDs that are damaged beyond the hope of achieving a perfect rip or on copy protected CDs the drive can matter. I don't think that the original poster was thinking of these two fairly rare (at least for now) occurances but for the sake of precision I guess that its good to point things like this out. Oh and of course the drive always matters in terms of speed .

edit: clarification

Yes, I did!

After many rips (some of the CD's looked like they had been stepped on) I simply have not been getting any audible clicks or pops that are induced by the ripping process.

If you test and copy and the CRC's do not match, the best you can do is listen to the track to see how it came out. Then try again and hope for an improvement if the first one was no good. Odds are the CRC's for some tracks will never match. I even tried using plextools for its error reporting. Problem tracks with thousands of errors played back without clicks or pops. You could simply refuse to rip the track if the CRC's do not match. But, that is like throwing the baby out with the bath water.

The bottom line is it takes about three times as long to rip with EAC test and copy as it does with foobar2000 or dbPoweramp. Of course secure mode can take ten or 20 times longer. I have found that with fast ripping I can make "disposable" lossless tracks using Monkey's or flac. This process takes 2 minutes for a typical album. That way I can have a few things to listen to on my PC without taking up permanent space on my already packed hard drive and without needing to archive to DVD and organize the stuff find it and then copy it back to my drive.

OK, test and copy does beat secure mode with drives that cache. But next time your CRC's do not match try that problem track with foobar2000 or dbPoweramp just to see what happens. You might be surprised.

It was rather a joke...
I mean that if you're going to encode lossily, a few interpolated samples (that's inaudible) don't matter. The lossy codec causes all samples to be inaudibly (?) wrong.
Anyway, I can't compete in the discussion about lossy codecs since I'm no longer into lossy at all.


Agreed. "No audible difference" is nothing one can handle, although ABX makes it a bit more handy. But maybe if you can't ABX, someone, somewhere, somewhen with some equipment might be able to ABX it. Then there is an "audible difference", though. "Bit identical=no measurable difference" is much more easy and unambiguous.

Of course eagleray is right once you've given up the attempt to retrieve a bit-perfect copy. I don't think this is the original poster's intention.

I can't comprehend why speed is so important...
During my ripping processes (default is secure + test&copy) I even manually decrease the speed to 4x because of poorly balanced audio CDs. If a scratch is encountered, the rip may last several hours. So what? I go eating, have a shower, go to bed...

Enabling error correct will not always help you,whether you use itunes, EAC, or whatever.

Even moderate scratches will return errors with EAC and can extend the ripping time to hours.You still won't get a perfect rip but at least the prog will tell you that.

Better to resurface the cd in this scenario.......

Heh. I actually agree with this even though it's a joke. If one rips to compressed files, does it matter if they have a bit identical rip? NO.

It does if there is a big pop in the middle of one of the tracks. Its true that this is not likely to happen but IMO its easier to rip securely then it is to listen carefully to every track to be sure that there are no audible problems.

[quote=music_man_mpc,Dec 20 2004, 11:09 PM]
[quote=eagleray,Dec 20 2004, 08:29 PM]I don't think that the original poster was thinking of these two fairly rare (at least for now) occurances but for the sake of precision I guess that its good to point things like this out. Oh and of course the drive always matters in terms of speed .
[/quote]

Actually, I was thinking only of the fidelity of the ripped AAC tracks and the introduction of distortion (or, hopefully, the lack thereof) by the drive in my laptop.

My comparison is not compressed to lossless, it is the rip of the drive in my laptop compared to a rip from a "better" drive in my upstairs - and not nearly as handy - computer.

A flawless EAC-rip won't create any distortions for sure. (I assume you're talking about digital clipping and/or quantization distortion ?)


It seems to me there's a problem regarding your personal priorities...
This 'pop' case is very rare; in general the first thing is to care for lossless compression. And the next one is a 'bit-perfect' rip. Lossy compression is the more important problem compared to faulty ripping.