Portability is The New Black

So, here's the problem. Currently, I own quite a lot of recorded media. At a rough count (worked out by measuring shelf length), it comes CDs: 700; LPs: 250; DVDs: 180 and LaserDiscs: 180 (really!). Amazing how it all mounts up.

The situation is getting out of hand for four reasons: firstly, shelf-space; secondly, indexing and browsing; thirdly, portability; finally, longevity.

Shelf space isn't really too much of an issue for us. Every so often, I have to buy or modify a piece of furniture, but that's about it. The secret to success is ordering. For music, I've gone for alphabetical by Composer, plus a shelf for "stuff which isn't classical". When I was a postgraduate student, I started making a text file with all of my recorded media in it, so at least I could find something just using the search function of a text editor. This gets you out of a scrape when you're looking for Enigma Variations under E for Elgar, but can't find it because it's on the B-side of Young Persons' Guide to the Orchestra (B for Britten). This evolved into a script called [RLDB] (record library database) to display the results of queries and to add new artefacts. It was written in [Qt] and [Python] on my Linux box using [PostgreSQL] as the back end (no point in messing about!), and thus works on the Mac too, at least, after I'd persuaded the Apple to consent to building the Python Qt bindings. ([Full Size])

With the appropriate command line options, it'll work (read-only) as a web CGI program so you can query the database from your mobile 'phone: ([Full Size])

By portability, I don't just mean in the Software sense. Apart from the absolute impossibility of transporting a selection like that around, for example to keep oneself amused on those wet summer holidays in the highlands, even playing some items in different parts of the house presents challenges. Have you ever tried carrying a Laserdisc player around?

As to the issue of longevity, when I was a school boy, I would exchange cassette copies of material I owned with friends, and if I heard something I liked, I'd go out and buy it. Hear that, record companies? Swapping bootleg tapes increases sales. You should be paying people to do it, not suing them! This only works if you have good product, of course; the best way to avoid copyright "theft" (whatever that means — "infringement", I think) is not to sell a load of old . At the time, the only "hi-fi" I had was a cassette recorder. A Pioneer CTF6060, if memory serves. I could only find a picture of the similar 4040 on the web...

LPs were better, obviously, but you couldn't carry them around, lend them to your friends so easily, etc. I sold the Pioneer and bought a NAD machine which had Dolby-C when that came out. This was a mistake. When we moved to Scotland, I was going through all my old stuff and considered what to do with my cassette player and its collection. Guess what? The commercial cassettes had faded away to almost literally nothing, whereas the 30-year-old bootleg copies, while not perfect, weren't at all bad! In the words of Feynman, "What have you seen? what have you learned?" (have you worked out why I don't like record companies yet? ) The Dolby-C ones didn't last too well either: the NR had done a sterling effort of reducing not only the noise, but most the signal above about 500Hz as well.

I'm not falling for that one again. Once the collection is safely and securely stored on hard disk, it can be stored encrypted and backed-up much more easily. And it'll fit easily in a suitcase (now), briefcase (soon) or key ring (sometime). So I won't ever have to pay for the privilege of buying LPs of cassettes I already own, and again for CDs.

Status quo

One of the overriding requirements for the new incarnation of my media collection is that use can be made of the RLDB database. It only covers audio recordings and music video ones, but nonetheless there are currently 4094 entries in it from Carl Fredrich Abel to Domenico Zipoli and I don't want to type that lot in again!

RLDB's database stucture has stood the test of time. Here it is:

               List of relations
 Schema |      Name       |   Type   |  Owner   
--------+-----------------+----------+----------
 public | artist          | table    | postgres
 public | artist_id_seq   | sequence | postgres
 public | composer        | table    | postgres
 public | composer_id_seq | sequence | postgres
 public | location        | table    | postgres
 public | location_id_seq | sequence | postgres
 public | work            | table    | postgres
 public | work_artist     | table    | postgres
 public | work_id_seq     | sequence | postgres
(9 rows)

Now, the good thing is that the idea of an artefact (piece of plastic) is separated from the idea of a musical work. The work and artefact (or, as I called them at the time, "location") tables are stored like this (triggers omitted for brevity, but basically columns with names ending _id are foreign keys of the appropriate relation):

                           Table "public.work"
   Column    |  Type   |                    Modifiers                    
-------------+---------+-------------------------------------------------
 id          | integer | not null default nextval('"work_id_seq"'::text)
 title       | text    | not null
 opus        | text    | default ''::text
 composer_id | integer | not null
 director_id | integer | 
 ensemble_id | integer | 
 location_id | integer | 
 medium      | text    | default ''::text
 comments    | text    | default ''::text
 key         | text    | default ''::text
 date        | text    | default ''::text
Indexes:
    "work_pkey" primary key, btree (id)

                          Table "public.location"
   Column   |  Type   |                      Modifiers                      
------------+---------+-----------------------------------------------------
 id         | integer | not null default nextval('"location_id_seq"'::text)
 l_composer | text    | default ''::text
 l_title    | text    | default ''::text
Indexes:
    "location_pkey" primary key, btree (id)

There is some confusion; the medium is stored in the work relation and not with locations for example. This, if I remember, was a dirty hack to avoid having to deal with multi-CD sets in the location table, whose job is really only to say "go to the shelf and look under 'Fournier'", not really to suggest which actual disk contains the work.

Ripping yarns

An external 1.5TB hard disk drive cost me £120. That should keep me busy for a bit, and allow for a reasonable amount of room. Audio CDs are being stored as [flac] (Free Lossless Audio Codec) files. No need to choose a bit rate, and no arguments as to whether my codec is better than your codec: what goes in is what comes out. Plus, my mp3 player can play them, so I can copy files straight to it if I don't want to carry the whole collection around.

Video is a bit more tricky, but fortunately, I don't have as many DVDs. The best thing to do for more serious material is simply to dump the ISO image of the DVD straight to the hard drive. This preserves all of the navigational information, and can be played directly with [mplayer's] dvdnav:// URL, or after mounting. with [Ogle]. Some disks, principally ones with T.V. series (I've just done this to my "Beiderbecke" DVDs with James Bolam, for example) are transcoded to MPEG4 but at an generous 2.5Mbps. This roughly halves the file size, and the look identical to the original to me. I don't need subtitles and scene-by-scene navigation, so I'm prepared to compromise.

At home, I've got an antique machine which was saved from the scrap heap after a research project came to an end. In its day, it was a top-draw piece of kit: dual 1.2GHz AMD processors, 2GB RAM, twin 34GB SCSI-ultra disks. About the same as a run-of-the-mill desktop machine now, but with a built-in room heater. Fortunately, it comes with a very nice screen, and all of the software I need can be open and running on the desktop at the same time. ([Full Size])

In the top left is quite an important part of the work. Every CD ripped is logged including its bar code and path relative to the external drive's mount point. For example, Beethoven's Violin Concerto ends up in a directory called Thomas Zehetmair, Frans Bruggen & Orchestra of the 18th Century - Beethoven : Violin Concerto & Two Romances. This is because the lack of coherent metadata available for classical material means that ripped CDs are usually given rather eccentric directory names. The external drive has been formatted with a Linux ext3 filesystem, apart from anything else to permit files larger than 4GB, with names containing pretty much any character, and I don't trust Apple's offerings after the laptop experience (what's this "Fix Permissions" thing all about?)

Next Step?

So now what? There are a few collection managers around which might be able to make a decent fist of this: [tellico] is the KDE one. The thing about these sort of programs is that the very rarely cater for classical music collections — tellico's music collection doesn't even have a "composer" field for example — and while they are fully configurable, one wonders if it isn't an extra layer of dependencies which could be handled by a simple script, like RLDB, and a decent database, like PostgreSQL.

The next step must be a bit of masterful introspection. Exactly how do I "read" my collection? Presenting it as boxes on shelves is rather irksome. I expect somebody has done some research on this, but I'm powerfully swayed by the idea that what I really need is to code up some basic functionality and to add what I need as I need it.

It's the open-source way.