Ripping 1 CD containing multiple compositions by 1 Composer on Linux

1.0 Introduction

This is the third article in my series showing how I would suggest you go about the business of ripping and tagging different CDs of varying configurations. Previously, I've discussed:

In this article, I'm going to tackle the next logical extension to these scenarios: one CD, containing multiple compositions by a single composer. In particular, I'm going to discuss how to rip this album:

According to Discogs, the CD contains the following music:

...which potentially means we're looking at up to 13 different compositions by Thomas Tallis -and therefore, possibly, 13 different albums? Well... let's think about that a bit more first...

2.0 What's an Album?

That 'table of contents' for the CD in question is really rather important to read, carefully. And as you read it, I want to emphasize that there is no right answer to the question I'm about to pose: namely, what is or are the albums here?

  • Scenario One: You could regard the entire CD as a single collection of Tallis sacred music (perhaps you'd call it 'Sacred Music', rather than 'Spem in Alium Lamentations of Jeremiah Motets' as the CD cover has it, on the grounds that brevity is best?
  • Scenario Two: If you look at the track timings, it's pretty clear that Spem in Alium is a signficiant work of composition in its own right (practically 14 minutes long). So are the two parts of the Lamentations of Jeremiah (each at least 8 minutes long, but over 20 minutes when combined). However, almost every other track is quite short: a maximum of 4-and-a-bit-minutes for track 8, but around the 2 minute mark for nearly everything else. Those times are all under the 4 or 5 minute mark mentioned in Axiom 4. Despite undoubtedly being glorious pieces of music, therefore, perhaps all those short tracks don't deserve to be regarded as standalone 'albums' in their own right. This scenario thus seeing us turn this CD into three separate 'virtual' albums: one called 'Spem in Alium'; another called 'Lamentations of Jeremiah'; and everything else making up one we could call 'Sacred Music' or something similarly descriptive.
  • Scenario Three: A strict interpretation of Axiom 1 is that the it doesn't matter that 13 choral works by Tallis are included on one CD: these are all individual choral compositions by a major composer and therefore deserve to be recognised as separate 'albums', no matter their length. Every track therefore gets ripped as a separate album, with such names as 'God grant we grace', 'Spem in Alium', 'Hear the voice and prayer of Thy servant' and so on. Since tracks 6 and 7 clearly belong together, we'd end up with 12 distinct 'virtual albums'.

Now, having said that there's no right or wrong answer as to what scenario we should adopt when confronted with this CD, I would definitely want to reject Scenario One: Spem in Alium is an absolute masterpiece and definitely does not deserve to be buried within what would effectively become a compilation album of 'Tallis' Greatest Hits'! It most certainly deserves to stand alone as an independent 'album', even if nothing else does. Though even a brief acquaintance with Renaissance English Church Music makes one swiftly realise that the Lamentations are equally deserving of separate treatment. So that puts me definitely in the Scenario Two or Three camps.

Now, when I began writing this article, I was convinced that Scenario Two would have been the one I adopted many years ago when I first ripped this CD to my permanent collection. But it turns out memory is fallible and I was wrong: sometime in the 2000s, I apparently decided to adopt Scenario Three, as my current music library attests:

I was clearly a strict adherent to Axiom 1 back in the day! With the benefit of 20:20 hindsight and an ever-increasing propensity to avoid typing too much, however, I think now I would adopt Scenario Two... and that's the one I'm going to document in the rest of this article. Spem in Alium and Lamentations as separate 'virtual albums', everything else lumped together into a 'Sacred Music' album. If, confronted with the same track list, you were to choose to adopt one of the other scenarios, I wouldn't fight you about it! It's a judgment call, and your judgment may well be different from mine ...and in any case change as the years pass.

Anyway: on with the Scenario Two ripping...

3.0 The Rips

If you've worked through the previous examples in this series, you will know that CCDR can rip whole CDs or parts of CDs equally well, provided that when you rip parts of a CD, the parts are contiguous. So, to rip Spem in Alium as an individual, standalone virtual album, we could run CCDR to extract just track 2 perfectly well. We could also extract tracks 6 and 7 to create a Lamentations virtual album easily, too. But to create this scenario's 'Tallis Sacred Music' virtual CD, we'd have to rip tracks 1, 3, 4, 5, 8 to 13... and those are non-contiguous track selections. CCDR cannot, therefore, create this third 'album' in a single rip, though it could do it as 3 separate rips (just track 1; then tracks 3-5; finally tracks 8-13).

With that theory in mind, therefore, we can begin to rip the CD into its component 'works'. The order in which we create the three virtual albums doesn't really matter. I'm going to start, however, with the creation of the 'Tallis Sacred Music' album, because that's the one which works in perhaps a more surprising way than you are already familiar with. To start, therefore, just insert the CD into your chosen optical drive, then open a fresh terminal session and type the command ccdr:

In a way that should now be familiar, you are asked to confirm which optical drive to use. If you are happy to re-use the drive you've used before, just press [Enter] to proceed (if not, press Ctrl+C to quit the program and re-launch it using the -d= or --device= run-time switches to direct it to use a different optical drive). You are then prompted to supply information of album-wide significance and some track-specific options. Here's how I went about answering those questions:

Remember what the ultimate goal here is: it's to create a virtual album of 'Tallis' Sacred Motets' that contains tracks 1, 3, 4, 5, 8, 9, 10, 11, 12 and 13 from the source CD. Since we cannot select non-contiguous track ranges to rip in one go, however, I'm starting by only ripping the first of those tracks. Since it's already physically track 1 on the CD, I don't need it to have it's track number on the hard disk adjusted, so I've not supplied a track offset. The album-specific information is mostly provided from the details provided by the CD's booklet -though I've had to make up the composition name, since I'm obviously 'constructing' one out of separate, short choral works and thus wasn't ever thought of as a named composition by Tallis back in the sixteenth century! Note, finally, that I've asked for the CD not to be ejected at the end of this rip.

Pressing [Enter] at the end of that set of questions causes physical track 1 to be ripped to hard disk. The process completes swiftly enough (because it's a short work) and I get dumped to the operating system's command prompt at the end of it:

So you can see that track 1 ripped perfectly (because there's a :^D smiley at the end of the progress line for that rip). You can also see that once I get dumped back at the command prompt, I simply launch ccdr again! This will be the "second pass" in which I nab tracks 3, 4 and 5 to become the 2nd, 3rd  and 4th tracks of my 'Sacred Motets' virtual album:

Notice in this screenshot how I don't need to re-type any of the album-wide information again: since the composer, album name, performers, genre and recording date are all the same, I can accept the answers supplied during my first rip which are shown within square brackets. I do so simply by pressing [Enter] for every question, which is handy and fast! A new question is asked after this, however: since the album name and performers haven't changed, the directory into which the new tracks will be ripped will be the same as the one already used for track 1... am I happy to re-rip into the same folder? I answer 'y' at this point and a big, red confirmation message appears to make sure I know where my new rips are going to end up.

Just think about that for a bit, though. If I were to rip another track into the same directory and tried to make it track 1, then the new track 1 would over-write the one obtained during the 'first pass rip'. Re-using the same folder can be risky, in other words, if you don't make sure that the fresh rips use completely different track numbers than before. This is why you can see me carefully selecting tracks 3 to 5 to be ripped as my 'second pass rip' and then asking for a track offset of -1 to be applied to them. Why -1? Because that will make CD track 3 become hard disk track 2, and CD track 4 become hard disk track 3 and so on. No new hard disk track numbers would conflict with any files already present on disk from the first rip, so all will be fine. If I'd asked to use a track offset of -2, however, then the second-pass track 1 would simply over-write the first-pass track 1, and the first-pass rip would effectively never have happened.

In short: learn to use the track range and offset prompts to best effect, and be careful to think logically about what you're doing so that new rips don't obliterate the work of previous rips. The onus is on you to get that right!

Here's the result of my second-pass rip:

You can see that CD tracks 3, 4 and were each ripped toward the top of this screen, but lower down, they have become 'track02', 'track03' and 'track04': that's the track offset of -1 kicking in. But you'll also notice that the final FLAC consistency check is applied to all the tracks which are found in the rip destination folder, so track01 gets included in that final check too. This does at least give you re-assurance that, at this stage in proceedings, there are four audio files on hard disk, not just three: no silent over-writing has taken place!

As before, the end of the second-pass rip dumps you back at the command prompt... where you can immediately type ccdr one more time to start the third-pass rip:

Notice in this screenshot how CCDR's ability to remember the results of the previous rip (and show them to you within the square bracket parts of each question) means you can do second and subsequent rips with hardly any typing at all. Here, I've been able to press [Enter] six times to accept previous answers or the default response to prompts before I have to do any real typing at all. Only when I have to specify which tracks of the CD should be ripped do I need to actually type something. In this case, of course, I know I want to rip tracks 8 to 13 as one contiguous whole. I also need the first track of this rip to become the 5th track of my 'Sacred Motets' virtual album. Thus, I'm applying an offset of -3, so that CD track 8 becomes hard disk track 5.

After that, it's just a further set of pressing [Enter] to accept all the defaults and the third-pass rip begins:

Once again, you see the 8th to 13th tracks being ripped at the top of the output, but the entire set of 10 tracks being checked for internal consistency before proceedings come to an end. You will also note that our 'Sacred Motets' virtual album is now complete and contains 10 tracks, nicely numbered from 1 to 10, sequentially and in order.

At this point, I hope it's easy to see how you now rip the second and third 'virtual albums' from this one CD. Let's say that my next album will be the 'Lamentations' -which involves ripping tracks 6 and 7. I simply re-run ccdr one more time:

Once again, notice how little typing I have to do! The composer is the same as before; the performers are the same; the genre is the same; the recording year is the same. Only the 'virtual album name' needs to change from what I've specified previously. Therefore, I only have to type in 'Lamentations of Jeremiah' in that first batch of questions; for everything else, I just press [Enter]. The tracks to rip are, as expected, 6-7, specified as a contiguous range without any spaces between the numbers or the hyphen. This time, the track offset is -5, because I was CD track 6 to become hard disk track 1 (it's a new Album, remember; and all albums start at track 1!)

When that rip completes, you can then create the third and final virtual album, of Spem in Alium. Re-running CCDR for the final time, my responses are as follows:

Again, I have to supply a new 'album name', but everything else can be accepted from before, just by pressing [Enter]. The track number to rip is, of course, also unique and therefore I need to specify it -though this time, it's a single track, not a track range. I still need to apply an offset, though: since CD track 2 needs to become hard disk track 1, the offset in this case is -1. I have also no more tracks to rip from this CD after the Spem in Alium is safe on disk, so I've chosen to ask for the CD to be ejected from the optical drive at the end of this last rip.

Once that third rip completes successfully, I can close my terminal session down altogether and switch instead to my distro's file manager. Navigating to my $HOME/Music directory (to which CCDR automatically directs all its output, unless you configure it otherwise), I now see this:

So, you can see three distinct folders, one per 'virtual album', all stored within a Thomas Tallis/Choral folder/sub-folder combo. Add up the total number of FLAC files listed, and you'll find there's 13 of them... which just happens to agree with the number of tracks listed for this album on Discogs (and on the CD booklet, of course). We can be confident, therefore, that all tracks have been ripped off the CD, though it took multiple runs of CCDR to do it.

In particular, the 'Sacred Motets' album was tricky, because of CCDR's inability to rip non-consecutive track ranges. Though it's finally showing merely as a single virtual album, it took three separate runs of CCDR to create it, since track 1 was not contiguous with tracks 3-5; and tracks 3-5 were not contiguous with tracks 8 and onwards. Running the same program multiple times to achieve a single outcome may seem a weird way to proceed -but I hope I've shown you that CCDR's ability to remember the answers provided for previous runs means that the second and third rips that were needed to create the 'Sacred Motets' album didn't actually involve much typing at all.

4.0 The Post-Rip Tagging

CCDR has extracted the CD contents to our hard disk. The answers you gave to its questions have also enabled it to get a lot of the internal tags (the 'metadata' which describes the audio files) correct, too. For example, the answer to 'What is the name of this composition' has become part of the ALBUM tag; so has the answer to 'Who is the conductor or major performer' question: in that case, the answer was Pro Cantione Antiqua, so CCDR took the last component of that answer and stuck it in brackets, appending it to the 'name of composition' answer, resulting in an ALBUM tag which reads something like 'Spem in Alium (Antiqua)'.

But CCDR does not get all tags correct. It didn't ask you about individual tracks, for example -so there's no way for it to have created suitable TITLE tags.

Specifically, CCDR does not get the following important tags correct (or leaves them entirely blank):

  • Performers
  • Album Art
  • Track Names/Titles

To get those correct, we therefore need to launch CCDR's companion product, the Classical CD Tagger, or CCDT. As you know by now, from having read the earlier articles in this series, CCDT requires that you open a new terminal session, navigate to the directory containing the FLAC files you want to tag, and then launch the program from there. So let me start by tagging up the 'Sacred Motets' virtual album I created earlier:

As ever on Linux, directory names are case-sensitive, and if they contain spaces (or other special characters, such as opening and closing brackets), those have to be 'escaped' by prefixing them with a back-slash character. This makes typing long, complex paths with spaces and brackets a bit of a pain, to be honest... but remember that you can type the start of a folder name and then press the TAB key to get the shell to complete the name for you. Thus, in the above example, I typed cd /home/hjr/M and then pressed TAB. The shell supplied 'usic', not me. I then typed T <TAB> and the shell supplied "homas\ Tallis" for me, complete with the escape character. I similarly didn't type very much of the entire path at all; I got the shell to type most of it for me, having supplied initial letters only, for the most part.

Anyway, however you choose to do it, I've ended up in the Sacred Motets folder and I can therefore launch CCDT by typing the command ccdt:

The usual set of numbered menu options is then listed. From the earlier list of tags I said we needed to provide or correct, it should be apparent that we need to take, in turn, option 3, option 6 and option 8. You could take any of the other options if you liked, but you'd merely end up re-typing in tag data which you've already provided to CCDR, so there's no real point.

Here's me taking option 3 and spelling out who the performers of this music are, in much greater detail than CCDR allowed me:

As usual, I'm specifying things in conductor->orchestra->choir->soloists order, though in this case the conductor is really the 'director' of the choral ensemble and there isn't an orchestra... and there aren't any soloists either!

Next, I take option 6 and supply some album art:

Note that the program is suggesting another piece of album art, within the square brackets bit of the main prompt: CCDT remembers the last run it made and that must have been my answer then. It's not appropriate now, so I'm having to type in the full path and filename of the correct album art for these tracks, in yellow text.

Finally, I take option 8 and start supplying track titles:

CCDR did put a track title in this tag, so CCDT notices it and warns you what it knows is already present (in red). You can see that CCDR doesn't do very good or interesting TITLE tags! So, it's a 'y' response to the question about whether I want to replace what's already present, followed by appropriate track titles, typed in normal English capitalisation, Not The Sort Of Capitalisation That Discogs Proposes!! You have to do a bit of mental gymnastics at this point: you need to remember where this 'virtual albums' tracks came from on the original CD. Thus 'Sacred Motets Track 2' is actually the physical CD's track 3 and so on from there.

Updated to add (16th April, 2020) : Please note that CCDT has just been updated so that if it detects track titles in files which it knows to have been ripped by CCDR, it now will now not ask you if you want to edit or alter them, but will act as if the track title is blank. It will thus just ask you to supply a new track title and will auto-overwrite the generic title supplied by CCDR with whatever you supply. Given that CCDR's track titles are always 'generic' and meaningless, it seemed awkward to have to type 'y' every time you simply wanted to type a proper track title. The screenshot above shows the old behaviour of requiring a 'y' response to the 'do you want to update/alter' question.

Remember to quit CCDT cleanly when you're done tagging up the complete set of tracks -by pressing the 'q' option from the main menu:

Taking the 'quit' option causes all the FLAC files in that folder to be checked a final time for internal consistency and makes sure that all tags are written to the files in the correct order and format. You also get a nice visual confirmation that your physical files on disk have now been re-named according to the track TITLE tag you just supplied.

Once one virtual album has been tagged, you're dumped back at the terminal command prompt. You navigate from there to the next virtual album and tag it in exactly the same way, each time taking options 3, 6 and 8 in turn and typing in track titles when prompted. You will find that you don't have to type in the performers names or the path to the album art, though: CCDT will remember those values from your previous run and offer them to you as defaults which you can accept just by pressing [Enter]:

Here, for example, you see that as I attempt to say who the performers of the Lamentations are, I already have the correct answer proposed in the square brackets next to the question being posed. I can apply that answer to this new album's tracks, just by pressing [Enter]. The same will be true for the Album Art tag -but not for the track TITLE tag, since they are (by definition, really) always unique.

When you've finished applying tags to all three virtual albums, you can check your work back in your distro's file manager:

Each virtual album starts with track 1; each album name has a distinguishing artist in it, inside brackets; each has its tracks sequentially numbered; each can be seen to have embedded album art (the icon against each file is showing a tiny representation of the CD booklet front cover, rather than a generic 'musical notes' icon as previously). It all looks good from the perspective of the file manager; but is the music player/manager as happy?

Well, I think it probably is! The three 'albums' are listed distinctly from each other, though the now-prominent album art display makes it clear that all three share a common physical CD heritage. The tag display panel over on the bottom right-hand corner is also displaying the fact that ARTIST, TITLE, ALBUM, DATE, GENRE, COMPOSER and TRACK NUMBER fields have all been filled in correctly -so this is looking like a good set of correctly tagged and differentiated rips of multiple compositions from the one CD.

6.0 Conclusion

Using CCDR to rip multiple 'albums' from one CD is, perhaps, a little more complicated than it really ought to be! It's because CCDR does not handle ripping non-contiguous tracks in one rip. If there had been three symphonies on one CD, this rip would have gone a lot more smoothly, because you'd have been able to rip tracks 1-4 as Symphony No. 1, 5-8 as Symphony No. 2 and 9-12 as Symphony No. 3: three contiguous sets of tracks, three rip operations, three virtual albums, nice and simple.

When your track selections are non-contiguous, therefore, CCDR has to be invoked multiple times to achieve a single virtual album output. Fortunately, this isn't actually too difficult to do, because all the information about composer, album name, recording date and so on will be correct for the second and subsequent rips, after you've supplied them for the first. The only really tricky part of a multi-rip operation turns out to be your track selections and working out what track offsets are required to prevent a new rip over-writing tracks originally produced by an earlier one ...but that's just a little basic mathematics!

As ever, you also need to be familiar with using CCDT as a companion tool, post-rip, to fill in the three tag elements which CCDR either doesn't do at all (such as Album Art) or does inadequately (such as track titles). But in this scenario, using CCDT is really no different than we've experienced in any of the other articles in this series.

Fundamentally, therefore, the thing to get out of this article is the concept of running CCDR multiple times and using track selections and offsets to achieve a single virtual album output. It's possibly an unusual way of doing things... but the results, if you keep your wits about you, are self-evidently satisfactory.

Back to the Master Index of the Guides to Ripping and Tagging