Scarlatti In Bulk

Thanks to another recent video by David Hurwitz, I was finally persuaded to bite the bullet and splash out on the complete Domenico Scarlatti keyboard sonatas as performed by Scott Ross (the album artwork of which appears off to the left). It’s a 34-CD collection, available for purchase from Presto Classical at only around £2.50 a box, which seems reasonable value to me.

Curiously, this collection of works has previously been discussed by me in

Continue Reading

It’s not just Easytag… :(

In my last post, I pointed out the shenanigans that ensue when you use Easytag to update the metadata associated with your FLAC music files. Specifically, I demonstrated how Easytag will silently, and without the opportunity to configure the behaviour, change the name of a tag from COMMENT to DESCRIPTION.

When you then go on to use software which expects a tag to be called COMMENT, this causes problems!

Well, that chance

Continue Reading

Easytag Garbage Creation

I had been subsconsciously aware of a problem for quite a while, but had paid it no real attention: whenever I looked, a lot of my music files seemed to lack proper performer details! The tracks played fine and everything else about them seemed OK, but just no ‘conducted by, orchestra playing is, soprano singing is…’ stuff. I’d noticed it, in a casual sort of way, from time to time… but because you can live without knowing that particular information at your fingertips, I mostly just did.

I had also vaguely registered (erroneously, as it turns out!) that the problem was with a lot of music I remember buying in the 1990s and ripping in the early 2000s, so I put it down to sloppy tagging habits, waaay back before I knew any better. But it wasn’t and isn’t. It is a tale of software shenanigans and garbage programming that really kind of ticks me off, to be frank. So, first: let me show you the problem…

Here is the metadata associated with some Darius Milhaud music files:

You may be able to work out that there are 10 tags (the ‘canonical ten’) and one of them is ‘COMMENT=’ and that this particular tag has no value assigned to it. There is nothing showing on the right-hand side of that particular tag’s equals sign. This music therefore has no performer information associated with it!

Well, assigning data to canonical tags is what my very own CDDT software was designed to do, so let me use that to fix this lack-of-data problem:

So that’s me specifying the conductor and orchestra. If I save that data and re-check the metadata tags associated with these files:

So now, we have a COMMENT tag containing the relevant information. It’s currently showing as tag [10], but if I save this in CCDT and then re-load it into CCDT and re-display:

…you can see that CCDT tidies tags up as it saves them, so that the COMMENT tag is saved into ‘canonical position’ [7].

So, now that the data is safely in the COMMENT tag, let’s say that for some reason or other I opened up these music files in a graphical tag editor such as Easytag, a Linux-based tag editor I’ve been using for years to do quick-and-simple tag inspections and the occasional tag ‘touch-up’ when needed, for many years.

Something I’ve always noticed about Easytag at this point, and which you can see happening in that screenshot, is that whenever it opens any of my tagged music files, it has always emboldened their file names in the left-hand panel you see here. Now, it usually uses bold in that panel to indicate that ‘there are unsaved changes that have been made to these files’… but since I’ve literally just opened the files in the program and haven’t changed a thing, I’ve always assumed this to be a ‘quirk’ and nothing more. How wrong I was! As we shall see!!

Anyway, I’ve opened the files in Easytag, just to inspect the data and you can see that it’s all present as CCDT said it should be: the ‘Comment’ tag is there, nicely labelled ‘Comment’, too.

Now, I’ve seen what I needed to see and haven’t typed a thing, so I go to close Easytag down… and this happens:

That is, a pop-up appears warning you that there are unsaved changes and they’ll be lost if you don’t say to ‘Save’ them. Just press [Enter] at this point to make the pop-up go away (as I think a lot of users would tend to do!) and guess what: you’ve just taken the ‘Save’ option!

So let’s say you’ve hit [Enter] without thinking about it much. Let me now immediately re-inspect the files in my own CCDT program:

….and what do we notice? In ‘canonical position’ [7], we now see a tag called ‘DESCRIPTION’, not ‘COMMENT’. Without really telling us, or explaining why, Easytag has renamed the COMMENT tag so that it is now called DESCRIPTION.

Never mind that its own user interface calls this tag ‘Comment’ in its own right-hand pane. Under-the-hood, Easytag thinks it’s OK to change tag names -and the fact that it had changed them behind the scenes is why it displays the files in bold when they are first opened and declares that there are ‘unsaved changes’ when you go to close the program without having manually changed a thing.

Is the fact that a tag got silently renamed the end of the world? Well, not in-and-of itself, no. It’s not. The music file will play fine; it will display the composer, album and track names properly. Even the embedded album art remains safe. Indeed, even if you inspect the tags in another program, you won’t see any indication of a problem at all:

That’s the Clementine music player’s tag editor, being used to investigate the tags associated with the same music files as before. Note that it still displays the file as having a ‘Comment’, so it’s not particularly fazed by having a differently-named tag supplying the information it wants to display there. It’s reading something now called “DESCRIPTION” and displaying it in something called “Comment”, totally transparently and automatically.

This tells you that a lot of music players will quite happily play these files just fine; they’ll also (usually) allow you to search what is now your DESCRIPTION tag as effectively as they’d previously allow you to search your COMMENT tag. So, functionally, not a lot changes because of Easytag’s sleight-of-hand.

But I wrote a tool a while ago now, called the Dizwell Tag Cleaner (DTC to its friends). If run against a set of previously-tagged music files, it ‘cleans’ their tags up, removing ‘non-canonical’ tags and leaving only the canonical ones behind.

Here’s a little code snippet to explain what it does:

# Fetch existing metadata into variables
COMPOSER=$(metaflac --show-tag=Artist "$f" | sed s/.*=//g)
ARTIST=$(metaflac --show-tag=Artist "$f" | sed s/.*=//g)
ALBUM=$(metaflac --show-tag=Album "$f" | sed s/.*=//g)
TRACKNUMBER=$(metaflac --show-tag=TRACKNUMBER "$f" | sed s/.*=//g)
TITLE=$(metaflac
Continue Reading

Artists’ Artistry

In order to get media around the house, to various rooms and devices, on an as-needed basis, I’ve deployed various mechanisms in my time -including such things as DLNA servers and other various forms of home-brew wonderment.

A couple of years back, I lighted on Plex Media Server, which is a really very capable music- and video-streaming programme with a reasonable media management library attached. It is open-source

Continue Reading

Classical CD Ripper – Updated

To accompany the updates to all my other audio-related scripts which have been published of late, the Classical CD Ripper has also now been updated. As with all the other software updates of late, the changes are in three basic categories: cosmetic, distro-awareness and year-in-album functionality.

The cosmetic changes are just to add a little colour to the various prompts and warning messages, so that you can tell the

Continue Reading

Absolutelybaching Flac Checker – Updated

Another short note to let you know that the Absolutelybaching Flac Checker (AFC to its friends) has been updated to version 2.02.

As with the recent update to CCDT, the changes are cosmetic for the most part, but also contain a significant piece of new functionality.

The cosmetics bits are to do with auto-detecting what distro you’re running on and prompting you to install any necessary software prerequisites in a

Continue Reading

Classical CD Tagger – Updated

Just a short note to say that the Classical CD Tagger has been updated to version 2.12.

There were a few code tidy-ups. For example, the utility now puts up proper ‘you need to install…’ error messages if it detects that certain software prerequisites are not already installed:

The script has been tested on OpenSuse 15.2, Ubuntu 20.10, Fedora 33 and Manjaro 20.1.2, and in each case the prompt to install the required software prerequisites will be distro-specific. Thus,

Continue Reading

Fixing Mistakes #3: Fixing the ALBUM tag

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 
Continue Reading

Fixing Mistakes #2: Checking the ALBUM tag

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
Continue Reading

Fixing Mistakes #1 : Checking the YEAR tag

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
Continue Reading

Fixing some mistakes…

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

Continue Reading

Lockdown Tasks

As we are all now experiencing ‘lockdown woes’, I decided I had time enough on my hands for it to be worthwhile for me to look again at my various bits of music management software. The Classical CD Ripper and Tagger scripts accordingly got a work-over: little tweaks to make each program work slightly more in ways that suit me than not! I use the Tagger program on a daily basis, so it’s important to me that it works efficiently, which I think it now does 🙂

I then tackled the

Continue Reading