User Tools

Site Tools


wiki:blog

Closing Down

After around 18 years, and innumerable incarnations, dizwell.com is closing down for good on or around 28th November 2019. I simply don't have the interest in maintaining a technology-themed website anymore. I will continue to blog about music at www.absolutelybaching.com (ABC), to which the dizwell domain name might re-direct, if I can be bothered making it do so. If not, the dizwell name dies at the end of November.

Thanks to my loyal readers for putting up with me this long!

2019/11/15 13:07 · dizwell

A Trip to the Dark Side

For reasons I won't go into, I had need to re-install a laptop with (cough!) Windows 10. I am fortunate to have a license for the Enterprise Edition of that, so I can switch off most of the telemetry that causes a lot of concern for some people. I also am able to configure updates to happen in such a way that my laptop won't suddenly decide to reboot on a whim of its own and take two hours to install updates it thinks are more important than my work, which is the other main concern most people seem to have about Windows.

Take the telemetry and update issues out of Windows 10, though, and it's actually not a bad client operating system. I wouldn't store data I cared about on it (because it doesn't yet have a properly-functioning ZFS file system, so cannot prevent bit-rot. ReFS looked like it might be able to do an equivalent job, but its future is a bit hazy, given Microsoft's yanking of the ability to create new ReFS volumes out of Windows 10).

Anyway: cutting to the chase, I find myself using a Windows 10 operating system for the first time in a long while and what's one of the first programs I miss being able to run on it? My very own Classical CD Tagger, that's what.

I will add parenthetically that I don't miss the Classical CD Ripper on Windows, because there are excellent free CD rippers for Windows that put accuracy over speed, such as the completely free-of-charge xact Audio Copy or dBpoweramp, which costs money to buy, though a free trial is available. CCDR is a bit redundant on Windows, therefore, I think.

So anyway: the issue soon became: can I get CCDT running on Windows 10? I specifically didn't want to use the Windows Subsystem for Linux, because in its new Version 2 guise, that's just a Linux virtual machine running on a Windows host, which is too heavy for the purpose. I similarly didn't want to run VirtualBox virtual machines, because the transition between Linux and Windows is neither seamless nor transparent… and it's a too-heavy solution for the purposes of running a simple shell script!

I accordingly used that old standby, Cygwin, which provides a 'Linux compatibility layer' for Windows, much as Wine is a Windows compatibility layer for Linux. When you navigate the file system in Cygwin, you are actually navigating the true content of your C: drive -so, it's lightweight and very transparent to use: you see a file in Cygwin, in a Linux 'context', and you can immediately open up Windows Explorer and see exactly the same file in its native Windows 'context': there's no copying or transferring files between two different and distinct environments. Perfect and lightweight enough for a shell script!

It is therefore now possible for this to happen:

…which is, hopefully obviously enough, CCDT running on a Windows 10 desktop.

To make this even more a cross-platform tool than that, I've also very slightly tweaked the script itself (so it's now up to version 2.06). On ext4, ZFS, XFS or any other 'Linux-y' file system you care to mention, it's perfectly possible to create a file called (for example) 01 - Finale: Allegro.flac. You can see me doing this here:

That's on a CentOS 7 file server that's sharing its files out with Samba… so what does it look like in Windows Explorer? Er… not good:

The nice file name I previously supplied has been turned into something weird and not very nice at all! This is because Windows doesn't like certain characters in file names and thus converts them when it sees them, on-the-fly. In this case, the problem is the colon in the original file name. Linux didn't mind it, Windows does… as I can demonstrate by renaming the file on the Linux server as follows:

That's me moving the file so that it acquires a new name that has an underscore where the original had a colon. And what does Windows make of this revised file name?

Well, Windows is now happy too and displays the file name correctly -and, because it now understands the file has a .flac extension, it even knows to display it with the icon of the program I use to play flac files on Windows (VLC, in my case).

The point is, in other words, that whilst CCDT was happily renaming music files to match what their track title had been set to, it was doing it in a Linux-specific manner that would not allow the resulting files to be transported easily to a Windows machine. The new 2.06 version of CCDT converts all 'unacceptable' characters in the original file name to NTFS-friendly equivalents -which is a nice way of saying that question marks, colons, greater-than, less-than, double-quotes, pipes, back-slashes and asterisks will all be converted to underscores. The tags themselves do not get this treatment, so a file will still correctly identify as What: are you going to kill me? in a music player, but on disk will appear with a physical file name of 01 - What_ are you going to kill me_.

So the short version of this blog is: because I was forced to work in a mixed Windows/Linux environment, CCDT is now NTFS-naming-convention friendly. And, I've got CCDT working on Windows directly, thanks to Cygwin.

In consequence of that, firstly: the new version (2.06, for the curious) of CCDT is available in the usual place. Upgrading to it simply involves downloading the new version, deleting the old version from wherever you stored it, and copying the new version back into the same place. And secondly: I've written a new article about how to get CCDT working on Windows.

2019/08/08 14:44 · dizwell

The Power of Random...

Humans are, on the whole, creatures of habit: they dwell within 'comfort zones' that tend not, by definition, to push any boundaries, take chances or give rise to the unexpected. For my own part, I know that when I worked in Sydney city in close proximity to a really good food hall that had an excellent Malaysian take away, I would eat Beef Rendang for lunch, day in and day out! I didn't need 'variety', because the 'monotony' was immensely tasty!

I am aware of this failing in my character: left to my own devices in pretty much any sphere of conduct, I will probably be boringly safe about things. It doesn't really matter what sphere of conduct we're talking about, either: I am a slave to routine!

In an effort to counter this, I have recently knocked together a shell script that will generate a random number between 1 and whatever number you supply as an input parameter when invoking the script:

#!/bin/bash
# Generates a random number between 1 and an upper limit supplied as a run-time
# parameter. The upper limit is inclusive. That is, if you supply "100", then the
# random numbers can include '100' as an output, but 101 can never be output.
# Usage: rnum <upper limit>

RANDOM=$$			# seeds the Linux built-in random number variable, makes it more random!
ULIMIT=$(($1+1))

R=$(($RANDOM%ULIMIT+1))
echo "Your random number is: "$R

Save that (say, as rnum.sh), and you can generate a random number between 1 and 100 (say) by simply running the script with '100' as the run-time parameter. In my case, for example:

[[email protected] ~]$ /home/hjr/Scripts/rnum.sh 100
Your random number is: 88

Not, in itself, particularly hard or particularly exciting, I agree! But if you associate some 'meaning' to a number, then the generation of a random number can mean the random generation of an instruction to go and do something!

For example: I recently threw together a list of about 750 English place names, creating 26 mini-lists of places ordered by the first letter in their name. I had to make a couple of special 'allowances' when doing this, of course: there aren't a lot of places beginning with 'X' or 'Z', so I decided that if a town had an X or a Z in its name anywhere, they'd be classed as an X or Z town, rather than their actual initial letter. Thus Ashby -de-la-Zouch and Devizes are both listed as 'Z' towns; similarly, Uxbridge and Exeter are both 'X' towns, rather than U or E ones. Those exceptions-to-the-usual-rules allowances made, I therefore ended up with this list of 'I' places, for example:

Ilford, Greater London 1
Ilfracombe, Devon 2
Ilkeston, Derbyshire 3
Ilkley, West Yorkshire 4
Ilminster, Somerset 5
Immingham, Lincolnshire 6
Ingleby Barwick, North Yorkshire 7
Ipswich, Suffolk 8
Irthlingborough, Northamptonshire 9
Ivybridge, Devon 10
St Ives, Cambridgeshire 11
St Ives, Cornwall 12

Note that each place has been assigned a number in ascending alphabetical order. There are equivalent lists of places throughout England for each of the other letters of the alphabet.

So all that's left to do now is to run my random number generator 26 times, one for each letter of the alphabet, supplying the maximum number of towns beginning with each letter as the run-time parameter. Whatever number comes up, that's the place we add to the 'must visit this year' list! So, for a random 'I' place to visit, I'd run this command:

[[email protected] ~]$ /home/hjr/Scripts/rnum.sh 12
Your random number is: 5

…and now I know I'm off to Ilminster in Somerset sometime soon. Given the distance from my home town of Nottingham, that probably means an over-night stay in a (desperately!) cheap bed-and-breakfast some place; and a quick glance at Google Maps tells me I might want to plan side-trips to Yeovil and/or Lyme Regis. So that's one weekend of my life now organised -and one where I won't be sitting at home doing not very much!

Now, some towns are a lot less interesting than others! But the rules of this game are that once you've visited the randonly-selected place, you can de-camp to any other place of more interest that happens to be nearby. Thus, our first randomly-selected place was “Ashton Under Lyme”, which appears to consist of some canals, rather a lot of dog-poo and not a lot else: so we used that trip as an excuse to visit near-by Manchester, which was altogether more interesting!

Our 'B' trip was to Brightlingsea:

As you can see, Brightlingsea consisted largely of a road-sign (it has quite a nice sea-front, too, though!). So, Brightlingsea having been visited -and ticked off the list- we swiftly moved on to nearby Colchester and Ipswich, which were more engaging altogether.

Our 'C' trip was to Crediton, in Devon:

That turned out to have a wonderful old church, in which we attended a well-sung choral concert on the night of the 50th anniversary of the Moon landings. So that was worth visiting all on its own (though we also popped into nearby Exeter to see the Cathedral!)

We've since elaborated a couple of extra rules for this 'randomly visit somewhere' game: if the randomly-generated list sends you to town X on one visit and town Y on another, and X and Y are three miles apart from each other… you're not allowed to combine visits to the two of them into a single day out. Two places must result in two separate visits, in other words!

Another rule is that if you visit X on the randomly-generated list and it's so boring that you take side trips to towns Y and Z, you can't class those extra towns as places you've visited. Our side trip to Manchester when visiting Ashton under Lyme, for example, doesn't mean we've done an 'M' trip; similarly, our side trip to Exeter when doing the Crediton run doesn't mean we can tick-off an 'E' place (or even an 'X' one!). Side trips effectively never happen as far as 'the game' is concerned.

The only other 'rule' is that there's no time-limit on completing the list, provided you do all 26 visits within one calendar year: we currently have no plans to visit 'D'udley, for example, even though Crediton was nearly a fortnight ago! So long as we get to it sometime before September, I think we'll still be 'on target' :-)

It's maybe a silly game to play, but we're finding it's making us go out and appreciate places we would otherwise never have bothered visiting. All thanks to the power of a random number generator!

So pleased have I been with the results in us getting out and about to weird and whacky corners of the realm we wouldn't have chosen to visit ourselves, I've recently decided to apply the 'Power of Random' to my music, too.

My list of around 400 composers, whose music forms most of my classical music collection, has therefore recently been sorted alphabetically and numbered sequentially on a spreadsheet. A quick trip to my random number generator later and I now have my instructions to listen to a particular composer for around the next fortnight or so -and, in the process, to research their life and work a little more deeply than I would if I were 'just listening' to whatever I happened to click on when running my computer's music player.

The first random number selected for this purpose happened to be 304: that turns out to map to Michel-Richard de Lalande, which means I'll be listening to his Grands Motets and rather less grand Symphonies for the King's Supper for the next couple of weeks. I won't be listening to that fare exclusively, of course, as that would likely get boring very quickly, if not with Lalande specifically, then at least with some of the other composers who are likely to pop up on my random list in the future! But, as in the case of the randomly-inspired Town visits which permit 'side-trips' if the main town of interest turns out to be not very interesting after all, I'm allowed to listen to (lots of!) other music all the while… provided only that I definitely make time for Lalande (or whoever the composer-of-the-fortnight turns out to be in the future) at some point.

I'm hoping this will cure my 'long tail' problem, neatly illustrated by these Last.fm screenshots:

So that looks pretty good: I've listened to around 559 different “artists” since 2008 (where “artist” really means “composer”, in my case!), and 139,038 different pieces by those different composers. I won't say it's an extraordinary set of statistics, but it does (I think) indicate a fairly wide and varied familiarity with the total body of 'classical' music. Except… except…

This screenshot now tells you that just the top 10 composers in my list of 'listened to' composers account for 78,086 of the 139,038 bits of music I've listened to since 2008. Or put slightly differently, that 56% of my listening is accounted for by just 10 composers! The other 549 composers all together amount to only 44% of my listening :-( That is not so good and is the audio equivalent of my Beef Rendang dietary fixation: there are a handful of composers I listen to a lot, but most hardly ever get a look-in.

Random numbers to the rescue, therefore: I'm hoping my new-found, random propensity to listen to things I've collected but seldom listen to through choice will hopefully improve this rather top-heavy approach to my listening habits! That long tail of seldom-listened-to composers should, with luck, get a lot shorter over time.

I recommend random number generators to you all as ways to make your life a little less predictable, therefore!

2019/08/02 13:49 · dizwell

Handling SACDs

A long time ago, I bought a copy of an SACD of Heifitz playing Bruch's Violin Concerto: for the avoidance of doubt, here's the invoice proving I paid for my copy!

What I hadn't realised, however, is that the disc I brought was an SACD -a high-definition “improvement” on standard CD audio which never really took off and, to this day, requires some fairly unique -and uniquely expensive!- audio gear to interpret and play in all its high-def glory. Lacking said hifi equipment at the time, I merely popped the SACD in a standard CD player and ripped it as usual (SACD, fortunately, was backwardly-compatible with standard CD and could thus be played -at ordinary CD audio quality- on regular CD equipment).

Due to a recent file system mishap (i.e., I clicked 'delete' when I meant to click 'rename'!), I needed to re-rip that particular SACD the other day, but discovered that storing it in the loft in Australia during several inland Summers had done terrible things to it: the thing was practically unplayable. I therefore did what I do not ordinarily make a habit of: I downloaded someone else's rip of the same disc, courtesy of a torrent site.

Trouble is, that download came as a single ISO file, not separate tracks:

So, here was my new problem for the day: how do you turn an ISO of an SACD into separate FLAC tracks that you would have obtained by ripping an ordinary CD of the same music?

Well, on Linux, there's a small utility you can install which will do the first part of the job, called sacd_extract. It's not in Arch Linux's standard repositories, but can be installed from the AUR. Other distros will have similar workarounds to installing the tool.

Once the tool is installed, you can then simply issue this command:

sacd_extract -2 -s -C -i name-of.iso

That pulls individual tracks 'out' of the ISO, creating separate files for each -though the files will be in “DSF” format, which is the extension used to identify high-resolution 'delta sigma' modulated audio files. Note, by the way, that the “-2” in the above command has already stripped out a lot of data contained within the source ISO: it's an instruction to turn the multi-channel audio contained in the original SACD into 2-channel, ordinary stereo, audio files. Working on my specific SACD ISO file, the process looked like this:

[[email protected] Bruch]$ sacd_extract -2 -s -C -i Bruch\ Violin\ Concerto\ No.\ 1.iso 
Exporting CUE sheet [Jascha Heifetz - Bruch Violin Concerto No. 1.cue]
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf] (1/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf] (2/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.dsf] (3/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/04 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Introduction Grave; Adagio cantabile.dsf] (4/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/05 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Allegro.dsf] (5/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/06 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Adagio; Andante sostenuto.dsf] (6/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/07 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Finale Allegro guerriero.dsf] (7/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/08 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro non troppo.dsf] (8/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/09 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf] (9/10)..
Processing [Jascha Heifetz - Bruch Violin Concerto No. 1/10 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro con fuoco.dsf] (10/10)..
Completed: 100% (19.1MB), Total: 100% (19.1MB) at 11.08MB/sec

That resulted in component tracks being extracted into a sub-directory, whose contents ended up looking like this:

[[email protected] Jascha Heifetz - Bruch Violin Concerto No. 1]$ ls -sh
total 2.6G
311M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf'
317M '02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf'
269M '03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.dsf'
315M '04 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Introduction Grave; Adagio cantabile.dsf'
187M '05 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Allegro.dsf'
266M '06 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Adagio; Andante sostenuto.dsf'
276M '07 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; Osi - Finale Allegro guerriero.dsf'
507M '08 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro non troppo.dsf'
146M '09 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf'
 47M '10 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Allegro con fuoco.dsf'

You will note that all these files are of type “.dsf”. You will also note that they are all enormous in size! Bear in mind, an ordinary CD would contain around 650MB of data: here, we have over 2.6GB of the stuff!

So, given that I'm over 17 and my ears cannot, accordingly, tell the difference between the high-res, deep bit-depth audio recording that is a DSF and ye olde FLAC equivalent; and given that I don't have an infinitely-sized hard disk in which to store around 2GB of un-needed, un-wanted data… how do you go about converting DSF files into 'ordinary' FLAC ones?

Well, there are various ways of doing that, depending on what software you want to use. But since it's highly likely you already have ffmpeg installed, here's one way of doing it:

for f in *.dsf; do ffmpeg -i "$f" -ar 44100 -sample_fmt s16 "${f%%.dsf}.flac"; done

That loops through all the DSFs found in a directory (which are likely to be using a 96KHz sampling rate) and down-samples each of them in turn to a FLAC file that uses a 44.1KHz sampling rate (which is the same rate ordinary CDs use). It also switches to using only 16 bits to record each sample (rather than the 24 bits per sample that the high-def DSF original probably uses). A 16-bit depth is, again, what an ordinary CD uses. Doing that on my Heifetz tracks created earlier, I see output such as this:

Output #0, flac, to '09 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.flac':
  Metadata:
    title           : Adagio
    artist          : Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New Symphony Orchestra of London
    album           : Bruch: Violin Concerto No. 1; Scottish Fantasy & Vieuxtemps: Violin Concerto No. 5
    genre           : Classical
    TRACKNUMBER     : 9
    date            : 2005-01-11
    encoder         : Lavf58.20.100
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16, 128 kb/s
    Metadata:
      encoder         : Lavc58.35.100 flac
size=   16176kB time=00:03:36.30 bitrate= 612.6kbits/s speed=89.2x    
video:0kB audio:16168kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.051644%
ffmpeg version n4.1.3 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8.2.1 (GCC) 20181127
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100
[dsf @ 0x55bd81a83d80] Estimating duration from bitrate, this may be inaccurate

The final 'this may be inaccurate' warning can be safely ignored. Otherwise, this sort of output appears once-per-track undergoing conversion… but at the end of the process, you have essentially converted an SACD rip into an ordinary CD rip. This means you are losing data from the original… but it's data your ears probably can't hear anyway!

In practical terms, you will save a lot of disk space. Here again, for example, are the file sizes of a few 'source' DSFs:

ls -sh *.dsf
  311M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf'
  317M '02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.dsf'
  269M '03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.dsf'

And here are their FLAC-converted equivalents:

ls -sh *.flac
  36M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.flac'
  34M '02 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Adagio.flac'
  34M '03 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Finale Allegro energico.flac'

You will note that you are getting file size reductions of 311M to 36M (to take one example): a reduction of around 88%. But the resulting FLAC is a faithful representation of what you would have ripped from an ordinary CD, so still (in my view!) is a properly lossless audio file.

As a further illustration. Here's an original DSF:

311M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.dsf'

Here is the down-sampled FLAC equivalent:

36M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.flac'

And here's a 192kbps MP3 I converted from the FLAC:

11M '01 - Jascha Heifetz, violin; Sir Malcolm Sargent, conductor; New - Vorspiel Allegro moderato.mp3'

Since the MP3 is still 75% smaller than the FLAC, there's clearly a lot of audio signal that can be compressed (and -mostly inaudibly!- removed) from the FLAC file, despite the FLAC file itself having lost around 88% of the original DSF signal data. That's my way, at least, of reassuring myself that the conversion from DSF to FLAC hasn't lost anything to care about.

Now the sort of audiophiles that haunt the likes of the Hydrogenaudio forums would have a fainting fit at what I've just described! They get very upset at reducing bit-depth from 24 to 16, for example; and proxy wars have been fought over whether human ears can hear the difference between 44.1KHz and 88.2KHz (or higher) sampling rates or 16-bit and 24-bit depth. But I'm a musicphile, not an audiophile: provided my music sounds great, and I know I've not lost anything I could plausibly hear, I don't mind down-converting SACD to CDs for my own listening purposes. Your mileage is free to vary, of course!

2019/07/06 09:56 · dizwell

Dogfooding

I was fortunate this month to be allowed to buy around 50 music CDs (for very little, which was why it was allowed in the first place!). All had to be ripped, of course: using the Classical CD Ripper (CCDR) for any length of time made me realise that my original version needed to be improved -and that's why I wrote about the new Version 2 of CCDR last time.

Now, I'd originally written CCDR with the idea that it would get all the 'album-y' stuff about a CD's metadata right, but that you would sort out the 'track-y' stuff later on with a separate tool, such as Easytag or Puddletag. That seemed like a reasonable move, since CCDR is concerned with ripping CDs, not one-at-a-time tracks.

When I got a bit fed up of having to launch Easytag or Puddletag separately after each rip, however, I soon felt the need for a command-line tag utility to get these 'track-y' bits of metadata correct, too: thus was born the Classical CD Tagger, or CCDT.

From the outset, then: CCDR got most of the tag data for an 'album' correct; CCDT only had to fill in the bits that CCDR didn't bother setting. It therefore really only tagged track titles and not a lot else. I hadn't envisaged CDs being ripped by non-CCDR tools and then needing to have all their metadata fixed by a command-line tag tool. But guess what happens when, confronted with a pile of 50 CDs to rip, you ask your other half to help out… an other half who is firmly wedded to Windows-only tools! You do, then, indeed end up with a pile of hundreds of tracks, all of which need to be tagged properly from scratch. The old assumption that CCDR would have got most of the tags right beforehand proves, in those circumstances, completely wrong!

Thus, by virtue of having to use this stuff at length, at home, I decided that the Classical CD Tagger needed a Version 2 re-write, too: it needed to be able to supply all the tags for a digital music file, not just the ones you thought CCDR wouldn't have supplied already. It also needed to incorporate the Dizwell Tag Cleaner (DTC) functionality, since I found that invoking that third utility every time I'd finished tagging a CD (or a part of a CD) was rapidly getting tedious!

So the short version of this blog post is that Version 2 of the CCDT is now available for download from the usual place.

It is extensively re-worked so that it now uses colour effectively for prompts, warnings and user input, keeping each class of information clearly separate. It allows you to supply album-wide as well as track-specific tagging information. It auto-numbers tracks if asked, starting from any given number and incrementing from that point onwards. It will display the tag metadata provided for the first FLAC file found. It will apply the Dizwell Tag Cleaner functionality to a set of FLACs if asked. It will also remember the tags you supplied last time you ran the utility (so, if you are tagging, say, Beethoven's 5th and 6th symphonies, both performed by the Chicago Symphony Orchestra conducted by Lenny Bernstein, you type all that information for Symphony No. 5, but when you come to tag Symphony No. 6, all those details will be available by simply pressing [Enter], as they will have been remembered from the earlier symphony tagging session).

When you press 'q' (and [Enter]) to quit the utility, the program will perform a background clean of the tags associated with all the FLACs in a directory, as if you'd invoked the DTC utility. So at the end of each tagging session, you are guaranteed to end up with a minimal, clean set of effective metadata tags, free of extraneous tags that we have no use for. The DTC check also re-computes MD5 hash values for the musical content of each track, so if you get through without any warning messages appearing (in bright red!), you can be sure that your audio data is in good order internally and is therefore free of corruption or bit-rot problems.

DTC remains available as a separate utility, of course, since you may well want to clean your tags (and check your files for corruption) without actually editing the tag data.

Upgrading from an earlier version is easy: just delete the old ccdt.sh file, wherever you stored it, and copy the new one down on top of it. Chmod +X the new file to make it executable; job done!

2019/06/23 14:47 · dizwell

Older entries >>

wiki/blog.txt · Last modified: 2018/12/12 14:06 by dizwell