The Classical CD Ripper (CCDR)

1.0 What is CCDR?

CCDR is (I think!) a better way to rip Classical music CDs! It’s precise and accurate, generating perfect copies of your precious CDs. It doesn’t fetch metadata from online databases, but will instead ask you a handful of questions that allow you to specify your own, accurate metadata. It outputs files to lossless FLAC files, which then represent a bit-perfect archive of your physical CD.

In short, CCDR provides an excellent way to transition from physical musical media to the world of digital music.

2.0 Why CCDR?

There are a lot of CD rippers out there, but CCDR has the following features which makes it especially useful to the fan of Classical music:

  • CCDR will not fetch masses of rubbish metadata about your CD from online databases
  • It will only rip to lossless FLAC files, preserving the entire audio signal
  • It rips carefully and correctly, with speed not being a priority
  • Its rips are verifiably accurate, with hash values for the audio signal being generated by default
  • You can rip just a part of a CD, specifying the track numbers uniquely for each part -handy for when one CD contains two different symphonies or multiple concerti, for example

3.0 Obtaining and Using CCDR

CCDR is a simple Bash script which can be downloaded by clicking this link. Once downloaded (I shall assume you’ve downloaded it to your own Downloads folder for what follows), you ‘install’ it by opening a terminal session and typing the following:

sudo mv $HOME/Downloads/ /usr/bin 
sudo chmod +x /usr/bin/ 
sudo ln -s /usr/bin/ /usr/bin/ccdr

That is, as root, you move the downloaded file into the /usr/bin folder (where it will then be in your environment’s PATH). You make it executable. Finally, you create a link to the new executable that lacks the “.sh” extension, so that you can invoke the program just by typing “auac”, rather than “”.

Since CCDR is simply a Bash shell script, you are encouraged to open the downloaded file in the text editor of your choice, to satisfy yourself that it does what it claims it will do and nothing else.

3.1 Software Prerequisites

CCDR has some software dependencies which need to be satisfied before you can run the program successfully. Different distros install packages in slightly different ways, but here are the basic instructions for the main distros I use:

On Arch/Manjaro:

sudo pacman -Sy flac gawk wget grep cdrtools cdparanoia ffmpeg

On Ubuntu:

sudo apt-get install flac gawk wget grep cdparanoia ffmpeg

On Debian:

sudo apt-get install flac gawk wget grep wodim cdparanoia ffmpeg

I have not yet been able to find an easy way of enabling APE support in the latest version of Debian.

On Fedora:

sudo dnf -y install$(rpm -E %fedora).noarch.rpm 
sudo dnf -y install$(rpm -E %fedora).noarch.rpm 
sudo dnf install flac gawk wget grep cdrtools cdparanoia ffmpeg

3.2 Running CCDR

Once you’ve ‘installed’ CCDR and its associated software prerequisites, you can run it by opening a terminal session and typing this sort of command:

ccdr [ -r=y | -d=<name of cd/dvd device> | -h=<name of parent music folder>]

This means that the program can be launched with up to three optional parameters as follows:

-r or ––reset : Set to a value of ‘y’ or ‘Y’, if present this flag will trigger CCDR to forget details of any prior runs. Without the flag being present (or with it set to a non-y value), CCDR will remember details of previous runs, such as the CD device used, the composer, conductor, the year of recording and so on.

-d or ––device : By default, CCDR will use the first available CD or DVD-ROM drive it finds on the system. If you have multiple drives, however, the default choice may not be the one you prefer to use. With the device flag, you can instead force CCDR to use a named CD or DVD-ROM. These devices are typically named something like /dev/sr0 and /dev/sr1 on most Linux systems these days, so /dev/sr0 is the one that will usually be used by default and you’d type ccdr -d=/dev/sr1 to force the use of the other drive. Having forced the use of a non-default drive once, CCDR will remember that choice for all future runs, unless you force it to forget it by invoking it with the -r reset flag.

-h or ––home : By default, CCDR will attempt to store ripped music files within your own Music folder (i.e., $HOME/Music). If you wish it to instead store audio files in another location, you can specify that alternative location with a -h or ––home parameter. For example, if you wanted music ripped to /music/rips, you would launch CCDR with the command ccdr -h=/music/rips or ccdr ––home=/music/rips. If you always want to specify a special location for your rips and don’t want the hassle of remembering to always use the -h or ––home switches, you can instead set the CCDR_MUSICHOME environment variable in your .bashrc or .bash_profile scripts. For example, here I’m asking for CCDR always to rip to a non-standard location, via my .bashrc:

Once I start a new terminal session after saving that last line into my .bashrc script, I can just launch CCDR with the plain vanilla ccdr command and it will output all ripped files to my Desktop/rips folder without further persuasion required!

CCDR may be invoked with or without an audio CD being present in the drive implied or explicitly specified. The program will attempt to evaluate the drive in either case and determine the ‘read offset’ needed to make the device function accurately. These details will be displayed to you

Once you press a key, the program will see if an audio CD is present and will prompt you to insert one if not. No further progress with the program can be made until an audio CD is loaded and the program determines it can read it:

Once an audio CD is found, the program will prompt you to describe it:

A series of five questions is asked. Answers to the first three are compulsory and the program will keep prompting you for them until a non-blank answer is supplied; the other two are optional and can be left blank if you prefer. Notice that for each prompt, a default answer is suggested in square brackets (in the above screenshot, the default composer is ‘Benjamin Britten’, for example). The previous answers come from your last run of the program. If they are still valid for this run, just press [Enter] to accept them; otherwise, as you see above, just type in new answers when prompted. These will then become the ‘remembered answers’ the next time you run the program.

If you ever want CCDR to forget the results of a previous run, so that no default suggestions appear in square brackets, just invoke it with the -r=y switch.

After 5 questions that capture information about the CD as a whole, there are 5 other questions to negotiate:

You are asked whether to rip the entire CD or only a track or range of tracks; whether you want the ripped tracks to have their track numbers offset from what they are physically on the source CD; whether the CD is to be ejected at the end of the rip; and whether you want two forms of integrity check performed on the resulting files on disk. There are defaults for most of these questions (shown in upper-case letters within the brackets at the end of the question). If you are happy to accept the default, you can just press [Enter]; otherwise, type the appropriate response yourself.

The first two of these questions are perhaps of greatest practical use. Imagine you have a single CD containing two Beethoven symphonies. Tracks 1 to 4 are the first, and tracks 5 to 8 are the second. When you rip the first symphony, you will answer the first question 1-4, indicating that a range of contiguous tracks, from track 1 to track 4 should be ripped. You would press [Enter] on the track offset question, because physical CD track 1 should become hard disk track 1 -so the two track numbers are identical. Therefore, no track number offset is needed.

When you come to rip the second symphony, however, you would answer the first question as 5-8, because you want tracks 5, 6, 7 and 8 to be ripped. You would then supply a track offset of -4, because you would want physical CD track 5 to become hard disk track 1. You therefore instruct CCDR to subtract 4 from the physical CD track number to arrive at the desired track number on your hard disk.

To take one more example: you rip an opera that is supplied on two separate CDs. The first has tracks 1 to 12; the second has tracks 1 to 14. When you come to rip the second CD, you will press [Enter] on the first question to get the entire thing ripped in one go, but you will supply a track offset of 12. That will make the physical CD’s track 1 become the hard disk’s track 13 -which is what you want if you want all 26 tracks of the same opera to flow on together without interruption. You can specify a positive track offset with a leading ‘+’ (just as you specify a negative one with a leading ‘-‘), but it’s not required to do so. For CCDR, 12 is the same thing as +12.

After the fifth of these ‘technical’ questions, the audio ripping process will begin:

CCDR hands over the cdparanoia program to do the actual rip. Cdparanoia rips accurately rather than speedily. It will detect errors (such as scratches) and attempt to correct them. Whether it finds any errors and whether it’s able to work around them successfully is indicated by the various symbols in the ‘progress bar’ displayed in the above screenshot. A complete listing of the symbols and their meaning is available from the cdparanoia website – see particularly the section titled ‘The progress meter’. If the program cannot correct a bad read after 40 attempts, it will abort that track’s rip.

Audio tracks are ripped to the directory shown towards the top of the CCDR progress screen. The particular folder ripped to will always be contained within your own Music folder and will have a name that is constructed from the composer’s name, genre and composition name you described to the program in the initial series of five album-describing questions. The composition name itself will be a compound creation that is not just the plain composition name you supplied, but also has the last name of the conductor (or other principal artist) tagged on to the end of the composition name, in brackets.

Thus, if you said the composition was Symphony No. 4 and that its conductor was Herbert von Karajan, the actual composition name used (and thus the folder the ripped audio is stored in) will be called Symphony No. 4 (Karajan). Although all but the last part of the conductor’s name appears to be discarded, the audio files are actually tagged with the complete name supplied, as part of the COMMENTS metadata tag.

At the end of every rip, CCDR places a log file within the same folder that it uses to store the audio files themselves. It is always worth looking at this log file to see if any errors or other issues arose during the rip.

3.3 Integrity Checks

As part of its processing, if requested, CCDR performs an internal integrity check of the FLAC files that it outputs. This is a simple pass/fail type of check, performed by running the internal FLAC -t test. In the log file produced at the end of the rip, the results would be displayed in this sort of fashion:

Flac internal consistency check:
track01.flac -> OK
track02.flac -> OK
track03.flac -> OK

It’s not a very sophisticated check, in other words! It doesn’t tell you much, other than the FLAC files are considered usable by FLAC’s own decoder software.

A more interesting check is (optionally) available, however: the computation of MD5 hashes. You don’t have to have these computed, but if you do, you’ll see this in the final log file:

Computed MD5 hashes for audio content:
track01.flac -> MD5=1cc2b865c2279b1909378f07fc27dad6
track02.flac -> MD5=acaabc24bb2aef87a8546dffe221526f
track03.flac -> MD5=2956de00e415fb69fbe1cc0b37e5e102

These hashes are generated by the ffmpeg program -so are computed completely independently of the FLAC encoder. They represent a unique ‘fingerprint’ for the audio component of a FLAC file only. That is, the fingerprint will remain invariant no matter how many times you alter the tags or the album art embedded in the file. Should you ever re-compute the MD5 hash and it differs from this originally-determined value, however, then that would be an indication that the audio signal within the file has changed in some way since it was first ripped. This would be an indication of bit-rot or internal corruption of the file, which is likely to affect playback in audible ways.

The MD5 hashes also give you the ability to compare the rips obtained with CCDR with those obtained by other software rippers, such as ABCDE or Exact Audio Copy (EAC). If two programs output the same MD5 hash for files ripped from the same CD, that would indicate that you can rely on either software package to be performing accurate rips.

They therefore also give you the chance to compare the accuracy of different CD-ROM drives on different computers. Your PC’s CD-ROM should produce the same MD5 hashes for the same ripped CD as your laptop’s optical drive. If they disagree, it is an indication that the read-offset is not set correctly, or that something else is making one or other of them produce inaccurate rips.

4.0 Worked Examples

For a complete set of worked examples using CCDR to rip a variety of CDs in different configurations, see this page and read each of the ‘For Linux Users’ articles in turn.

Note that CCDR doesn’t quite complete the rip-and-tag process, because although it can set a number of album-wide tags for you, it cannot do track-specific tagging (such as track titles). To complete the tagging process, therefore, you’ll need to finish things off with a run of the Classical CD Tagger (CCDT)


A list of common questions and answers about the software can be found here.


CCDR was devised and written by Howard Rogers ([email protected]).


CCDR is copyright © Howard Rogers 2019, but is made available freely under the GPL v2.0 only. That license may be downloaded here.

Bugs Tracking, Feature Requests, Comments

There is no formal mechanism for reporting and tracking bugs, feature requests or general comments. But you are very welcome to email your comments, complaints or suggestions to [email protected].