Where the current Discogs datamodel doesn't work (part 1)

After looking at many releases in Discogs and the edit history of various releases and how things have changed through time it is quite clear to see how the data model has changed.

Some of these changes have turned out well, while others were, in retrospect, probably not the right change to make. I am not blaming the developers as I know from experience how difficult it is to get a data model right the first time and how hard it is to change: as soon as something is in use it is non-trivial to change especially with a database the size of Discogs.

Still I want to go through a few examples where I think the current datamodel doesn't work. Most of my examples will focus on the fields from the "Barcodes and Other Identifiers" (BaOI) section. In this post I am looking at three of them: ISRC, SPARS codes and matrix/runout.

ISRC

Currently ISRC codes (International Standard Recording Code, see previous articles about it for more information: 1, 2, 3) are stored in the BaOI section. It would be better to store these per track, as they are actually assigned per track. Right now there is a disconnect between the ISRC code and the actual track. Most people use the free text field for the ISRC field to indicate which track the ISRC code belongs to, but this is a bit of a hack (and I am very sure that there are releases where people made errors, but I haven't checked that yet).

Storing the ISRC code per track would also allow other kinds of searches like "give me all physical releases with ISRC code XYZ" which could be quite a neat feature to have.

SPARS Codes

The SPARS codes (1, 2, 3, 4) are right now stored per release in BaOI, but the correct place would actually be per track. There are releases where they are different per track, although in most of the cases they are the same for all tracks on a disc. And, of course there can be multiple discs per release which do not necessarily need to have the same SPARS code.

Matrix/Runout

The Matrix/Runout field should be stored per disc in a release. Releases that have multiple discs have different matrix/runouts. If there is just a single disc in a release this is actually the same as storing it at the level of the release, but on multi-disc releases this is not true. The current Discogs model doesn't really seem to store information at the disc level at all: it is either per release or per track and should likely be added to have some sort of intermediate level of granularity.

That's it for now. In the next few weeks I will look at more examples.

Comments

SID codes (part 1)

One thing that I only learned about after using Discogs is the so called Source Identification Code, or SID. These codes were introduced in 1994 to combat piracy and to find out on which machines a CD was made. It was introduced by Philips and adopted by IFPI, and specifications are publicly available which clearly describe the two available SID codes (mastering SID code and mould SID code). Since quite a few months Discogs has two fields available in the " Barcode and Other Identifiers " (BaOI) section: Mould SID code Mastering SID code A few questions immediately popped up in my mind: how many releases don't have a SID field defined when there should be (for example, the free text field indicates it is a SID field)? how many releases have a SID field with values that should not be in the SID field? how many release have a SID field, but a wrong year (as SID codes were only introduced in 1994) how many vinyl releases have a SID code defined (which is impossi...

SPARS codes (part 1)

Let's talk about SPARS codes used on CDs (or CD-like formats). You have most likely seen it used, but maybe don't know its name. The SPARS code is a three letter code indicating if recording, mixing and mastering were analogue or digital. For example they could look like the ones below. There is not a fixed format, so there are other variants as well. Personally I am not paying too much attention to these codes (I simply do not care), but in the classical music world if something was labeled as DDD (so everything digital) companies could ask premium prices. That makes it interesting information to mine and unlock, which is something that Discogs does not allow people to do when searching (yet!) even though it could be a helpful filter. I wanted to see if it can be used as an identifier to tell releases apart (are there similar releases where the only difference is the SPARS code?). SPARS code in Discogs Since a few months SPARS is a separate field in the Discogs ...

Using matrix numbers of CDs to verify release years (1)

One of the first steps when making CDs is to produce a "glass master". From that (using a few more steps) a "stamper" is created which is then used to press the actual CDs. When looking at a CD you can often see text in a ring in the middle of the CD. This is the so called matrix which comes from the glass master. Apart from the matrix other text (like the IFPI mastering SID code) could possibly also come from the glass master. A bit of background information can be found on page 7 of the IFPI SID code implementation guide although I would also highly recommend watching some of the clips about glass masters on YouTube, which are highly informative. One company making a lot of these glass masters is Cinram . For most of their glass masters they stored the production date in matrix. This is good news, because it means that it could possibly be used to verify releases and see if the declared year of the release is right: it could never have been released before...

Vinyl & Data

Search This Blog