If you are into collecting records it has probably happened to you: you are at a record fair and wonder whether or not you already have the record you are holding in your hands and you need to decide whether to buy it or not on the spot. It certainly has happened to me: I have bought plenty of duplicates, or was absolutely certain that I had a certain record, only to find out at home that I actually didn't have it.
I sometimes also go through my record collection and see records that look very similar (to illustrate that: I have about 20 different copies of Queen's Greatest Hits) and then wonder what the difference between them is, as I tend to forget the subtle differences. This information is (mostly) recorded in online databases such as Discogs, but I am not always near my computer (strange, but true).
So I was thinking: what can I do to connect these two worlds? One answer I came up with: make labels with QR codes that point to the right release on Discogs and use my smartphone/tablet to scan the QR code and be taken to the right release.
However, with the new built-in QR scanner in Apple's iOS 11 (and my guess is that Android will be following soon as well) it will become a lot easier to scan QR codes and they will be more ubiquitous, so QR sounded like the right choice. And, as it turns out, it is a lot easier to create these labels than I first thought it would be.
First you need to get the information about your collection. Luckily Discogs makes this very easy by offering exports of collection data. Yay!
The CSV file exports the following data (in this order):
So I opted to use ReportLab to generate PDF files. ReportLab also has built in functionality to generate QR labels, and it is very good at generating PDFs. The one problem I have with it is that the open source version is horribly underdocumented.
Still, with some fiddling I got it working nicely for a 8x3 grid on A4 format (I happened to have some sheets with 24 labels on them). The result is a program, that you can find in its own GitHub repository (Python3 and released under the GPLv3 license, only tested on Linux). At the moment the parameters (grid dimensions, paper size) are all hardcoded to suit my particular use case, but that will change at some point in the future.
I am not entirely satisfied with the result yet: the labels that I used are a bit too small to store all the information that I want to have on them, but it is a good start.
From their point of view this is completely understandable: no one (apart from me) is using it right now, so why invest engineering resources in something that is basically unproven? It might turn out that there is absolutely no market for it at all.
However, I am more optimistic about the future: as said before Apple will natively support QR code scanning in the upcoming iOS 11 and my guess is that Google will add native support to Android soon as well.
I sometimes also go through my record collection and see records that look very similar (to illustrate that: I have about 20 different copies of Queen's Greatest Hits) and then wonder what the difference between them is, as I tend to forget the subtle differences. This information is (mostly) recorded in online databases such as Discogs, but I am not always near my computer (strange, but true).
So I was thinking: what can I do to connect these two worlds? One answer I came up with: make labels with QR codes that point to the right release on Discogs and use my smartphone/tablet to scan the QR code and be taken to the right release.
QR codes
QR codes have not been very visible (literally) in the West so far but they are a very big success in for example Japan. One factor contributing to it probably has been the lack of device support: to scan QR codes on Android you first need to install an external scanner app and Apple's iOS currently (iOS 10) also doesn't support QR codes natively (so again: external apps).However, with the new built-in QR scanner in Apple's iOS 11 (and my guess is that Android will be following soon as well) it will become a lot easier to scan QR codes and they will be more ubiquitous, so QR sounded like the right choice. And, as it turns out, it is a lot easier to create these labels than I first thought it would be.
First you need to get the information about your collection. Luckily Discogs makes this very easy by offering exports of collection data. Yay!
Discogs CSV exports
After logging in on Discogs you can see a tab "Export". After you click on that you are taken to a page where you can export data as CSV for the following:- contributions
- collection
- wantlist
- marketplace inventory
- marketplace orders
- marketplace order items
The CSV file exports the following data (in this order):
- Catalog number
- Artist
- Title
- Label
- Format
- Rating
- Released
- release_id
- CollectionFolder
- Date Added
- Collection Media Condition
- Collection Sleeve Condition
- Collection Notes
- artist
- title
- release_id (this is the identifier used in the Discogs database)
Valid Discogs URLs
The URLs on the Discogs site embed the release_id from the CSV. When clicking on a link you will see the name of the artist and the release, but also the release_id. The names actually don't matter (as it can change if the name of the artist or release is wrong) and internally Discogs only uses the release_id. The URLs. Valid release URLs can therefore be easily constructed as follows:https://www.discogs.com/release/ + release_idor, in Python:
"https://www.discogs.com/release/%s" % str(release_id)and that is really all there is to it.
Generating QR codes
The next step is capturing the URL in a QR code. Generating QR codes on Linux is actually very simple. For example, with the qrencode program you can generate QR codes for basically anything. But, and that's the drawback, that's all it can do. For printing I would want to add text and arrange the data in a grid so I can just buy sheets with different labels.So I opted to use ReportLab to generate PDF files. ReportLab also has built in functionality to generate QR labels, and it is very good at generating PDFs. The one problem I have with it is that the open source version is horribly underdocumented.
Still, with some fiddling I got it working nicely for a 8x3 grid on A4 format (I happened to have some sheets with 24 labels on them). The result is a program, that you can find in its own GitHub repository (Python3 and released under the GPLv3 license, only tested on Linux). At the moment the parameters (grid dimensions, paper size) are all hardcoded to suit my particular use case, but that will change at some point in the future.
Result mock up
I tested this with a few entries from my collection, printed labels, grabbed a few records and put it the labels on it. The result can be seen below. Please note that the QR codes do not correspond to the records, as it is just a mock up.I am not entirely satisfied with the result yet: the labels that I used are a bit too small to store all the information that I want to have on them, but it is a good start.
Things to keep in mind
There are a few things to keep in mind, related to printing, labels, and a few other things.Borderless printing
Most printers cannot print in so called "borderless mode". My particular HP LaserJet model certainly cannot do it. This means that you likely will have to fiddle a bit with margins to prevent that data is cut from the edges. This can be quite frustrating, so it might be worth checking out other solutions (such as a dedicated label printer). Also, it helps to test in draft mode and with regular paper before you unnecessarily waste labels.Get the right labels
Labels are actually very cheap: you can buy stacks of them for about 0.01 Euro per sticker in various configurations. Depending on the amount of information you want on the stickers you can explore different formats. I found 24 (8x3) on A4 to be a bit restraining, but I haven't played with any other formats yet. Probably I would go for 14, 15 or 16, or use a dedicated label printer (depending on the price of the labels).Use plastic sleeves
Needless to say but don't put the stickers directly on the outer sleeve of the record to prevent damaging the sleeve of the record itself. Always use an extra plastic sleeve and put the sticker on that.Information will change, so make sure it is correct
On a site like Discogs information will always change and it might be that at one point the release your QR code points to is merged into another release. The one solution for that is to make sure that the information on the page is as complete and correct as possible before you print the stickers.Other uses
The obvious other use besides using it for your own collection is if you are selling items on a record fair and you want your records to be "Discogs-enabled" (although you probably shouldn't call it that, the trademark people might not like it). At 1 cent per sticker it adds a lot of convience for people using Discogs on their phone. Of course, it means that every record that you use a sticker for needs to correspond to the actual item in the database and as I already have said in a previous post that is a lot of work, so it might not worth doing for every record, but just for the more expensive items.Support in the Discogs app? Not yet.
Currently QR codes like this are not supported in the Discogs app for iOS or Android. I told the staff about it, and also posted about it on the forum, and the answer was "cool idea, but not right now".From their point of view this is completely understandable: no one (apart from me) is using it right now, so why invest engineering resources in something that is basically unproven? It might turn out that there is absolutely no market for it at all.
However, I am more optimistic about the future: as said before Apple will natively support QR code scanning in the upcoming iOS 11 and my guess is that Google will add native support to Android soon as well.
Comments
Post a Comment