Recorded here are my thoughts and experiences using my Rio 500 with Linux. In the course of getting my Rio 500 to play nicely with my Linux machine, I have: added USB support to my 2.2.14 kernel; ripped WAVs from audio CDs; encoded WAVs in MP3 format; uploaded the MP3s to my Rio 500. Below I detail each of these steps.
Enabling USB support for my 2.2.14 kernel was actually quite straightforward. The Linux USB Project has a patch available that backports the kernel 2.3.x USB code into the 2.2 tree. I downloaded the patch, followed the instructions, and a quick compile later I had USB support.
One note, though, about configuring the kernel. One of the optional
USB drivers included in the kernel patch is for the Rio 500. I enabled
this driver, but I'm not entirely sure that it is either sufficient or
necessary for proper Rio 500 / Linux connectivity. Specificially, it
seems that I also (or only?) need the rio.o module that comes
with the Rio/Linux package (described below). I will need to reboot my
machine and try a few experiments before I can determine if
kernel Rio 500 support is useful (in light of having the
user-supplied Rio support).
Building MP3s from audio CDs is a two-step process. In the first step, you rip the audio tracks off the CD and (typically) into WAV files. (Question: why is this process called "ripping"? I don't know...) WAV files are more or less "raw" audio data -- they're uncompressed. If you rip a full 60 - 70 minutes of music from a CD, you're likely to end up with about 600MB of data on your hands (hint: there's likely a correlation between this effect and the fact that a CD can hold 74 minutes of audio or 640MB of data). In the second step, you encode the WAV files into MP3s. The encoding pretty much involves sampling the audio files and compressing the heck out of the data. In the end, you get an MP3 file, whose size is about 1MB / minute of high-quality music.
There are many tools available to rip WAVs from audio CDs. cdparanoia and cdda2wav are two of the probably most well-known utilities. I'm presently using grip, which is an integrated ripper/encoder/player tool with a Gtk interface. The built-in ripper is cdparanoia, but it can suppport external rippers as well. grip has no built-in encoder, though, so an external tool is required (see below for more details). Let me go into more detail about my experience with both grip and cdda2wav.
grip has a very nice interface. Gtk apps, done well, have very pretty UIs, and grip is a good example of such. grip is designed as a sort of one-stop audio CD tool -- playback, ripping, and encoding. I don't care much about playback -- I have a nice stereo within arm's reach that will play all my CDs much more easily. So, I'm most interested in grip's UI and functionality as a ripper. There, unfortunately, I'm a bit dissappointed.
My specific concern is that grip (or, cdparanoia, I guess, because grip is advertised as using cdparanoia built-in) seems to slur the first 1sec. or two of adjacent tracks together. For example, when I ripped track 4 of one of my CDs, the first second of track 5 appeared (or, the audio equivalent of "appeared") at the end of the resulting WAV file. This behavior was certainly unexpected and a bit annoying.
I've played with cdda2wav for only a very small bit. Mainly, I wanted to evaluate whether the artifacts that grip was indicating (see above) were intrinsic to my machine/OS, or to just the ripper I was using. Result: same problem. *sigh*
The other half of the audio-CD-to-MP3 fun is encoding the WAV files into MP3s. Again, I use (used) grip to drive the encoder, because I like GUI front ends. grip can deal with a number of different encoders, but I chose BladeEnc. Installing and using BladeEnc was actually a no-op, because I just pulled up the .deb file from Debian's site for the installation, and I let grip do all the driving. So, no excitement here.
After some playing around with the tools available for Linux, I've actually decided to just find a Windows machine to make my MP3s on, using the RioPort software. RioPort does a good job both in quality and performance. The resulting MP3s don't have the same strange sound quality problems that I found with grip and its friends. And RioPort can make MP3s in about 80% real-time (ie, about 50 minutes for an hours' worth of music). Compared to my experience, of over two hours of effort for a single CD, RioPort seems like the best alternative. I'll still write the MP3s to my Rio with Linux, though, which I describe in more detail next.
Ripping and encoding audio data needs to happen really only once per song -- you can just store the MP3s on your hard disk until the end of time. What's far more interesting on a day-to-day course is communicating with your Rio 500. To link up your Rio to a linux machine, you'll want to visit the Rio 500 Linux support page at SourceForge.
The Rio 500 support comes in three pieces. First, there is a loadable
kernel module rio.o that adds the glue between Linux and your
Rio on the USB. You'll need to be sure that you have USB support in your
kernel before you can make this module work (see above for tips on adding
USB support). Second, there are Rio runtime libraries that can be used by
applications to communicate with the Rio. These libraries are used
primarily by the third component, a set of specific Rio applications.
I use the Rio 500 Linux support to upload music and to check what's currently loaded on my device. The complete set of utilities that the Rio 500 support provides is as follows.
rio_stat
rio_stat
Print out a bunch of interesting info about your Rio and what's presently loaded on it. Perhaps the most interesting bits are the amount of free memory and the song list.
add_song
add_song <file> <folder_num> <font_name>
<font_number>
Performs the obvious functionality: upload an MP3 to the Rio. You can optionally supply which folder into which the song should be placed, as well as the font with which the song title should be displayed (yes, the Rio can change fonts!!).
add_directory
add_directory <directory> <folder_num>
<font_name> <font_number>
Adds all the songs in a specified directory to the Rio. Optionally
may be given the folder number and font info that should be applied
to each song. Note, though, that the order in which the
songs are added to the folder is dependent upon the order that the
shell will list the .mp3 files (for shell programers, you'll
understand why because the line for file in *.mp3
appears in the script). So, if you want to drop a complete CD,
track-for-track, onto your Rio, you need to take care that the
order of the tracks is preserved.
add_folder
add_folder <folder_name> <font_name>
<font_number>
Creates a new folder on the Rio.
del_song
del_song <folder_num> <song_num>
Removes a song from the Rio (obvious enough). Give the (name or?)
number of the folder and the number of the song. It
appears that, if given -1 as the song number,
del_song will delete the folder. I need to check
this, though...
format_rio
format_rio
Blow away all song and folder data on the Rio.
There are two helper applications that are seriously missing from the Rio support. First, an application that will record the order of the tracks on an album, and later use that data to uplink to the Rio the tracks in the same fashion. Second, and related, would be an application that connected to cddb.com and found the various album info (album name for folder name, order of tracks). Of course, these applications are just useful utilities; the core functionality needed to uplink from Linux to the Rio exists in good enough fashion presently.
For the simple stuff, like uploading a single song, the Rio 500 support for Linux works just fine. For more complex applications, though, there are still some areas that need work.