Vinyl & Data

A bit over a year ago I looked into ISRC codes for checking release dates. The ISRC code actually contains a year component which can be used to check dates, as (except in rare old cases) the release is always after the ISRC code has been assigned, so it cannot be earlier. A few people on Discogs seem to disagree, but meh. For more details you can read an earlier post . So back in February 2018 I got the following graph: Distribution of smells in releases with known ISRC fields in February 2018 which also included some other smells and not just date mismatches. Back then I concluded that there were 273 releases that had a date mismatch. So I decided to rerun my analysis with the latest data dump (up until and including April 30 2019) now that it seems that there are many more ISRC codes in the database, because people seem to be fixing the ISRC field . As expected the amount of releases with a date mismatch is now a lot higher: 1414. They are distributed across the database ...

I am still not done looking at matrix numbers to verify Discogs release data and I am uncovering more and more. In a previous post I wrote about how Cinram has embedded the manufacturing date of the glass master in the matrix and how effective it can be to find releases with an incorrect release year. But there are also other companies that did this, such as P+O . In typical German fashion they were very thorough with their matrices, and until 2007 they put a few markers possibly indicating the date in the matrix (later they used a different matrix and since then it is not so easy). Each old style P+O matrix has: a number identifying the release a character indicating the master (for example A, or B) an optional number indicating the stamper a month/year combination indicating the production date The two interesting parts are the number identifying the release and the month/year. For each of the numbers it is known which number was used in which year. The month/year combina...

Using pressing plant information to find wrong information in releases in Discogs is something that I explored in an earlier post . I only looked at a single pressing plant and that already uncovered 76 releases that were obviously incorrect. I added a few more checks for pressing plants to my scripts and processed the latest Dicogs data dump that I could find. Immediately hundreds of more errors popped up, and I didn't even add that many companies to my checks. With the new checks I could find 610 that are wrong, but I am sure that as soon as I start adding more checks many more errors will pop up. Releases in Discogs where manufacturing plants and release years don't match What often seems to be the case that people have combined the original release with reissues, making the entries completely useless for a correct classification. One thing that I noticed when looking at the pages for the manufacturing plants is that there are quite a few where it is mentioned w...

In the last few weeks I have been digging a lot into CDs and I have come to the conclusion that correctly identifying CDs is difficult: there are so many things that you have to take into account and it is easy to make a mistake. Luckily automation helps! I decided to look at SPARS codes again, as I felt that story was not yet complete. If you don't know what SPARS codes are, I would suggest to first read my earlier posts about: part 1 , part 2 and part 3 . On Wikipedia it says that SPARS code were introduced in 1984 . Of course, we all know that if it is on Wikipedia it just has to be true! Wikipedia has a reference to a physical magazine from 1984 and with a bit of searching I found someone who actually describes the same magazine and which seems to confim what Wikipedia says. So, I wondered: how many releases are there in the Discogs database with a defined SPARS code field (containing a valid SPARS code) and a declared release date prior to 1984? I was surprised to f...

Something that has turned out surprisingly hard to do is to categorize CDs. While at first it seemed easier than vinyl it has turned out to be much more difficult, as CDs have been repressed in different years by different plants (or the same under a different name), but where everything is the same, except for some very minor details, such as SID codes, or the CD matrix. I have already written about SID codes and how they can be used to very roughly date CD releases . But there is also other information that can be used to see if releases have been dated (somewhat) correctly. Recently I decided to look at the companies that are listed, see when they were operational and use that information for checking release years. Quite a few CDs were pressed at a particular plant in the US. During its lifetime this plant operated under different names: PDO, USA from 1986 - 1992 PMDC, USA from 1992 - 1999 UML from 1999 - 2005 EDC, USA from 2005 - 2009 There is some overlap: some g...

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...

Time to revisit the ISRC codes. I already talked about these twice, namely how many errors for these codes there are in Discogs , as well as how to extract them from a CD . In the first of those posts I already hinted at that there is actually a year component in the ISRC codes. The ISRC code for a single track has 12 characters. Characters 6 and 7 should be digits indicating the year the code was assigned (although in the early days some ISRC codes were handed out where the year the song was written or when the recording was made). It would of course been easier if they would have used 4 characters, but they didn't. That means that the year component from the ISRC code can be used to check whether or not a release is correctly dated, because a release cannot be from earlier than the year the ISRC was assigned. I adapted my scripts to check for a few things: is the format confirming to the ISRC standard? is the year recorded in the ISRC not later than the date of the rele...

When I was a bit more fanatic about collecting records of a certain artist who were on EMI (and related labels) I quickly learned about how EMI's labels worked and it all seemed very clear: catalog numbers starting with 5C means The Netherlands, 1A is either The Netherlands or Europe (in the 1980s), 5A and 1C are Germany, 4C is Belgium, 2C France, and so on, like mentioned on this page in the Discogs reference site . So I thought that it would be trivial to cross reference EMI label numbers and countries in Discogs to see if they would match and clearly see if anyone would have entered the wrong data and then rightfully scold them for it. But reality turns out to be a bit more complicated than anticipated. What I did is that I looked at all the releases where the catalog number starts with either "5C" or "5c" and checked if the country is The Netherlands. I could find a bit over 6400 releases from the Netherlands: Distribution of Dutch releases with EMI ...

One of the things that I care about in Discogs is correct data and finding something in the dataset that allows me to perform a few more checks to find errors always makes me bit excited. This time it is about "Greek license numbers": like Czech manufacturing dates or Indian packaging dates (some) Greek releases have a license number, where one part of the code is actually a year. Some people have added this license number to the "Barcode and Other Identifiers" (BaOI) section which means it can be used to verify if the year that was declared in the releases is actually correct! In total there are 1402 releases from Greece that have such a license number in BaOI and where it can be easily detected. They are distributed over the data as below: Distribution of Greek releases with a license number For this particular check I made the assumption that a release cannot be from before the release year that is on the release, but it can be from after (similar to ...

Another country that put dates on its releases is Czechoslovakia (I am using past tense, as the country no longer exists). On most releases from this country from the late 1960s - early 1990s you can find a so called "manufacturing date code", or something similar to that. The page for the Opus label on Discogs says: "Most Czechoslovak vinyl records pressed between ca. 1967 and 1992 include a three-digit code on the side A center label . The first two digits represent the year, the third digit the half-year of the pressing. For example, a record with code '75 2' on the label has been manufactured in the 2nd half of 1975." and goes on to explain that this code does not necessarily mean that the record was also released in that year, but that it could have been held back for whatever reason. But it does mean that it can be used for checking the release year to see if it is perhaps wrong (too early). so I did just that. I looked at a few things in t...

Time for me to go back to a very boring error in the Discogs database: release dates. In an earlier post I already wrote about weird data in the Released field (this is the date field) but that is not what I want to talk about now (as I have already done that). This time it is about something a lot simpler: wrong months in Discogs. Month equals 0 As it turns out there are quite a few releases in the data where the value of the month is no longer correct. Apparently in the past it was custom (or even mandatory) to have releases in full YYYY-MM-DD format, and if the month and date were not know the value 00 was inserted. This is no longer accepted and if you edit a release and the value of the month is 00 then the following error will be displayed: Error message for wrong month This happens only for older releases that haven't been updated for years. It can be argued that this is mostly a cosmetic bug as the old dates with month values of 00 will display just fine. But, t...