Mad File Format Science

The first classical album I ever had was a recording of Tchaikovsky’s Nutcracker Suite, on RCA Red Seal 45’s. The format worked pretty well for it. Except for the Arabian Dance and the Waltz of the Flowers, each piece fit on one side of a record. But a lot of classical pieces didn’t fare nearly as well on 45’s.

Then came the LP. Now all but the longest symphonies would fit on one record, and most didn’t even require a side flip. But the ideal format for classical music was the compact disc, whose length was actually specified to accommodate Beethoven’s 9th. Now over an hour of music could be played continuously without manual intervention or kludgy changers.

Now the CD is on the decline in favor of musical downloads, usually MP3 and MP4. But as things stand, downloadable music isn’t so hospitable to the classics. There are three related issues: The data model, the metadata model, and the economic model. For all three, the unit is the “song,” a single file that’s expected to be not much more than five minutes long. But classical pieces often are much longer and are made of multiple components: the movements of a symphony or suite, or the songs of a song cycle.

Downloadable music typically treats each component as a “song,” but this is often a poor fit. It doesn’t seem fair to the seller to count Mahler’s gigantic Eighth Symphony as just two “songs.” Besides, treating each movement as a separate unit fails to recognize that the work is the group. This gets a little messy when you’re trying to keep a classical piece together in a desktop music application or portable player. Playlists are a weak workaround, since there’s no metadata at the playlist level.

In any case, the metadata which are standard for popular songs are a poor fit for classical music. For a current song, you’re usually interested in the title and the performer. For classical pieces, the composer is generally more important than the performer — it makes a difference whether it’s Beethoven’s Fifth or Schubert’s Fifth!

The various problems each need their own solutions. But it would greatly help lovers of classical music if there were a way to define a group of audio files as a single entity, with metadata to characterize the work as a whole as well as the components. In fact, there is a format to do this. It’s called SMIL (Synchronized Multimedia Integration Language). It’s an XML-based language which defines the presentation of multiple sounds, images, or videos. It includes a metadata capability which makes use of RDF and Dublin Core. Fully implemented, it allows most of the features of a PowerPoint presentation.

Unfortunately, SMIL isn’t very widely supported. iTunes and iPods know nothing about it. RealPlayer supports it, and it was easy for me to handcraft a simple SMIL file that RealPlayer could use. But RealPlayer ignores its metadata features, making it not very helpful for the purpose I’ve described.

Supporting a basic subset of SMIL, including simple metadata presentation, in music players should be easy. Perhaps it hasn’t been done widely because of a feeling that if you’re going to do it at all, you need to do it all. But just as a way to specify an umbrella covering multiple audio components, it would be an extremely useful thing to support. (The moral: Let a SMIL be your umbrella.)

Would there be interest in a SMIL module for FITS? This would be my own spare-time project.