Category: classical music

This is the last in my series of three posts explaining what I’ve done to fix up a silly cataloguing error in my extensive music library. The problem was first described back here. But to recap: whilst I have always “allowed” the inclusion of a recording year in the ALBUM tag where it was necessary (to distinguish, for example, between Boult’s 1959 and 1968 recordings of Vaughan Williams’ 9th symphony), I only added the recording date rarely, and as an exception to the norm. Rethinking the logic of what counts as recorded music’s primary key, however, I realised that the recording date should always and without exception be included in a recording’s ALBUM tag.

So, the past few posts have been about the scripts I wrote to (a) check every recording had a recording year stored in its YEAR tag; (b) to check that those recordings that had a date included in their ALBUM tag matched there what their YEAR tag said should apply as the recording date.

In this last installment, I now have two things to do: i) for those recordings that don’t already have a recording year in their ALBUM tag, I need to put it there. And ii), since it is an axiom of mine that the physical storage structures of my music library should mirror its logical organisation, if my ALBUM tag gets changed to include a recording year, the physical folder containing that recording should also be re-named to include a recording year. And, given the 60,000+ music files involved, all of that has to be done entirely automatically, using scripts!

So. Eyes down for a tricky one (because this last stage of fixing things is the most complex and awkward to accomplish)! Here’s the script I wrote to achieve the necessary outcome:

    1  #!/bin/bash 
    2  # Clear up previous runs 
    3  rm -f /home/hjr/Desktop/renamealbums.txt 2> /dev/null 
    4  rm -f /home/hjr/Desktop/renamealbums.sh 2> /dev/null 
       
    5  # Initialise a counter 

So, this is the next in a mini-series of posts, explaining how I went about fixing up the discovery that I’d tagged my music files incorrectly after all these years, despite knowing better!

The short version is that I always knew the recording date was an important factor in distinguishing between recordings of the same work by the same artist, but since I didn’t often have duplicates, I assumed I’d get away without including it in the ALBUM tag for a composition. And then I realised that though I might well get away with it today, a new acquisition here or there could well mean that I wouldn’t get away with it for ever: if the information is theoretically necessary to distinguish recordings, then it ought to be present, always.

Thus, I needed to go back to my music library and make sure that the recording date was present in the YEAR tag, which was designed for it. How I did that was the subject of my last post.

But a recording date stored in the YEAR tag isn’t actually functionally useful for distinguishing between two recordings of the same work. That’s because most music players will order and group recordings by what they call “Artist” and “Album Name” -which are the ALBUM and ARTIST tags in a FLAC file. If the recording date is stored in the YEAR tag, that’s fine, but it won’t usually be used from there to sort and group music properly. In other words, having made sure that I actually had a YEAR tag for every recording, my next task was to bring that YEAR data up into the ALBUM tag, where it could actually be useful.

I’ll just pause at this point to say that I’m really doing something at this point which I’d much rather not have to do: namely, repeating information already stored in one place in a second place. There’s a reason for not liking to do this: the two pieces of information are physically independent of each other and there’s no intrinsic mechanism in the audio player world to make sure they stay identical. That is, I might have an opera called Peter Grimes which was recorded in 1958. I could set YEAR=1958, and ALBUM=Peter Grimes – 1993 …and nothing can stop me now having two completely different recording dates associated with the same recording. You are then in the position of not really knowing whether one is right and one is wrong, nor which one is right or wrong -or whether both are as bad as each other! In strict database practise and theory we avoid duplicating information like this precisely because it makes data maintenance so tricky for the future.

On this occasion, however, I don’t have a lot of choice. The fundamental piece of data every music player sorts and groups by is ALBUM. If the recording year is not present in that, then it functionally cannot help to distinguish between different recordings of the same work by the same performer. So practically trumps strict theory on this occasion -but it’s still a good rule to bear in mind in general, which is why it’s such a good idea to not include the ALBUM data in your track TITLE tag, for example.

Anyway: that’s the purpose of this post. Now that I know all my recordings have a YEAR tag, I want to make sure that I haven’t ever included the recording year in the ALBUM tag… and used a different date when doing so. If YEAR=1958 and ALBUM says “Peter Grimes 1969”, I want to know that 1958 doesn’t equal 1969. I’ll have to make a manual decision about what to do, and how to fix, any discrepancies found -but the job at hand is to find any discrepancies that do exist.

As always, I’m after a script that will check my entire music library in either one huge go, or in whatever smaller chunks I feel like running from time to time. And here’s the script I came up with to do the job:

    1  #!/bin/bash 
    2  # Clear up previous runs 
    3  rm -f /home/hjr/Desktop/freshdatacheck.txt 2> /dev/null 
       
    4  # Initialise some counters:  
    5  # i=count of records processed 
    6  # b=count of records where YEAR is present in ALBUM, but it's the wrong one (i.e. "bad records") 
    7  # g=count of records where YEAR is present in ALBUM, and it's the right one (i.e. "good records")  
    8

My last post explained that my music collection needed to be re-catalogued to some extent. In particular, I needed to make sure that every track I’ve ever ripped has an entry in its YEAR tag, identifying when a particular recording was made (because that little piece of information turns out to be a crucial component in classical music recordings’ “primary key“)

I wasn’t going to check all 64,000+ ripped audio tracks by hand to achieve this! Instead, I needed to script something that could batch-check my entire collection in one go.

Here’s the bash script I ended up writing to do that:

 

    1  #!/bin/bash 
    2  clear 
       
    3  # Clear up previous runs 
    4  rm -f /home/hjr/Desktop/missingdates.txt 2> /dev/null 
    5  rm -f /home/hjr/Desktop/fixmissingdates.txt 2> /dev/null 
    6

I was in discussion with some people on a Classical music forum recently. Topic of discussion: yet again, the issue of how you go about tagging your music collection so that it works efficiently and in a scalable manner to achieve good music discovery and access. Of course, I long ago decided I had the correct approach to that!

Anyway, the discussion did what it usually does: when push comes to shove, two of the people declaring my proposals unworkable turn out not to bother with tagging music

Having begun the process of re-cataloguing my collection of Mozart music just before Christmas (see the previous blog post), I thought it about time I posted a bit of a progress report. Naturally, what began as merely an exercise in re-naming things (for example, ‘Requiem, K626’ would become ‘DZ 02082 Requiem’ using the new Dizwell numbering scheme), rapidly became a full-on musicological cataloguing