Turning up the volume…

Before I accidentally wiped the web server that runs this site, I had been blogging about the problem of SACDs and the fact that they are often mastered with absolute peak volumes set to about 6dB quieter than they really should be (for technical reasons). I thus modified by AUAC audio converter program to automatically boost SACD rips by whatever it took to get the loudest track on a CD to be as loud as it could reasonably go without becoming distorted.

Which is fine for SACDs… but

A Slight Mishap!

Visitors to the website over the past ~12 hours or so will have noticed… errors. Lots of errors!

My apologies.

I’m not sure if it was the second whisky-and-soda of the evening, but I was attempting to backup the website via a script. That was working well. But the script was then supposed to delete old backups -anything older than 14 days.

The script therefore used a variant of the Bash command:

find $BACKUPDIR -type f -mtime +14 -exec rm -f {} \;

Now that’s a perfectly valid

Another AUAC Update – Volume Matters!

If you’ve been reading the last few posts hereabouts, you’ll know that I’ve recently updated most of my audio-processing scripts. The AbsolutelyBaching Universal Audio Converter (AUAC) in particular received a significant new piece of functionality: when extracting high-res audio from an SACD ISO, it will now boost the resulting FLAC files’ audio volume by 6dB (6 decibels).

This was done because

Universal Audio Converter – Updated

Since all my other software scripts have recently gotten a bit of a re-work, I thought I should probably re-visit the program I use most often myself: the AbsolutelyBaching Universal Audio Converter, or AUAC for short.

For the uninitiated, AUAC is a shell script which provides the convenient ability to convert almost any audio file format into practically any other. Thus auac -i=ape -o=flac will convert Read More...

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 Read More...

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 Read More...

Happy Birthday, Benjamin Britten!

Today would have been Benjamin Britten‘s 107th birthday.

His music was the first ‘serious’ music I ever encountered, thanks to Mr. Harold Vafeas and the Senior School Choir he directed that sang “proper” music like Vivaldi, Orff …and Britten. I hated the music Harold made us sing of Britten’s. Absolutely hated it! It was difficult, complex and… “modern”, at least to my ears. But if you practice a single piece for a term or Read More...

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, Read More...

Time for a change…

That screenshot left of this text contains the answer to an obscure-looking Linux command’s query: when did the file system on my /dev/sdc1 disk partition get created?

The answer is November 23rd, 2019.

Meaning? Meaning that I installed my current desktop operating system almost exactly a year ago. Old-time readers of mine will be astonished, I think, that I’ve managed to maintain the same operating system installation for anywhere near that long! Past practice was for Read More...

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 

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")  

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