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?

[gl4ss]

too much time on his hands. or maybe the music will just sound better then.

in answer to the question though, flac is perfectly usable for that and will remain free and there will be tools that understand it.

Re:Again?

[OmniVector]

i know.. seriously people. mp3 is going to be around for a very long long time. why are you even bothering with any other format? every single device plays mp3s (except for sony's piece of shit first try at a digital music player). every OS plays mp3s. they're more than good enough for all but the most anal retentive of audiophiles. if you're really overly concerned about quality even in that case, just use VBR mp3s.

Re:Again?

[mellon]

You can't edit mp3s. Well, you can, but the results aren't good. You have to decompress the mp3, do your editing, and recompress, and chances are that you're going to get artifacts when you do this. So if you ever intend to use an audio file for any kind of editing, you really want it stored losslessly.

At Diamond Mountain University, we typically record all our classes, at 16bit 44khz mono, which consumes a substantial amount of disk space. When people record directly to MP3 it's a huge hassle because I can't take the audio and do dynamic range compression on it without creating artifacts, which means that you can't listen to it on your car stereo unless you have a luxo-mobile with really good sound baffling.

Right now I store all this stuff as AIFF files, but the idea of converting them to FLAC files is definitely attractive.

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.

Definitely FLAC

[Punboy]

I would definitely go with FLAC. No patent/IP worries, no licensing... its opensource... and it transcodes very nicely. I use it personally for my entire collection except what I switch over to my iPod, which is when I transcode it to 192Kbps AAC. Don't use Apple's Lossless, it has licensing issues and Linux decoders are buggy at best. Don't use RAW or WAV cause um... they're too big.

The best sound format:

[Randolpho]

.MIDI 'nuff said.

*ducks*

Re:The best sound format:

[zoeblade]

MIDI

Saying that MIDI sounds bad is like saying that ASCII has a bad font.

My full rant's on E2 if you'd like more detail on the matter.

comparisons of lossless compression

[belmolis]

I made some comparisons of lossless compression techniques a while back. This web page contains the results of my own tests (for speech data) and links to the tests I found (for music). I use FLAC.

Stay Tuned for Next Week's "Ask Slashdot"

[Anonymous Coward]

excerpt:
"I'm ripping my entire audio collection to lossless audio files and I need a cheap large-volume storage solution...."

Consider longevity of the codec

[rubinson]

Almost certainly FLAC will be what most people recommend. And it very well may be the correct choice for your situation. But I'd also take into account longevity of the codec. The fact that FLAC is open source, patent-less, etc is only a buffer against obsolescence, not a guarantee. WAV's, for example, have been around forever and are so entrenched that you can be certain that support for them isn't going anywhere. FLAC, on the other hand, has only been around for about 4 or 5 years.

Re:Consider longevity of the codec

[belmolis]

the reason WAV has been around for so long is that it's just doing a direct read of the bits on the audio CD, and dumping them to a file.

Not exactly. WAV is a FILE format, not an audio representation format. The audio data can be in any of dozens of formats, many of them involving lossy compression. One of the registered audio data formats (with ID 1) is straight PCM data, that is, uncompressed audio in the usual format. WAV files often contain straight PCM data, but they don't have to. (I've got some lecture notes on audio data and file formats here.)

We Need a Listening Test

[Doug Dante]

Sorry, but I'm an avid audiophile, and just because all lossless audio codecs generate digital output streams identical to their digital input streams does not mean that they sound the same! We must verify that those bits still sound the same via our one way gold plated speaker cables!

General slash response...

[sethadam1]

Let me sum up this entire thread so far and everything that will eventually be added for you:

FLAC blah blah blah. Blah blah Monkey's Audio. Blah blah FLAC blah. Blah blah SHN! Blah. WAV. Blah blah OptimFROG blah blah blah. Blah blah. WMA. WMA?! Blah! Monkey's Audio blah. Blah blah FLAC.

There you go: FLAC.

Aye

[numbski]

But I have to say this:

The audiophile with the biggest flamethrower is going to win out on this article. ;)

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:Flac for sure

[booch]

uh...why not create wave files and then compress the hell out of it with a separate data compression program

That's pretty much what FLAC is -- it's a specialized data compression program. To a "normal" data compression program (ZIP, gzip, etc.), audio data looks pretty random, so it wouldn't do a very good job. The important lesson here: knowing more about your data allows you to compress it better.

Re:What you mean

[DA-MAN]

What the hell do you mean CODEC and LOSSLESS?

You guys make everything way too complex.

There are two methods for compressing data:

1) Lossless compression: Think zip/rar/sit/tar.gz etc. These output the source file bit for bit when decompressed.

2) Lossy compression: Think JPEG/MPEG/MP3 etc. These output with a lot of data stripped off, the best lossy compression attempts to remove as much as possible without affecting quality too much.

Just because something is compressed doesn't mean anything is lost.