Skip to content

Instantly share code, notes, and snippets.

@spinitron
Last active November 16, 2018 16:47
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save spinitron/d562f52e370fddf926113d38e659d1c8 to your computer and use it in GitHub Desktop.
Save spinitron/d562f52e370fddf926113d38e659d1c8 to your computer and use it in GitHub Desktop.
Music metadata in Spinitron v1 and v2

Spinitron music metadata

What happened to the music database browser?

Spinitron v1 stored music data and playlists in a database that separates entities into tables of artists, spins, disks, and labels (see terminology below). Another table called appearances connected them in the sense: an artist has appearances on one or more disks, a disk has appearances of one or more artist, and an appearance (of an artist on a disk) can feature in one or more spins. The design was partly motivated by the theory of database normalization (I'd give a link if I could find a good one). Here's a simplified diagram of this schema.

v1 schema simplified

The idea was that a relational database of a station's music library would emerge as its staff use Spinitron. As DJs enter spins into playlists, Spinitron would automatically manage the artists, disks and labels and their relations. This would allow users to search and browse the music the station had played and follow the relations.

It turned out to be one of v1's most costly design fails. It was a simplistic model and yet it took painfully complex software to automatically manage the entities and their relations. It produced mess because any data-entry variation would tend to multiply. Tidying database mess by editing to fix data-entry errors was a lot of work with so little reward that stations generally didn't try.

v2 uses a completely different approach. We scrapped normalization and put all music and spin data into one big table of spins. The simplified diagram below shows the general idea.

v2 schema simplified

Search, browse and chart are now supported by a search engine that indexes the table of spins in real time. This is a powerful technology that can do anything the database browser could and more. An upcoming tutorial video demonstrates.

The same technology can also operate across all the stations using Spinitron. We offer access to this as a fee-based service aimed at the music business.

Terminology

When v1 was designed, many years ago, most music was distributed on disk-shaped media so we chose to name the published release field disk instead of the more common album because plenty of songs are played from singles and EPs. Album is even less appropriate for today's digital and network distribution. Collection would be good technically but it is unfamiliar. In the end we opted for release in v2.

We refer to a recording title as song or sometimes song title even though this is often technically wrong. For the majority of users this will be less confusing than other options.

In Spinitron we distinguish songs and spins. A song is a thing that exist in the world of music. When you play a song on the radio, that's a spin. A spin is a record of a planned or historical event. Spins are the primary entries in playlists. A spin's metadata includes, for example, date and time while a song's metadata includes, for example, title and genre. (Both v1 and v2 store song metadata together with spin matadata in the same table.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment