Linux CD Ripping Performance: Surprising Results

Next week, I'm building a Linux-based media PC. I've been doing some research and planning. The first goal is to setup a digital music library. I started my research at the beginning, with CD ripping. My initial performance results were so bad, it called the whole project into question—or, at least, the decision to use Linux.

Here is a message I posted to the Austin Linux User's Group mailing list.

I'm getting ready to setup a media system, and I'm distressed at the thoroughly horrible CD ripping performance I'm seeing.

My test system is a Dell Dimension P4 2.8GHz with 512MB memory and Phillips DVD8631 (40x speed).

When ripping under Linux (Ubuntu 5.04), it takes about 25 minutes to RIP a CD. I've tried both Sound Juicer (reports about 4x performance ripping to FLAC) and cdda2wav (rip to WAV).

When I reboot the system to Windows, Apple iTunes rips the disc in about 4 minutes (reports about 30x performance).

It turns out that although ripping performance may be slow in the default Linux configuration, there are adjustments you can make such that Linux can actually rip faster than Windows.

There are two significant issues that lower Linux ripping speed. First, for stability reasons, most Linux distributions do not enable DMA for the CD drive. If your system can handle it (I think most modern systems can), then you should enable it with the hdparm command. To do so, run (as root):

# hdparm -d1 /dev/cdrom

On Debian systems, you can make this setting permanent by editing the /etc/hdparm.conf file.

The second issue is that most Linux CD ripping tools enable error checking (sometimes called "paranoia") by default, while most Windows tools do not. If you disable error checking, you will see a significant improvement in ripping performance. It's not clear that this is an advisable adjustment, but it explains part of the significant performance difference.

I ran some tests on the aforementioned Dell system to measure the effect of these various settings. I used the grip CD ripping tool and ripped to raw WAV format. The trials were all timed by the wall clock, so take the results as plus/minus a few seconds.

DMA Error Checking rip time
off on 10:18
on on 7:42
off off 3:14
on off 2:01

By comparison, when I rebooted this system into Windows XP and ripped with Windows Media Player to Windows Lossless Format, it took 2:23. (This isn't quite apples-to-apples since there was an additional encoding step under Windows, but that should have only added a few seconds at most.) This was an unexpected surprise: Linux actually outperformed Windows. I was shocked, given how poor the initial results were.

Now that I'm over this hump, the research continues. I'd like to investigate whether "error checking" is a valuable protection, or unnecessary overhead. Also, I need to determine which ripping and playing tools I want to use. A database backend would be nice. I'm pretty sure I want to rip into the lossless FLAC format. I need to verify that's going to be feasible for our CD collection.

Comments

Comments have been closed for this entry.

re: Linux CD Ripping Performance: Surprising Results

I should note that this thread had some helpful information (although I did not get the same results when testing 32-bit I/O). Also, Joe Barr helped by pointing me towards the "paranoia" setting.

re: Linux CD Ripping Performance: Surprising Results

I run Debian sarge and I'm unable to locate the /etc/hdparm.conf file. I'll google this for now but I'm hoping you can enlighten me.

Thanks.

re: Linux CD Ripping Performance: Surprising Results

Load the hdparm package.