music library maintenance

I was talking with a friend a few days ago because they posted about how much space storing music takes up, when I decided that I ought to write down how I do my music library’s organization.

Now, ideally this might not be that interesting, but I don’t have much storage space, and I don’t wish to store lossless music on everything. I just don’t have the storage space across all my devices.

somasis ~ ● ssh fort beet stats
Tracks: 11983
Total time: 4.9 weeks
Approximate total size: 329.7 GiB
Artists: 1964
Albums: 984
Album artists: 337

What I can do, is store lossless in one place, and then store compressed copies everywhere else, though. Here’s how I do that.

first you take up a lot of space on a server

When I get my music, I store it in a directory on a server in my home. This directory is the source, “/mnt/raid/library/audio/source”.

somasis ~ ● ssh fort tree /mnt/raid/library/audio/source --dirsfirst -d -L 1
/mnt/raid/library/audio/source
|-- rips
|   |-- Various Artists - Hot Wheels Turbo Racing (1999)
|   |-- Various Artists - Inner City Sounds
|   `-- Various Artists - Little Darla has a Treat for You, Volume 30 - Summer 2020
|-- stores-bandcamp
|   |-- ATW - A Small Horse
|   |-- ATW - Mares EP
|   |-- Andrew Lang - Burnt Shades
|   |-- Andrew Lang - From Before
|   |-- Andrew Lang - Momentary Senses
|   |-- Andrew Lang - Strangers EP
|   |-- Karnaboy - Feathers Falling in Slow Motion
|   `-- Men I Trust - Oncle Jazz
[...]

And so on.

It is where all the things in the library originate from, in terms of import location. Additionally, tracking details like if I ripped it from my CD collection/vinyl collection, or if it was from Bandcamp, helps me to retrace my steps if I notice issues on a MusicBrainz release I committed. Mainly, this allows for an incremental import, using the corresponding configuration options in beets, meaning that it won’t import from any directories it has already imported from in the past.

I have a simple Makefile for importing, which simply runs…​

beet-import:
    find /mnt/raid/library/audio/source \
        -mindepth 2 \
        -maxdepth 2 \
        -type d \
        -exec beet import -tc {} +

Again, it’s using the -{min,max}depth so as to catch all the categorizing directories ("stores-*", "rips"), but nothing under them.

actually importing the music {#_actually_importing_the_music}

When I get a new music release, I put it in the corresponding source directory, and run make beet-import.

I run the interactive tagger, rather than let it do anything here automatic, and I run beet import -t; so, using "timid" mode, to be even more pedantic. My goal is for beets to be the source of truth when it comes to what my music library contains. If a single thing is linked to a release other than what it actually is, it invalidates my trust in the accuracy of my entire library’s tagging. Accuracy is important for me, as someone who has a lot of music and uses much of it when producing more music. So, I run it in timid mode and validate the results myself.

The music is imported to “/mnt/raid/library/audio/lossless”. I like to keep the directory mounted over sshfs, so I can access it from “~/audio/lossless” on my laptop.

converting the music {#_converting_the_music}

The relevant beets config.yml snippet:

convert:
  copy_album_art: yes
  album_art_maxwidth: 800
  embed: no
  never_convert_lossy_files: yes
  formats:
    opus:
      command: ffmpeg -i $source -y -vn -acodec libopus -ab 96k -ar 48000 $dest
      extension: opus

Which is to say…​

Which brings us to the second Makefile target:

beet-convert:
    beet convert -a -f opus -y

I wish I could just stop there and say that’s how I maintain the two copies of my library, but alas. We have arrived upon the first problem with beet convert.

duplicates and workarounds, or, the important headache you’ll eventally get {#_duplicates_and_workarounds_or_the_important_headache_youll_eventally_get}

Though beets’s homepage proudly displays the beet convert plugin for transcoding audio to any format desired, it does not do the upkeep of maintaining a library’s structure in the process as well.

The problem lies in removing and renaming tracks. beets will shift files in your library directory (which in my case is the lossless directory) without issue most of the time, but it is not smart enough to replicate those changes on the libraries maintained with beet convert

Really, the main problem is that beet convert (and beet alternatives) only do the work of creating the structure-- once folders change, filenames change, the problem is then that you have duplicates, and you’ll have the converted library structure fall out of sync over time if you want to keep the same directory structure.{fn-structure}

As of now, I fix this problem with a little script named beet-rmdupes; it also requires the mimefilter script in my "~/bin" as well. It’s a little wonky in terms of false positives when it comes to beets' asciification, for reasons I have not yet figured out.

so yeah {#_so_yeah}

This is essentially the hard parts. The rest is pretty standard beets configuration, and the documentation is otherwise excellent, except for these particularly irritating pitfalls.

beets does…​ a staggering amount, and without choking as hard as it could. I’ve really considered writing my own music managing utility as of late but I just haven’t had the motivation to uproot my library again.

However, there’s bits and pieces laying around…​ someday.

Kylie McClain <kylie@somas.is>

2021-05-21