Why go through all the trouble to rip tracks from a CD using EAC? What are the disadvantages, if any, of using a program such as Nero to create an image of the CD on the hard drive? Wouldn't that create a file on the hard drive with identical content as on the CD? You could then mount that image with a virtual drive and rip the songs from there which should be identical in quality as the ones on the CD.
Am I making sense at all? I'm sure I must be missing something. There must a reason why EAC is the most popular method for ripping.
I was thinking about this after I read a post by someone who wanted to know if he burned MP3 files to a CD, would he have to use some "secure mode" ripping to copy the MP3s back to his hard drive. I know the response was that he could simply copy/paste them without worrying about quality but I forgot why.

EAC has its benefits as you can rip to a lossless format which will be bit-for-bit identical to the source audio CD yet take up less space and hold track ID information. EAC can also accurately rip and compare your rips to an online database. Programs like Nero may introduce errors in the image creating processes, EAC will let you know if any errors have occurred and if the rip was accurate.

I see your point but why go through all that trouble when you will never use the CD image again? Simply rip to lossless once and you will be set. The lossless files take up less space than the CD image and are compatible with many, many different programs.

In terms of secureness, space, and ease, it just makes sense to rip to a lossless format with a secure/accurate ripper such as EAC. The only downside to EAC that I see is that it can be hell on a CD drive if you rip a bunch of content. dbpoweramp has, from my experience, put less strain on optical drives yet it can be just as secure and accurate (although some argue that it is even more secure than EAC).

You could indeed mount the image as a virtual drive, but with full disc + cue sheet encoding, in a lossless codec, you can just play the individual tracks directly using a competent music player. You could then burn a CD identical to the original from the full disc + cue file.

-

I'm not so much worried about doing all the work in one step. I can do the encoding in other programs. I'm sorry I forgot to mention that I'm purely interested in the quality of the ripped wave files. Encoding, tagging, and such are not a concern in my question.
(I use EAC to rip and then I encode the wav files to FLAC)

You could start reading here to find out why.

I'm assuming your concept of an audio CD is that data is stored on it in a similar way to a hard drive.

But audio CDs have substantially less error detection/correction capability than hard drives or even data CDs (data CD formats were codified later). Why? The original goal was to deliver *uninterrupted* music, not necesarily bit-correct music, and still allow for space for storage of xx minutes of music. So the priority in the error-correction arena was to fix what read errors could be fixed with the parity in the core chipset and then give the playback hardware the best hints possible on how to reconstruct missing data with a worst case scenario of interpolation of audio data when it could not be reconstructed. Most of the time, we wouldn't notice these errors. When they got really bad (beyond clicks), the playback device would have to take control and ask the core chips to seek (sometimes repeatedly) causes jumps in the audio.

Another way to look at it is basically as a streaming protocol fixed on optical media instead of over a network. No "buffering..." messages allowed either, as the original CD players had no RAM type memory to buffer audio data in.

Data CDs and later optical technologies prioritized data integrity, and the more complex error correction/detection approaches are testament to that.

-brendan

Very helpful. Is that what this sentence from the EAC site is talking about?

I am sorry but I fail to see the logic in doing this. Why not just rip to lossless to begin with? Why rip to WAV then encode to FLAC when EAC can rip directly to FLAC? That seems like a unnecessary step in this whole formula. Isn't it easier to follow CD->EAC->FLAC than CD->Image file->Virtual Drive->EAC->WAV->FLAC?

I'm aware that

CD->Image file->Virtual Drive->EAC->WAV->FLAC

is much longer but I was curious to know if that would give me a better backup than EAC.

Oh, well the answer is no. You get the same (or probably better due to EAC's CD ripping techniques) by ripping directly with EAC to FLAC.

Yes, except that the author isn't being conservative enough about the possible reasons you may receive erroneous results. Bad CD-ROM (read: optical) drives are just the tip of the iceberg when it comes to sources of erroneous ripping results.

Again, here's another (bad?) analogy.

Analog TV may be low quality, but you can pretty well get an idea what is going on even when the signal fades significantly - video quality loss is gradual. Unlike analog TV, digital HDTV is high quality, but there's a sharp threshold in reception between crystal clear (>= xx% of original signal) and no signal (<xx% of original signal). Degrade the data stream beyond that point and you get nothing. However, one reason it works at >=xx% (that is, why it works at all) is the parity-type redundancy built into the signal stream.

Now imagine a theoretical digital video standard that was engineered to able to reconstruct one of every 2 pixels or one of every 4 pixels as the receiveable signal moved from (say) xx% to xx/2% to xx/4% at which point the signal is lost altogether. This would be great for certain kinds of watching (news, some sports, etc.) and annoying for other kinds of watching (specials on the grandeur of the earth, romantic films) depending on your personal tastes.

I sort of look at the CD Redbook standard as trying to fit the above (non-existant) middle ground, since they weren't all the convinced they could do error detection/correction well enough on this first try at a consumer digital format with the hardware they had at the time (early 80s). The redbook standard sort of meets this criteria: most people don't notice or won't mind little dropouts here and there (though the ear is actually much more sensitive than the eye to distortion). A threshold was determined where a certain level of interpolation is likely to go unnoticed. And that was the target signal the engineers sought to create: something good enough for the average listener in the average situation.

And so we're still stuck with it!

EAC and dbpoweramp have all sorts of tricks up their respective sleeves to reconstruct as close to the original signal as possible that Nero can't touch.



It is assuredly guaranteed to give you a worse backup, on average. The CD->Image file step is a physical ripping step, and the Nero software does not specialize in this area.

Also, though not important for this discussion, an "image" of an audio disc is a misnomer: it almost assuredly throws out all of the subchannel/subcode data, which can contains cd-text information, index marks, etc.

-brendan

Thanks for all the explanations! Very helpful. I've been using EAC the entire time since so many think of it highly.



In Nero, there is an option for creating an image

"Read all subchannel data"

Does that help at all?

Ah, I did not know that Nero had that option. I suspect, however, that the images made this way must be nero images, not ISOs, correct? Is there a virtual drive program that will mount Nero images made with this option?

Still, if you're mostly paranoid about the correctness of the audio data pulled from the CDs (esp. from damaged media), I don't think that Nero's ripping process is nearly as rigorous as EAC or dbpoweramp.

-brendan

"Read all subchannel data" will not help secure ripping (even if they were reading CU errors, why not use C2?).

Edit: it might help for drives with no c2 pointers, within the subchannels is a CRC of the sub-channel data (such as MSF), if this highlighed as corrupted then it is likely the audio data is corrupted also.

Edit: Edit: the subchannel could return a CRC error, whilst the audio which had an error, auto-corrected.