May has been a month of progress on something I made a New Year's resolution to do (but then put off for four months!): catalogue the enormous pile of ripped CD files I've built up over the past year or so. Click on the graph at the left and you'll see how I've done: I started the month with 485.1GB of music files sitting in the 'temporary' area of my hard disk (which has been pretty permanent for at least 2 years now!), in the form of 10,007 individual FLAC files. As of this afternoon, I'm down to 13.6GB and just 625 files. Most of that is a 'collected works of Messiaen' box set, which will take ages to catalogue and tag-up properly, because French is slow to type, what with all its accents (but maybe not as slow as German. And definitely way faster than Czech!)
Undertaking all this cataloguing has meant using my own CCDT tagging program, of course. As a result, I decided to make a couple of little changes to CCDT. The important one is a new run-time switch, called --namereplace. Run CCDT with that in the launching command and CCDT changes the way it handles music files that already have a track title tag.
When it comes to adding a TITLE tag, there are really only two possible situations: (1) the track has no existing TITLE; or (2) the track has an existing title. In the case of situation (2), CCDT has always spotted the existing tag and asked you if you want to replace it, like so:
As you can see, it displays the existing title and asks if you want to update or alter it. If you do (and it turns out that tag data supplied by the likes of Chandos and Naxos is almost as bad as you can obtain from the CCDB online music database, so you often do!), you have to type 'Y' to say you want to change it and then you can type the new data. That's not a bad approach, if you are tagging up maybe 10 files downloaded from one of the record companies.
But doing it 10,007 times is a royal pain in the butt! Given that existing tags are often likely to need correcting, asking if you want to every time just slows things down badly. I also discovered that I got into the habit of typing 'Y' in response to that question so that I started to type 'Y' instinctively, even when a music file had no existing tag (i.e., for situation (1) as well)... and that meant I ended up with an awful lot of TITLE tags set to just 'y'! That naturally required me to go through the track title naming process a second time in order to correct my mistake: and that was slowing me down, too! All in all, the existing CCDT workflow was fine for single CD rips, but lousy when it came to doing tagging jobs in bulk.
So, now, starting from version 3.14, you can launch CCDT like so:
ccdt --namereplace
...and that alters the track title naming function like so:
As you see, the new switch changes the behaviour of the program so that it asssumes you will want to change the existing tag data. It still displays the existing tag data (in blue), but you are immediately put at a prompt where you can start typing the correct TITLE tag. If it happens that the existing data is (somewhat miraculously!) already correct, you can just press [Enter] and the existing tag is preserved. Put simply, the new runtime option sort-of reverses 'the burden of proof': it behaves as though you will want to change the data, but gives you an option to not do so, whereas the previous and default behaviour was to be unsure whether you'd want to alter the existing data and to ask you -every damn time!- if you do or don't want to altter it.
Incidentally, this is not entirely new behaviour: from the earliest days of CCDT, you've been able to set an environment variable called CCDT_AUTORETITLE. Set it to a value of TRUE and CCDT would then assume you wanted to supply new track names... but, in doing so, it would not display any existing data. In other words, issue this command:
export CCDT_AUTORETITLE=TRUE
...then run CCDT with the bare command
ccdt
....and you'd see this track naming behaviour:
See how the program immediately asks you to supply a new track title... but doesn't even bother to display the existing one? It certainly displays the physical file name (in yellow), but there's no display of the existing TITLE tag data (which usually these days should appear in blue). The assumption here, therefore, is that if you've agreed to 'auto-retitle' by setting the relevant environment variable, the existing data is clearly rubbish, so why would you ever want to see it?
Well, 10000-tagging operations in the last few weeks has taught me that it's actually useful to have a 'middle way': by all means assume the existing data is rubbish and that I'll therefore want to alter it, but at least show me what it is anyway. Here's a good example of why that 'middle way' is so helpful:
The record company has tagged the title of this track with a combination of the ALBUM and TITLE tags, all mushed up together. My tagging standard is: the ALBUM goes one place and the TITLE is therefore strictly and only for the title of the track in question. So in this case, I'd want to change the supplied data to just 'Introduction'. The new --namereplace function is here displaying the original, rubbish tag data in blue -and I can immediately see that I should supply the new title as 'Introduction', because I can actually see it there in the original data, on-screen, right in front of me! It saves me having to check things up in the CD booklet, basically... another massive time-saver.
So you now basically have three choices: (1) don't do anything and let CCDT prompt you every time to see if you want to change an existing track title; (2) set CCDT_AUTORETITLE and have CCDT assume you want to supply new track titles, but starting from a completely blank slate, with no clue provided about what the existing data is; or (3) run CCDT with --namereplace and have CCDT assume you want to supply new track titles, but display the existing data, so you can use it if you need to.
Personally, I think CCDT_AUTORETITLE is basically rendered a bit redundant by --namereplace: the new switch provides much the same functionality as the old environment variable, but it does it more flexibly and with better functionality. But I've chosen not to remove the old environment variable option, for backwards compatibility reasons. From my three weeks of tagging like a madman, too, I am fairly confident that in a future release of CCDT I may reverse the default: that is, have the namereplace functionality be the default behaviour, and require a 'nonamereplace' switch (or whatever we decide to call it) to revert it to the current default of prompting you each time... but I've decided not to do that just yet. Since what amounts to a 'quick retag' feature is now one command-line switch away anyway, I don't think changing default behaviour is really necessary at this stage!
Anyway: I have another 13.6GB of FLACs to tag-up, so if you'll excuse me, I'll be busy breaking my keyboard (and fingers!) in the other room!