Which Lossless Audio Codec, and Why?

deadsquid puts forth a worthy follow up question to last week's query on audio codecs: "I'm about to re-rip my entire CD collection for the fourth time. I don't want to do it again, so have decided to invest in a small(ish) array and use a lossless codec to create a reference set of my music. From the reference, I plan on transcoding to a variety of bitrates (depending on where the final product will end up) and whichever format of the week suits the device(s) the transcoded content will ultimately sit on. I don't particularly care about encoding time, but would like something that transcodes nicely to MP3, WMA, OGG, and other formats in a reasonable length of time. I would like to ensure that track metadata is maintained in the reference, and is easily transferable when transcoded. I also want something that's not proprietary to an individual's or small group's whims. I'm thinking FLAC, but was wondering if other people had better experiences with other codecs. If you were to use a lossless encoding format, which would you use, and why?"

Comments

Again?

[BrookHarty]

I'm about to re-rip my entire CD collection for the fourth time.

Thought I saw this story already this week, wierd.. But one question, why for the 4th time? I've been ripping to MP3 since my Amiga days. ;)

And my Car stereo plays MP3s, I dont see me going to a different codec for awhile. A long while.

Re:Again?

[orangesquid]

Actually, if you get into signal processing and transmission line theory, you will see that cables make a difference, for the same reasons that you wouldn't use CAT3 wiring for gigabit networking or indoor extension cords outdoors in a thunderstorm. Of course, paying $50-$200 for a pair of headphones to use in a professional recording studio isn't unreasonable. Paying $2,000 for a pair of headphones to wear while jogging, on the other hand, is quite unreasonable. Sanity has a sliding scale.

But, yeah, there is a point at which you can't justify the extra cost, and you're just throwing away your money. It's like Joe Sixpack buying vintage wine when he can't tell the difference between it and the cheap stuff.

But, back on topic:

My experience with flac is that it is VERY quick to encode and decode. Compression isn't an order of magnitude like MP3, of course, but you might be able to shrink files by a significant quantity (not quite a clearance rack or going-out-of-business sale, but definitely like black Friday). Since it's so damn fast, it's trivial to re-encode flac to other formats.

I just started doing this again myself...

[Malor]

I invested in a good-sized array (5 250g drives in a RAID-5), and I'm in the middle of reripping my entire collection.

The format I am using is BIN/CUE... I'm trying to take a perfect copy of the actual CD, so that I can recreate it when I wish. My original goal was to copy every bit on the CD.

From what I have found, however, none of the CD image utilities out there make a bit-perfect copy of audio CDs. I have tried Alchohol, Blindwrite, and something else, and NONE of them result in bit-perfect rips with EAC from the image afterward.

The only way I found I could get bit-perfect copies of the music was to use EAC with its AccurateRip database. EAC won't copy anything but sound, so I'm losing the 'extra' content that comes on some CDs. However, what I really care about is the music, so if I have a bit-perfect copy of that, I'm happy.

There are two major ways to make BIN/CUES... separate wav files, or a single wav file. Both require a CUE sheet to reassemble into a CD image. I chose the single-wav format, because this makes tagging when I actually extract the data into whatever I want to use easier. The separate wav file approach would allow you to more easily access the individual files with a script. I suspect this may be a technically superior approach. But I'm using single WAVs anyway, even though it takes more work.

My actual rip process:

Buy a really good CD drive to rip with. I'm using a Plextor Premium.
Install CYGWIN or find some other way to script a quick 'diff'. (I'll put my tiny script at the end).
Install Daemon Tools to mount images.
Run EAC (I have installed the AccurateRip database as well)
Set EAC to rip to Track%N.wav when extracting.
Rip CD to individual WAVS on the C drive, ensure that everything is either bit perfect or the CD is unknown. AccurateRip only understands individual tracks, so this is the only way I've found to verify that my original CD is perfect.
Have EAC create a separate-files CUE sheet 'with leftout gaps'.
Edit CUE sheet to remove anything but INDEX 00 lines. Remove all PREGAP and INDEX 01 lines. (This was the only way I could get bit-perfect second-generation rips.)
Mount CD image. Rip again to a single-file BIN/CUE image. (this is very fast, 30 seconds to 1 minute on my system) (this will be what you keep)
Mount new image. Rip AGAIN to individual files in a separate directory. (again very fast)
Run a 'diff' between the first generation rips and the final generation. If they're exact copies, then you have a bit-perfect BIN/CUE.
Copy BIN/CUE to server.
Delete everything and start on the next CD.

It would be perfectly possible to skip the second and third-generation rips, since you know you got a good copy the first time, but I prefer the single-file approach... I don't want to work with the wav files directly because I don't have tag info for them in that format. And it doesn't take very long to create the single-file image, so I go ahead and do it that way.

Then the next step is to mount the images and rip with whatever software you want to use. I'm using iTunes. I just mount the images with Daemon Tools off the server and rip with iTunes, which always seems to recognize the CDs. I also found that if I bump iTunes' priority down to Below Normal, my rips go ENORMOUSLY faster... they jump from about 8x (dismal) to about 45x. I assume Daemon Tools isn't running at very high priority and iTunes interferes with it... by bumping iTunes down, it doesn't interfere as much and rips faster.

Oh, iTunes also didn't like the 'Generic' label that Daemon Tools uses by default, it seems to be coded to explicitly not recognize a drive with that label. I changed mine to be a 'Pioneer' 'DVR-1X' during the Daemon Tools install, and then iTunes used it fine.

Once you're done ripping, then script something on your server to compress your WAVs with whatever compressor you want. You won't be able to mount them without uncompressing them again, but you'll save a lot

Re:I just started doing this again myself...

[Malor]

Truly accurate CD ripping is fairly hard, at least when the CD isn't factory fresh and totally perfect. A simple dd will indeed copy the image, but it's really designed for data, not audio. If your CD has any scratches, it is highly, highly likely that your copy will be imperfect. Audio CDs, unlike data discs, don't have much in the way of redundancy, and it's easy for errors to be missed by the OS.

EAC, on a good drive, will see problems that dd just doesn't catch. It knows how to talk to the better drives, like the Plextors, that will report C2 error information. When it finds a problem, it will retry numerous times at different speeds, trying like mad to get a solid copy. It's surprising just how good a job it does, even on rather questionable CDs. dd offers none of this. It's not an audio ripper, it's just a data copier.

EAC, combined with the AccurateRip database, is a way to be CERTAIN you got a perfect rip, or at least the exact same results that other people have gotten. You simply have no way to know if you extracted properly with dd.

And don't think that just because your CDs are unscratched that they will extract perfectly. I have a couple of CDs that report errors even though their surfaces are apparently perfect. My copy of the old Lost Boys soundtrack is particularly bad. I've run it through several polishing sessions, and there are no visible scratches of any kind, but EAC has a heck of a time with it. I assume that it must be a poor-quality pressing. A couple of tracks on the disk are damaged past EAC's ability to compensate, and I need to find new copies. Had I been using dd, I wouldn't have known.

Remember, I'm trying to archive here. I'm trying to get it PERFECT, so that I never, ever have to do it again. If you just want a casual rip to toss in your iPod, that's a rather different goal.

Re:Consider longevity of the codec

[man_ls]

Agreed...back in the day I had some kind of program that wouldn't export to MP3 unless you paid extra for it.

So, I exported as WAVs, with MP3 as the compression scheme...then renamed to .MP3, it worked fine.