User Tools

Site Tools


Rip Audio CDs on Linux

1.0 Introduction

The primary requirement for an audiophile when ripping music CDs is to rip safely rather than speedily -i.e., that the output files should match the content on the original CD bit-for-bit, as far as possible, even if this means the ripper has to make multiple passes of the disk and/or deploy its error-correction algorithms. The secondary requirement is that the ripper should be able to output files in multiple formats: ideally, I want FLAC files for 'desktop listening' and much smaller MP3 files for 'listening on the go' -via my mobile phone and bluetooth headphones, for example, when audio fidelity is not of prime significance.

There are, I think, two principle candidates for ripping on Linux: whipper or abcde.

2.0 Whipper

Whipper is very good at ripping accurately, since it's one of the few Linux rippers that knows how to work with the AccurateRip database. The theory goes that if you calculate a checksum for each track ripped and compare it with a database of other people's checksums obtained when they ripped the same track in the past, if the checksums match then your new rip is mathematically identical to theirs -and therefore must be bit-for-bit identical to each other. That, in turn, means the probability is that you both managed to obtain perfect rips from your original CDs. As an example, here's me ripping a CD I got on the front of the BBC music magazine recently:

[[email protected]@britten ~]$ whipper cd rip
Using configured read offset 6 
Checking device /dev/sr0 
Reading TOC... 
CDDB disc id: 8312e409 
MusicBrainz disc id kwomyAgOE2o8uDtwa6DpHWM2u5M- 
MusicBrainz lookup URL attach?toc=1+9+362857+150+24497+58478+66141+96710+140800+174354+202994+255186&t
Disc duration: 01:20:36.093, 9 audio tracks

creating output directory ./album/Shostakovich, Schnittke; Paul Lewis - BBC Music Volume 26, Number 6 - Shostakovich - Piano Concerto no. 1 - Schnittke - Concerto for Piano and Strings 
Ripping track 1 of 9: 01. Dmitri Shostakovich - Concerto for Piano, Trumpet and String Orchestra, op. 35 - I. Allegro moderato.flac 
CRCs match for track 1                    
Peak level: 24448 
Rip quality: 100.00%

As you can see, the command to initiate a rip is straightforward enough. You can also see that the program looks up the MusicBrainz database to find out what CD it is that I'm attempting to rip: it found a good match, so starts ripping the first track. One of the messages returned when it has done so is, “CRCs match for track 1” -meaning that the checksums obtained from this rip match those found in the AccurateRip database for the same track on the same CD as submitted by (potentially) many dozens or hundreds of other users. Therefore, the rip is considered to be of “100% quality”.

So far, so good. But Whipper has a number of issues.

For a start, it's documentation is extremely poor: its software download page probably has the most comprehensive documentation I've found available, and it's pretty short! You get nothing by trying to read a man page for it:

man whipper
No manual entry for whipper

It's online help system is similarly on the thin side:

[[email protected]@britten ~]$ whipper --help
usage: whipper [-R] [-v] [-h] [-e {never,failure,success,always}] 

whipper is a CD ripping utility focusing on accuracy over speed. 

whipper gives you a tree of subcommands to work with. 
You can get help on subcommands by using the -h option to the subcommand. 

optional arguments: 
 -R, --record          record API requests for playback 
 -v, --version         show version information 
 -h, --help            show this help message and exit 
 -e {never,failure,success,always}, --eject {never,failure,success,always} 
                       when to eject disc (default: always) 

 accurip  handle AccurateRip information 
 cd       handle CDs 
 drive    handle drives 
 image    handle images 
 mblookup lookup MusicBrainz entry

Secondly, Whipper isn't terribly flexible: as far as I can tell, it outputs in FLAC format only and there's no possibility of making it output anything else, at all, ever. You can always copy the FLACs it produces and then subject the copies to further encoding to MP3 by a different program, of course: but that's extra manual fiddling and hassle.

The third problem I have with Whipper is its exclusive use of MusicBrainz for its CD metadata retrieval. To be fair, I've never known any source of CD metadata be anywhere near useful or accurate -I always end up having to type my own metadata pretty much from scratch, for example- but I have usually found MusicBrainz slightly more useless than CDDB, so Whipper's reliance on it is, for me, something of an issue.

The short version is, therefore, that Whipper is useful -but it's not something I'd want to use long-term.


Abcde is the name of 'a better CD encoder' and is much better documented than Whipper -and much more flexible, too. For a start, it will output music files in a variety of audio formats: FLAC, MP3, OGG… you name it, it can do it. What's more, it will actually output multiple audio formats at the same time. So, with one rip, I can get both my FLAC and my MP3 versions produced simultaneously.

It's secure, in the sense that it relies on cdparanoia to do the actual ripping. Configured correctly, cdparanoia can take many hours to rip a CD accurately, but will generally get there in the end. Whipper's alternative approach of using AccurateRip to determine accuracy can mean quicker rips, though.

Finally, abcde is very configurable: everything can be pre-configured in an abcde.conf file, with simple variables declaring how each part of the program will behave. Here is my configuration (stored in $HOME/.abcde.conf):

# Rip all tracks and only then encode them. This takes more disk space
# but makes abcde run much faster

# Specify the CD Device (important if you have >1 CD drive)
# Specify the method to use to retrieve the track information,
# the alternative is to specify 'musicbrainz':

# Make a local cache of cddb entries and then volunteer to use 
# these entries when and if they match the cd:

MP3ENCODERSYNTAX=lame # Specify encoder for MP3
FLACENCODERSYNTAX=flac # Specify encoder for FLAC

LAME=lame # Path to MP3 encoder
FLAC=flac # Path to FLAC encoder

LAMEOPTS='-V 0' # Options for MP3 
FLACOPTS='-s -e -V -8' # Options for FLAC


# The cd ripping program to use. There are a few choices here: cdda2wav,
# dagrab, cddafs (Mac OS X only) and flac. New to abcde 2.7 is 'libcdio'.

# Give the location of the ripping program and pass any extra options,
# if using libcdio set 'CD_PARANOIA=cd-paranoia'.

# Give the location of the CD identification program: 

# Give the base location here for the encoded music files.

# The default actions that abcde will take.

# Decide here how you want the tracks labelled for a standard 'single-artist',
# multi-track encode and also for a multi-track, 'various-artist' encode:

# Decide here how you want the tracks labelled for a standard 'single-artist',
# single-track encode and also for a single-track 'various-artist' encode.
# (Create a single-track encode with 'abcde -1' from the commandline.)

# This function takes out dots preceding the album name, and removes a grab
# bag of illegal characters. It allows spaces, if you do not wish spaces add
# in -e 's/ /_/g' after the first sed command.
mungefilename ()
echo "[email protected]" | sed -e 's/^\.*//' | tr -d ":><|*/\"'?[:cntrl:]"

MAXPROCS=8 # Run a few encoders simultaneously
PADTRACKS=y # Makes tracks 01 02 not 1 2
EXTRAVERBOSE=2 # Useful for debugging
EJECTCD=y # Please eject cd when finished :-)

Stepping through this bit by bit…

LOWDISK=n means that abcde will rip all the tracks of the CD in one go and then encode them into FLACs and MP3s afterwards. It means that, temporarily, the raw WAV files will all exist on disk before they get replaced by their smaller encoded equivalents… and that obviously means more disk space is taken up (temporarily) per rip. The alternative (LOWDISK=y) means 'rip a track, encode it, then rip the next track, encode it and so on'. Much lighter on disk consumption, but seriously slows the ripping process down.

CDDBMETHOD gives you the option of getting abcde to use either CDDB or MusicBrainz as its metadata source. Unfortunately, a bug means that MusicBrainz won't work on Fedora 28, so CDDB it has to be. (Mind you, as I've already mentioned, I find MusicBrainz metadata for classical CDs much worse than CDDB's, so this enforced use of CDDB is not an issue for me).

The two …ENCODERSYNTAX entries indicate that I want to use both FLAC and MP3 encoded tracks. This then means I must have already installed the relevant encoding software: a sudo dnf install flac lame will take care of that.

The CDPARANOIA… entries indicate that I want to use the cdparanoia engine to do the actual ripping. This comes pre-installed with Fedora 28, but if necessary, it can be easily installed on most Linux distros by using their standard repositories. Note that the use of –neverskip=40 for one of the options means that cdparanoia will not allows itself to skip over any misread parts of a CD, but will keep trying to read bad sectors of a disk forty times. If it can't manage a good read by then, it will throw an error and stop any further ripping: this is how you know you'll get a good, accurate rip of a CD.

My ACTIONS section is listed as “cddb,read,encode,tag,move,clean”. This means, in turn, 'find out what this CD is and look up its metadata at the CDDB database; read my CD and extract its audio content; encode the audio into whatever formats I told you to use with the …ENCODERSYNTAX parameter; complete the tags in each encoded file, so that the metadata is included within the file; move audio files to the output destination I've told you to use with the OUTPUTDIR parameter; and once everything is finished, clean things up by deleting any temporary files and so on'.

There are other possible actions that I haven't listed. I don't want cuesheets or playlists generated, for example; getting album artwork embedded in the output files is problematic on Fedora, so I skip those possibilities here (and I do better album art by hand, anyway!) I especially do not want my audio tracks 'normalized', so that option is very deliberately omitted. (Normalization is the process of making a bunch of track's volume level more or less the same across all tracks on a CD. For some people, this is a good thing, because it means you can play a bunch of tracks without having to bump the volume up or down as each new track starts. But when you're listening to classical music, you really don't want the slow, quiet movement of a concerto to be played at the same level as the fortissimo full-orchestra allegro that began the piece!)

The complex-looking bits around the OUTPUTFORMAT parameters define the file names that abcde will produce when it encodes. To be honest, it really doesn't matter to me what abcde outputs, because I will re-tag my files manually as a separate exercise and re-name the files based on those tags. But on the off-chance that, once in a blue moon, CDDB will provide metadata that is vaguely accurate, it makes sense to get abcde to name things properly too! Here, I'm asking for files to be called ${TRACKNUM} - ${TRACKFILE} -in other words, something like “01 - Allegro” or “04 - Sanctus” …whatever the track number and title happen to be, nicely separated by a hyphen.

I want the files stored in a sensible folder hierarchy, though. I've asked for: ${OUTPUT}/${ARTISTFILE}/${GENRE}/${ALBUMFILE}/, meaning that I'd end up with a directory called flac or mp3 to start with (that's what $OUTPUT means); within that, I'm going to have the Artist's name, and within that the Genre, and finally within that the Album Name. So, for example, I might end up with /flac/benjamin britten/opera/billy budd or /mp3/bela bartok/choral/cantata profana. This is a ripping hierarchy that meets most of my requirements, but -as I've hinted already- usually the metadata returned from CDDB is so bad that no meaningful directory structure will be obtained by abcde directly and it will be up to me when manually tagging the files post-rip to get things in proper good order.

The rest of the configuration file is, hopefully, mostly self-explanatory: though you can only rip a CD sequentially (there's only one disk and one laser reading it, after all), you could have multiple files output and awaiting encoding -and on a multi-core CPU, it makes sense to parallelize that encoding phase of proceedings. Hence, I've set MAXPROCS to 8. I like double-digit track numbers, lots of output appearing on-screen during the rip and I find it helpful to have the CD auto-ejected after ripping.

4.0 The Classical CD Ripper

Dissatisfied as I was with both Whipper and ABCDE (I mean, why bother doing Internet lookups for track metadata in the first place, when you know in advance that no matter where you source it, it's going to be mostly rubbish!), I decided to knock together my own: The Classical CD Ripper.

It's secure, in that it uses the cdparanoia back-end ripping engine, but instead of looking CDs up in online databases to fetch poor-quality metadata, it prompts you to type in the information -so your metadata ends up being as good as you want to make it.

It only outputs to FLAC (because I can copy-and-convert afterwards), and it uses proper Vorbis tags to mark up the ripped audio files with metadata, whereas most other rippers seem to pack everything into ID3 tags (which are really only supposed to be used to mark-up MP3 tracks). It's basic, but functional and, these days, I don't use anything else to rip my CDs!

wiki/linux/useabcde.txt · Last modified: 2019/05/21 10:28 by dizwell