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
Installing CCDR is a simple process of issuing the following commands:
wget https://absolutelybaching.com/abc_installer bash abc_installer --ccdr
The first command downloads a generic installer script. The second command is an instruction to run that installer script, specifying (with a double-hyphen parameter) that it's CCDR you want to install. You will be prompted at one point for your sudo password, without which the installer cannot install the software in the /usr/bin folder correctly.
3.1 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!
3.2 First Run and Software Prerequisites
The first time you run CCDR (with or without command-line switches), the program will evaluate your system and provide distro-appropriate prompts to install any missing software prerequisites it determines are not already present on your system. For example, on Ubuntu, you might see this:
Thus, you issue the software installation command shown in bold yellow to get the necessary software components installed before you can run CCDR successfully a second time. On Fedora, you might instead see something like this:
Notice that the installation command is "sudo dnf install" this time: CCDR is 'distro-aware'. The other unique thing here, however, is that on Fedora, you cannot install the ffmpeg software from the standard repositories (possibly because of software patent issues). Therefore, CCDR tells you that you first need to enable the RPM Fusion repository, if you haven't already done so (though I think most Fedora users tend to enable this repository as one of the first things to do after any fresh O/S installation!)
If you haven't previously enabled RPM Fusion and need to do so now, just issue these two commands:
sudo dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm
sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
Once they've been enabled, you can issue the 'sudo dnf install' command first shown by CCDR, and then you're ready to run CCDR for real.
3.3 Using CCDR
CCDR may be invoked with or without an audio CD being present in the drive implied or explicitly specified. The program will first evaluate the first optical drive used by your system (or whichever drive you've directed it to use with the --device or -d switch if your system has more than one optical device).
in either case and determine the 'read offset' needed to make the device function accurately. These details will be displayed to you
In this specific case, I'm running CCDR inside a virtual machine, so the "optical drive" is entirely fake and as a result, the program can't look up a correct 'drive offset' for the device. All optical devices are manufactured with a 'drive offset': it means that if software instructs the drive to read block 1000, it might read block 994 or block 1026 or some other block instead. Reading the wrong blocks makes for inaccurate rips, so knowing the 'offset' required to make it read the right blocks is important. CCDR tries to work it out, but -as you can see- if it cannot (because your hardware is weird, old or, as in this case, not actually real) then it will prompt you to supply a drive offset of your own. You may be able to determine it by looking your drive up in online databases or by reading the manufacturer's product data sheets. If you don't know it, just press [Enter] and a drive offset of zero will be applied, but this will almost certainly be wrong.
Chances are, however, that the program will determine your drive offset correctly -in which case it will simply display the device identifier, like this:
If the program is silent about drive offsets, in other words, that's good news: it's been able to work out what the correct offset for your particular hardware should be and will apply it automatically in future to ensure accurate rips.
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:
Five simple questions are 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 (but you shouldn't: every recording needs to have a recording date, for example).
Since this is my first time running the program, you will note that the questions end and then you immediately type your answers. Second and subsequent runs of the program will display the answers from your last run of the program, like this:
This time, my previous answers are displayed in a pair of square brackets. If I want to re-use the previous answer, I can just press [Enter]. If I need to change the previous answer, I just type a new answer as I did originally. This allows a CD that contains two or more compositions to be ripped efficiently: most of the answers for the first composition will probably apply to the second or subsequent compositions on the same disk, so you'll only have to type full answers when ripping the first composition and press [Enter] a lot of the time on subsequent rips.
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.
Note that the program uses your responses to correctly tag the resulting ripped audio files. In particular, your answers for 'what's the composition name', 'who is conducting' and 'what year' will be combined to create an ALBUM tag (and a name for the hard disk folder into which the ripped files will be stored. When doing this combining, the program only takes the last name of the supplied conductor. So, in the example shown in the above screenshot, "Vernon Handley" will be turned into 'Handley', and the ALBUM tag will be set to The Perfect Fool (Handley - 1993).
Be aware that the conductor's name (or other principle artist, if you prefer) will always be chopped off in this way. If you say your symphony is being conducted by 'Herbert von Karajan), for example, then the results will always be 'Karajan'. If you wanted it preserved as 'von Karajan', you are out of luck as far as CCDR is concerned, but you can always correct the rip after it's finished with a tool such as the Classical CD Tagger.
Finally note that if you choose not to provide a recording year, then no attempt is made to append it to the ALBUM tag in the way previously described, though the conductor's name always is: you would end up with, simply, The Perfect Fool (Handley), not The Perfect Fool (Handley -).
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.4 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)
5.0 Housekeeping and Legal Stuff
The CCDR FAQ
A list of common questions and answers about the software can be found here.
Author
CCDR was devised and written by Howard Rogers ([email protected]).
License
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].