Whilst it's true that there are lots of CD rippers out there, none of them met my specific ripping and tagging needs very well. My favourite CD ripper on Linux, for example, is abcde. It does a superb job of ripping a CD safely (that is to say, it cares more about accuracy than speed). But it spends a lot of time getting CD metadata (composer, work name, track titles and so on) from online CD databases and then prompting you to edit it in not very obvious ways. The metadata for classical CDs is almost always complete rubbish, so all that focus on metadata is completely inappropriate for me. Abcde can be configured not to consult those online databases at all -but then your ripped music is left with absolutely no metadata at all. I wanted a happy medium of allowing myself to specify some metadata, but not to have to fight bad online sources of metadata in the process.
Abcde is also very powerful and flexible, in that you can configure it to rip to MP3, FLAC or pretty much any other audio codec you like… but that flexibility is just a liability for me, since I only ever want to rip classical music to FLAC. So again, Abcde is an excellent ripper -but it's got features I don't need or want, and lacks one or two I really require.
The same is true for practically any other ripper out there. They all, in one way or another, spend time and effort doing things I don't want them to do, or not doing things I really need them to do! Classical CD Ripper (CCDR) gets the balance right (for me, at least!)
It's designed to rip CDs carefully and accurately to make near-perfect digital copies of a CD, using a lossless audio codec (i.e., FLAC). It doesn't rip to MP3, for example, as some of the acoustic information from the music signal is discarded when creating an MP3 version of it. In using FLAC, this ripper produces files which are about half the size of the 'raw' audio signal on a CD, but they still contain every bit of information the original signal had on the CD. This lossless approach to digitizing music is not something that's unique to classical music, of course; but loss-less digitization is arguably more important for the wide dynamic range of classical music than it is for the much-more steadily-loud non-classical genres.
Another thing about this ripper is that it makes no attempt whatsoever to fetch metadata about your music from online databases or repositories since, without exception, all online metadata sources are completely useless for tagging classical music digital files. Other programs that do fetch online metadata will eventually have you listening to George Solti's Das Rheingold, for example; or getting lost in Murray Perahia's Goldberg Variations. Those who listen to classical music tend to think that Richard Wagner and Johann Sebastian Bach should get a rather more prominent mention in the metadata than that!
This means that the Classical CD Ripper outputs a set of unnamed, largely untagged, FLAC audio files -and it's left to you to use third-party programs to carefully edit and curate the metadata you want associated with them. That way, the metadata will end up correct and properly meaningful.
CCDR will also not talk about “artists”, “songs” or “tracks” unless it is technically accurate to do so. In the world of classical music, we have composers, works, pieces, movements and so on. CCDR uses this sort of terminology.
One other feature I'll mention which I think is more appropriate to classical music than any other type: quite often, we rip works which are supplied on multiple CDs. Think of Götterdämmerung, for example, which is usually supplied as a 4-CD boxed set. A lot of other rippers will regard the CD as the atomic unit of data. They will, therefore, tend to rip each CD with its tracks starting at '1'. But in the world of classical music, we only care that there's one 'opera' and we want its individual tracks numbered sequentially from beginning to end, no matter what CD they happen to have been supplied on. So, CCDR will allow you to specify a 'track ofset' when ripping CD2 of the boxed set so that its tracks will follow on sequentially from wherever CD1 got to; repeat with different and ever-incrementing offsets for the third and subsequent CDs in a set.
Of course you can. CCDR's features are certainly tailored to those interested in classical music, but they can be used equally well by someone who enjoys all sorts of non-classical music. The program won't throw fatal errors the minute it sees a Michael Buble, Tony Bennet or Ariana Grande CD, for example!
Metadata is simply “data about data”. In other words, the data you're actually interested in, in this context, is the audio contained within a digitized FLAC file. Put even more simply, the data we care about is music. But metadata describes this music. It tells us, for example, that it's by Beethoven or Mozart; that it's a concerto not a symphony; that Colin Davis is conducting, not Simon Rattle. And so on.
In the world of digital audio, this 'data describing the music' is stored within the audio file itself, in specially reserved sectors of the file, called 'tags'. There are separate tags for each piece of metadata. There is, for example, a 'Composer' tag, a 'Track Number' tag, an 'Album Name' tag and a 'Track Title' tag… and many others.
For a music collection to be easily navigable, readily understandable and delightfully playable, the metadata within your digital music files needs to be accurate, precise and consistent. It's no good, for example, labelling 'Beethoven' as the composer of Symphony No. 5 one minute and 'Ludwig van Beethoven' as the composer of Symphony No. 6 the next: “B” is nowhere near “L” in the alphabet. Sort your music by composer name, therefore, and the two symphonies will be miles apart, with one near the top of the list and the other buried in the middle.
In non-classical music, the tags can generally be a bit more relaxed, in the sense that if you are a fan of Paul McCartney, you're going to have music by him filed under 'B' (for Beatles) one minute, 'W' (for Wings) the next and 'P' (for Paul) the other. Beethoven tended not to change 'artist name' quite so frequently, though!
Correct and precise metadata is vitally important when you are dealing with classical music in a way it isn't quite for other types of music, because classical music collections are sorted and organised in precise ways which bad metadata will prevent working properly.
Because it's always rubbish. Here, for example, is what abcde makes of a 2002 recording of William Walton's Belshazzar's Feast (which happens to be paired with Ralph Vaughan Williams' Job):
Retrieving 1 CDDB match...done. ---- Various Artists / Walton & Vaughan Williams ---- 1: Thus Spake Isaiah 2: If I Forget Thee, O Jerusalem
Well, it found a match, which is nice. But left to its own devices (as a lot of other rippers give you little choice about), it would tag these music tracks as being by someone called “Various Artists”. Store that on disk and let a media player catalogue and play it and you'll end up with this:
Note how the window title bar displays “Various Artists - And In That Same Hour”. It's (a) not very informative and (b) violates most rules of English grammar I can think of: capitalising words like 'in', 'that' and 'same' is an odd understanding of the basic rules of capitalisation, it seems to me! Meanwhile, in the main body of the player, the artist is declared to be 'Various Artists' and the piece of music I'm playing is just 'Walton & Vaughan Williams'… not a whisper that this might be a part of Belshazzar's Feast, then!
In short, it's all horribly wrong, vague, mis-typed, mis-spelled, inconsistent rubbish …and is therefore frankly not worth fetching in the first place.
To be fair, abcde does offer you a chance to edit the metadata: but in a command-line text editor which (by default is vi-based!), that's easier said than done. Even on a good day, in nano, you are asked to edit this sort of data:
# 340815 # # Disc length: 4753 # # Revision: 1 # Processed by: cddbd v1.5.2PL0 Copyright (c) Steve Scherf et al. # Submitted via: fre:ac v1.0.17 # DISCID=33128f15 DTITLE=Various Artists / Walton & Vaughan Williams DYEAR=2002 DGENRE=Classical TTITLE0=Thus Spake Isaiah TTITLE1=If I Forget Thee, O Jerusalem TTITLE2=Babylon Was A Great City TTITLE3=Praise Ye
Is it obvious from that lot that something labelled DTITLE is likely to become both the 'album name' and the artist? Where do you set 'Composer', for example? Again, not obvious. So, editing that which has been fetched from the Internet is not something that's trivially done, even when the ripping program gives you an opportunity to do it.
The short version is, therefore: I think it's better to start clean, have the ripper add bare-minimum metadata of your own choosing and afterwards use other, third-party, GUI tools to set everything else correctly.
Quite a bit; in fact, nearly everything you would need to make sense of the music in most music player/managers, except for the track titles (which need setting after the rip, using whatever tagging software you prefer). We don't bother setting esoteric information like the recording engineer or the key of the work, though!
You are asked 4 questions about the musical work on the CD that's being ripped: it's name, who its composer is, what year it was recorded and what musical genre it belongs to. The name you type in becomes both the “Album” tag and the sub-directory of your Music folder within which the ripped audio tracks will be stored.
When you supply a composer name, that becomes the “Artist”, “Album Artist”, “Composer”, “Original Artist” tags: the same value, as typed by you, is set for all four. You will need to add details such as orchestra, conductor, principle soloists and so on in the 'Comments' tag field manually afterwards.
Track numbers are set automatically, though you are allowed to specify a 'track offset' by which physical track 1 (say) becomes labelled as ripped track 15 (or whatever other number you choose).
The question about genre is used to populate the “Genre” tag. It should be things like 'Concerto', 'Orchestral', 'Opera', 'Vocal' and so on -though, naturally, any free-form text is actually permitted.
The “Encoded By” tag is also set to indicate that CCDR was used as the ripping tool (I needed a way to tell which bits of my own collection had been ripped accurately by CCDR versus those bits which hadn't).
Naturally, you are only asked the questions about piece name, composer and so on once -which could be considered a problem if you've got a CD with multiple works by different composers. In that case, however, you can choose to select only some of the tracks on the CD to be ripped; the answers to the questions you supply can be correct for just those tracks. Then you can choose to not eject the CD at the end of that rip, and re-run CCDR to rip the other tracks with different answers to the questions that are now appropriate for the second set of tracks to be ripped. Keep re-ripping different parts of the CD with different answers supplied until the entire CD is ripped -and for the last ripping run, choose to eject the CD when finished.
The subject of tagging digital audio files can get rather complicated!
If you create (lossy) MP3 files, you are supposed to tag them with “ID3” tags. If you create (lossy) Ogg Vorbis files, you are instead supposed to tag them with “Vorbis” tags. And when you create (lossless) FLAC files, you are supposed to tag them with… Vorbis tags.
Where it starts getting tricky is that there are various versions of ID3 tags: ID3v1 only allowed a few, very short tags. ID3v2 allowed lots more, variable-length tags. And then there are different versions of the ID3v2 standard, to boot! Different media players can read different types of ID3 tags (and not read others, if you happen to get really unlucky!)
And to pile on the confusion, whilst FLAC files are supposed to be tagged with Vorbis tags, they can simultaneously store ID3 tags… and when a single FLAC files stores both types of tag, it's mostly pot-luck as to which ones a particular media player will choose to read and display.
Since CCDR only ever outputs FLAC files, it only tags files with the Vorbis tags. This makes it a well-behaved FLAC-using application, doing things “properly”. Unfortunately, those media players or other tools that are coded only to work with ID3 tags will therefore regard your files as completely un-tagged. But that's their problem, not yours (and is easily rectified by getting a better media player!)
Well, first: it's optional to supply a track offset.
If you do provide one, though, it is simply added (or subtracted) to the track number actually recorded on the CD.
As an example: Leoš Janáček's opera Jenůfa is supplied (in my Mackerras recording from 1983) on 2 CDs. CD 1 consists of 13 tracks, CD 2 has another 15 -of which the last is actually the standalone overture Žarlivost, and so not technically part of the opera at all.
When I rip the first CD, everything is fine: all 13 tracks belong to the opera and start from track 1, incrementing steadily to track 13. For ripping this CD, there is no need to supply a track offset at all.
But when I rip the second CD, I don't want its first track to be numbered '1', but '14', since it's the 14th track of the opera, regardless of being the first track of the second CD. When I rip this CD, therefore, I will ask for a track offset of 13. CCDR will then add that number to the physical track number, and thus physical track 1 will become ripped track 14. Physical track 2 will similarly become ripped track 15 and so on: basically, all tracks on the second CD will have their physical track numbers augmented by '+13', the supplied track offset number.
However, only 14 of the 15 tracks on this second CD actually belong to the opera. The 15th is a standalone overture derived from it. It shouldn't be included in the Jenůfa “album”, but be stored separately and numbered uniquely, too.
So, in fact, when I rip the second CD of the set, I would choose to supply a track range of 1-14 to rip, as well as a track offset of 13. That then gets all of Jenůfa ripped correctly, as one 'work' and with continually-ascending track numbers from 1 to 27.
I'd then perform a second rip of the second CD, specifying to rip only the last track on that CD (track 15), but supplying a track offset of -14 (i.e., negative 14). As before, CCDR just adds the physical track number to the supplied track offset, and since 15 + -14 = 1, this one-track rip to a work called Žarlivost will become track number 1 of a brand-new 'album'.
In short, physical track number + offset = ripped track number. And we can play with this equation with both positive and negative numbers supplied as the offset to either join tracks from multiple CDs into one work, or to take just part of a single CD and declare it to be a work of its own whose tracks correctly start at '1'.
Leaving the offset blank (i.e., just pressing Enter) is the same as typing in an offset of zero: both mean “I am happy to have the physical CD's track number become the ripped track's track number.
CDs often contain many separate works on the one physical disk. For example, it's quite common to see Beethoven symphonies 'paired' on a CD, so you'll get Symphony No. 1 and 2 on the one CD.
The fact that the two works are on one CD is irrelevant though, when it comes to digitizing the music: you will want Symphony No. 1 and Symphony No. 2 ripped as entirely separate works, no matter that they came supplied on the same medium.
Partial disk ripping gives you the chance to separate out the multiple works you find on a single CD. You can rip a single track, for example, simply by typing in a specific track number. Type 8, for example, and only the 8th track on a CD will be ripped. If you want to rip multiple contiguous tracks, but not the entire CD, simply supply a range of tracks when prompted, such as 5-8.
When typing a range, don't put any spaces in. Just separate the first and last tracks with a minus sign/hyphen.
Unfortunately, we can't rip multiple, non-contiguous tracks (so typing something like “4,7,11” would generate an error, for example).
Classical CD Ripper requires the following applications to be installed before it will work:
Many of those are standard parts of any Linux installation and I'd be surprised if they weren't already present (awk, grep and so on). But if any of them are not present when you first run CCDR, you will be told. It's then up to you to install the particular applications using whatever tools your distro gives you. For example, to install ffmpeg on OpenSuse 15, you type sudo zypper install ffmpeg. On Ubuntu, it would be sudo apt install ffmpeg, and so on.
I used OpenSuse 15 as my principal desktop O/S, so CCDR was written on that and tested extensively on it. It's also been tested on virtual machines running Ubuntu 18.04 (using the Gnome desktop) and Fedora 29 (using XFCE):
I've lately switched to using Debian Testing as my main desktop O/S, so I've recently re-worked CCDR to run on that without issue, too (Debian deprecated cdrecord -one of CCDR's dependencies- a long time ago and uses wodim, a fork of it, instead. Therefore, CCDR on Debian now checks for the presence of wodim and prompts for its install if it can't find it).
It should work on pretty much any disto, but if it fails to do so on a specific one, please email me at [email protected] with full details about your O/S of choice and I'll see what I can do about it.
Because I don't want to prescribe a specific way of doing it knowing as I do that it's done differently in different distros. I do try to detect what distro you're using and suggest a single one-liner command that will install all necessary software, but actually performing the installation would require CCDR to know a lot more about different distros and their inner workings than I have time to supply!
If you're digitising classical music on Linux, I take it you're reasonably smart and can work out how to install the software you need all by yourself, basically! The installation command CCDR suggests you use is exactly that: a suggestion to point you in the right direction but with no guarantees that it will actually work as-written!
Well, first thing to say is that you don't have to output the hashes if you don't want to. But if you do, they give you a value which basically sums up the audio content of the track involved. I stress “audio content”, because the hash number calculated for a track will not change just because you tag it or add a bit of CD cover art to it.
[email protected]:~> cd Music/Belshazzar\'s\ Feast/ [email protected]:~/Music/Belshazzar's Feast> ls hashes.txt track8.flac [email protected]:~/Music/Belshazzar's Feast> cat hashes.txt track8.flac -> MD5=9a9c18e3482a1e6c501e4618eebb3436
This shows you I've ripped track 8 of a CD and it has a hash value of “9a9c…”. Now, let me modify the file:
[email protected]:~/Music/Belshazzar's Feast> id3v2 -a "Benjamin Britten" track8.flac
That means I've just set the Artist tag for that track to “Benjamin Britten” (and yes, I've used ID3 tags for these examples, which is something you definitely shouldn't be doing yourself, but it's less verbose than doing it properly with metaflac and therefore makes for easier reading here). Now:
[email protected]:~/Music/Belshazzar's Feast> ffmpeg -i track8.flac -map 0:a -f md5 -
That's me calculating the MD5 hash for the track in question. A lot of output is generated, embedded within which is:
ffmpeg version 3.4.4 Copyright (c) 2000-2018 the FFmpeg developers Metadata: encoder : Lavc57.107.100 pcm_s16le MD5=9a9c18e3482a1e6c501e4618eebb3436
So, the MD5 hash is still “9a9c….”, as before. One final test:
[email protected]:~/Music/Belshazzar's Feast> id3v2 -a "William Walton" track8.flac
This time, I'm setting the Artist tag back to “William Walton”, and the effect on the MD5 hash is:
[email protected]:~/Music/Belshazzar's Feast> ffmpeg -i track8.flac -map 0:a -f md5 - Metadata: encoder : Lavc57.107.100 pcm_s16le MD5=9a9c18e3482a1e6c501e4618eebb3436
So the hash remains invariant, regardless of what you do to the metadata within the file. That means the MD5 hash is a computation based purely on the music signal within a file and nothing else. Accordingly, you could rip the same CD on a different PC with a completely different CD or DVD drive -if the hash on that PC matches the value you got when you ripped it on the first, you can be confident that the audio signal for a track is not being altered depending on which PC or CD/DVD drive is doing the ripping -and that means you can be reasonably confident that your rip is a true and faithful replica of the audio supplied on the original CD.
Those come from Cdparanoia, the ripping engine, and a full description of them can be found on Cdparanoia's home page. The brief version is, however, that you want to see :-) whilst a track is being ripped -it means no error was detected during the rip. You also want to see :^D when ripping a track has finished: again, it means 'no errors'.
Apart from those 'smileys', you also see a display of track-ripping progress:
The area between the two square brackets indicate track progress: if you see X, * or ! in that area of the display, it means Cdparanoia detected a scratch or other problem when reading that part of a track. That's not good, though Cdparanoia will attempt to correct or read-around the problem. A lot of times, it will be successful in doing so.
In the screenshot above, however, you see what you want to see: nothing except a '>' symbol indicating progress!
All feature requests (or bug reports, come to that) are welcome. Just email me, Howard Rogers, at [email protected]