Getting a grip by Jason Wallwork   I'm going to tell you something really shocking. Make sure you're sitting down before you read this. In fact, if you have any heart problems, you'll want to skip this next paragraph entirely. I don't have a big stash of MP3 files! I know; I'm behind the times. I haven't really felt the utter pangs of joy from ripping my entire CD collection into compressed algorithms of technical bliss. So take this article part as confessional, part as maybe helpful to those of you who have only begun ripping their CDs. Those of you more experienced can laugh your way into the next article. Those of you that are new to this can follow along. Let's start with lingo. CD music tracks are stored digitally which is great because that's how computers store data, too. Copying those songs from CD onto your hard drive is called ripping. The songs are ripped from the CD and stored as separate wave files (ending in  .wav). A CD has about 650 MB of information on it. As you can imagine, keeping the data this way would fill up your hard drive in no time, so not many people bothered. Then along came the mp3 format. It does for audio what jpeg does for images. MP3 is a compression format for audio that compresses data at an 11:1 ratio. That 650 MB audio CD now takes up under 60 MB of space, and potentially even half that (depends on quality). The program that converts *.wav files to *.mp3 files is called an encoder. Lastly, if you want to keep your music on discs still, but want to fit, say, 100 songs to a disc, you can copy the encoded mp3s back onto a CD-R. There are portable CD players that can play mp3 files as can most DVD players. Copying data, music or video onto a CD is known as burning it, probably because a laser actually melts the data pits onto the CD in a CD-RW drive (also known as a burner). Now the fun stuff. Under Windows, the ripper, the encoder and burner are usually combined into one program that does it all like the Musicmatch program. Under Linux, the program that does ripping and encoding is usually grip. But grip is actually just a graphical interface for the programs underneath that are doing the actual work. That's often the case with Linux programs. This is such an important point that I have to repeat it: grip is actually just a graphical interface for the programs underneath that are doing the actual work. Knowing this can help you fix ripping problems on your own including the one I had next. I used my SuSE 8.1 Pro CDs to install grip. Along with grip, some ogg vorbis and cdparanoia packages were installed as well. Don't you simply love the way Linux afficionados name things? I know I do. Once grip was installed, I put in a music CD and ran grip from the Multimedia--> CD menu. Grip has a nice interface as you can see in the screen shot below. If you only get empty tracks showing up, then either the FreeDB server isn't available for queries (it tries to match your CD with a list of tracks), grip isn't configured to use one or your musical tastes aren't that popular! Don't worry, that happens to me a lot. Feel free to submit your info to FreeDB if so inclined. Note the menu items tabbed along the top and the CD player buttons along the bottom. Grip is a CD player as well as ripper which makes it easy to listen to your tracks so you can choose which to rip, just in case you don't like all the songs on a CD. I've heard this happens with some CDs. If everything is setup properly, you can rip and encode the entire CD easily. Make sure you have enough hard drive space - 650 MB minimum normally. The *.wav files are deleted after each is encoded into an *.mp3 so you might be able to do with less. If you run out you'll just get an error message and still have some of the songs done. Click on the Rip tab and click Rip+Encode. One of the reasons, I haven't ripped all my CDs is that I don't have much hard drive space. So, if you're lacking for space like me, or only want to rip a few tracks, you can do so by selecting them on the tracks screen by clicking the right mouse button for each. Then, back to the rip screen and Rip+Encode. The files are stored in a directory labelled mp3 in your home directory, under the artist name and then the album name. Now, the difficulty I had, and you might have (especially if you use SuSE 8.1 Pro) is that when I tried Rip+Encode, nothing happened. The folders were created but there wasn't an mp3 file. I tried it with a couple of songs and then just one. I tried different CDs but with the same result: no error message, nothing. What was going on? The first thing I thought was that I didn't have permission to access the drive. SuSE sees the CD-RW drive as /dev/sr0 but there's a symbolic link from /dev/cdrom to it since that's where most programs expect the drive to be. I certainly had read permissions and I had write permissions as well from having used a burner program (k3b) which made those changes for me. Something else was going on. I did searches on google and all I could find were basic tutorials to grip (like this one) but nothing about what to do when it didn't work. That's when I realized that grip doesn't actually do the work, so maybe the problem was in the ripping or the encoding program. That's why I emphasized that point before, grip doesn't do the work itself, it hands the ripping task off to cdparanoia and encodes with oggenc (in my case, yours may be setup to use a different encoder). Oggenc is a program that encodes *.ogg files, which are like *.mp3 files but I think they sound better and compress to slightly smaller files. Ogg is also freely licensed, unlike MP3. Then maybe something was going wrong at the ripping stage. So I did some reading and figured out how to use cdparanoia by itself, which is a console program. Then I tried to rip one track using cdparanoia. I received this error message: could not find generic device to match SCSI cdrom device Not a particularly helpful error message, but at least it was something to go on. It was enough to get me to a web page on troubleshooting cdparanoia and a fix: This error means exactly what it says; the generic SCSI devices are missing, unusable or have permissions set to deny access by users. First, a bit of explanation... Cdparanoia doesn't actually use the 'normal' SCSI cdrom device, typically /dev/scd* or /dev/sr*; it uses (and requires) a generic SCSI device (typically /dev/sg*) to access a drive's audio extraction features. Cdparanoia does accept the CDROM device name because users are used to this device specifying a cdrom drive, but only uses the CDROM device name to map to a matching generic SCSI device. If cdparanoia can't get to a working set of generic devices, it can't use a SCSI drive. Before sending mail, check that: 1. The kernel has generic SCSI support compiled in (or the generic module available). Generic SCSI support does *not* mean only SCSI or SCSI CDROM. 2. Those using ATAPI CDROM drives with IDE-SCSI emulation must *not* have ATAPI CDROM support included. ATAPI IDE-SCSI emulation users must have all the appropriate SCSI support selected. 3. The generic SCSI devices (/dev/sg*) must exist and be accessible. Check that permissions on the device entries allow user or group read *and* write access (it's safest to grant user or group access only to the device matching the cdrom). I know that (1) and (2) weren't at issue because I've already burnt discs without a problem. Therefore, the problem must be in the permissions for the /dev/sg0 device. I checked it and sure enough, it didn't have write permission. Unlike what the cdparanoia FAQ writer stated, however, I had to give read and write access to all. Right after I did this and tried grip again, it started ripping and encoding with no further problem. My point of this article? Sometimes you need to dive into the inards of Linux to fix things. Not all the programs generate error messages that you can see graphically. Sometimes simply running a program in the console (or konsole) will give you clues to fix the problem. Meanwhile, happy gripping!           ©2003 Peterborough Linux User Group, All Rights Reserved. Logos and buttons are used by permission of their respective owners. PLUG can not be held liable for damages resulting from the use or misuse of the information at this website or from its members. Don't run with scissors.   Comments can be sent to Jason Wallwork, Webmaster.