It's Just this Little Chromium Switch Here

FedEx delivered the parts for my new media PC today. It took a few hours time (and an unplanned run to Fry's Electronics) to put it together, but now I'm ripping and playing CDs.

Here are the parts I'm using:

• ASUS Pundit-R "booksize" barebone computer
• Intel Celeron D 335 Prescott CPU, 533MHz FSB, 2.8GHz operating freq
• Hitachi Deskstar T7K250 160GB SATA hard drive
• NEC ND-3540A DVD Burner
• two Kingston 256MB DDR400 CL3 memory modules
• IOGEAR GWU523 USB 802.11G WiFi adapter

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.

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.

Although I'm finding some interesting things about the Hurricane Katrina relief effort blogged at Boing Boing (I posted one earlier today), I'm seeing some terribly misguided, distressing things too.

For instance, start with this post about the "concentration camp" setting in a Denver shelter. That striking description, however, is pulled out of context. Nobody in the shelter called it a "concentration camp." They are quoted saying things like, "real glad to be here." The "concentration camp" description comes from the reporter's displeasure at not having full access to the facility.

Well, how would you feel about the press being able to barrel into your bedroom at any time? Don't you think that might be a little damaging to your comfort and dignity? There are good reasons to manage press access in the residents' spaces.

Or take this article about the inability of some well-meaning volunteers to setup a low-power radio broadcasting facility in the Houston shelter. At this time the authorities are more concerned with moving people out of that shelter—not adding new ammenities to it—and they are doing a good job of it. News reports I saw today had the resident count down from 20,000 to 3,000.

I was listening to a disaster relief expert on the radio tonight (audio here, starting at 1:00) explaining how mass shelters are not the best solution, and instead create a lot of problems. I'd rather see officials working on moving people into better living circumstances, not building up a tent city.

The Red Cross may be a big, stupid bureaucratic organization, but they do have a little experience dealing with natural disasters. The Boing Boing crew (mostly Xeni) needs to drink a nice cup of STFU and recognize that their immense cleverness may not be what the evacuees need most right now.

There is an urgent need for Cold Fusion/Fusebox programmers to help develop automation tools to support the Austin shelter for Katrina evacuees. If you know anybody who can help, please email me at chip [at] unicom [dot] com and I will connect you with the appropriate city personnel.

Please do not distribute this notice after Friday, September 9.