YesterdayI've read the question Algorithm to create costum Template/Code from String. Because the question was not formulated that well it was downvoted just instantly. However, the question itself was in my opinion not that bad, so I decided to ask a hopefully better version of this question again.
First, consider what would happen if there are two different songs called "Coffee." Your proposed algorithm would assign them both the same code. That seems unreasonable. You want the code to uniquely identify the song.
Second, song names can be arbitrarily long. For example, there's a song by Pink Floyd called "Several Species of Small Furry Animals Gathered Together in a Cave and Grooving with a Pict." Your encoding algorithm probably won't be able to fit that into 24 bars. Even if it can, I can always find a longer song title.
Given the letters a-z, there are 11,881,376 possible 5-character strings. If you just want to uniquely encode all possible, you can do that with just 23 bits. Just treat the string as a base-26 number and do the conversion.
Update: I asked a similar question and it was answered by someone linking the patent for this barcode. To summarize, they use an intermediate look-up-table to link the barcode to the unique Spotify ID.
The bars in Spotify Codes have 8 different heights they can be. The logo is the max height, and the first and the last bars are always the lowest height. In the image above, the max height is 96 pixels, and the bars fall into 8 different height bins: [96, 84, 74, 62, 52, 40, 28, 18].
The weird thing about this is the amount of information in the URI and the spotify code do not match up. The URI is 22 characters long, and contains 0-9 a-z A-Z. This means 62^22 potential URIs, or 2.7 e39. There are 23 bars in the spotify code, but the first and last are always 0, so there are only 21 usable bars. This means 8^21 or 9.22 e18 potential codes. The URI to code mapping is not straightforward since there is not 1 code to 1 URI.
I do not know how they map the URIs to the codes. My guess would be that they have a separate database/lookup table that they use to map the codes to URIs. When creating a code, they hash the URI to a code and store that to look up later. When someone looks up a code, they check that database and map it to the URI. Since there are so many more potential URIs, they just don't ever get used and they don't have to worry about them.
The record player uses Radio-frequency identification (RFID), the same technology in your credit card when you tap to pay, and in access cards you scan to enter restricted buildings. This technology usually involves RFID chips such as in your credit card, and an RFID scanner such as a debit machine that can read the values of the card when it is tapped and perform an action accordingly.
In this project, the RFID scanner module is mounted inside the wooden box, and the vinyls all have an RFID sticker that can be tapped on the box to switch the album. Inside the box, the RFID scanner is wired to a Raspberry Pi, which is running a python program that switches the song based on the value it reads from the RFID scanner. Depending on the RFID sticker value, the corresponding album is played through the Spotify API.
When you purchase the RFID scanner, it should come with a set of header pins. The header pins are either pre-soldered on, or included for you to solder them on yourself. Either way, your RFID module needs to have headers to connect it to the Raspberry Pi.
Now that our wiring is done, we can turn on the Rapberry Pi and set it up. The first thing we have to do is update our Raspberry Pi to the latest operating system, and ensure it is running the latest software.
The first thing we need to do to integrate Spotify with the Pi is making it a Spotify Connect Device. This adds the Raspberry Pi to your list of available Spotify devices on your home network, and lets you play Spotify tracks through it.
So at this point, we have code that allows us to scan and read RFID stickers, and we are able to play Spotify through our Raspberry Pi. The last piece of the puzzle is using the Spotify API to control the music that plays on the Raspberry Pi based on the RFID card values.
If you get a no device found error, open Spotify on your phone/computer and connect to "Raspotify" from the available devices and try it again. We need it to be an active device in order to play songs through the API, otherwise the API call will fail. You usually only have to do this again if you haven't played anything on the device for a few hours. However, as long as you're playing music on it, it will remain active.
A Note: The code below will infinitely loop and will restart if there are exceptions (errors). This is because if you try to scan a card to play a song after hours of not playing music on the device, it will become inactive and Spotify will return a "404 device not found" error. Once you go on Spotify from a phone/computer and connect to Raspotify again, the code will work. The code might also just time out, and if that's the case we want it to restart. Before it loops again, it will print the error message, so if the code isn't working for you, use this message during debugging to identify what your errors are. You can always use Ctrl C to stop the loop and exit the code.
This great article walks you through how to add your file to the crontab and execute the script upon startup of the Raspberry Pi. I recommend testing the player.py code thoroughly before adding it to the crontab, to ensure you aren't running into any errors.
Finally after the code was working, I printed mini-vinyl covers on cardstock, and 3D printed vinyls to attach the RFID stickers and insert into the covers. I also 3D printed some parts to mount the scanner and Raspberry Pi into the wooden box.
Spotify is amazing. With a few taps on my phone I can access all the music I love to listen to, both old and new. Spotify makes it really easy to find something to play and to switch from a track on one album to another.
I like to listen to entire albums from beginning to end. Part of this is because I felt this is what the artist must have intended when creating the track list. However swapping out CDs and changing from a track on one album to another was a really disruptive experience - even with the Sanyo 5 CD changer stereo I had in my later teenage years.
Of course many of the points made above are the same reasons for the recent resurgence in popularity of vinyl records. People enjoy feeling connected to their music. Their music. One property of vinyl records which I like is that moving backwards and forwards within a track, or even from one track to another, is not directly supported by the medium or most players. The single physical groove which spirals from the outer rim to the centre encourages the listener to experience an album from beginning to end. I will not comment on whether or not vinyl records sound better than CDs ;)
My original idea was to use RFID tags on random vinyl records to identify Spotify albums as they were placed on a record player. I developed this concept on and off for a few years, and had bits of working hardware and software in various stages, but after a few years I grew to like the idea of reducing the project complexity (in size and moving parts). In 2017 I was off sick for a few days and ended up binge watching a bunch of Techmoan, LGR and The 8-Bit Guy videos, which seeded in me the idea of using floppy disks. This meant I could remove the RFID tags and reader, and read and write Spotify URIs directly to the disks! Much simpler, and the hardware did not need any construction. A simple USB floppy disk drive and a Raspberry Pi would do the trick.
As the hardware and the floppy disk case are all matte black I thought I would use colour floppy disks with a black shutter to brighten the project up a bit. I found all my disks on eBay, with an average price of around 1 per disk.
My first iteration used Mopidy as a local music server, in conjunction with the Mopidy-Spotify extension. However at some point in last few years, Spotify deprecated the libspotify libary used by the extension, resulting in a loss of functionality:
Spotifyd in turn makes use of librespot which is essentially an open source alternative to libspotify written in Rust. It looks like the people behind librespot have reverse engineered the Spotify Connect protocol.
The configuration is very simple, a single file located at /etc/spotifyd.conf and then the installation of a systemd unit file so that it can be run as a service after boot. This is all well documented in the project README:
I am using the shell script below to act on floppy disk change events. The script checks if the device is listed as part of the attached block devices (lsblk). If it is, this means that a new disk has been inserted. The disk is mounted to a fixed location on the filesystem, the Spotifyd service is started, and the contents of diskplayer.contents file in the mounted folder are used as an argument to the diskplayer player application. The device is then unmounted from the filesystem.
If there is no device listed in the output from lsblk then we assume that a floppy disk was removed. The script then invokes the diskplayer player application with a pause command, and stops the Spotifyd service.
Very early on, we decided that the main problem we were trying to solve was to help engineers (when using technical documentation) go from stuck to unstuck, and fast. This became our guiding principle. Is what we are building helping engineers get unstuck faster? From this, it follows that we need to promote quality documentation on the one hand, and provide a high level of discoverability on the other. One without the other is not going to cut it.
What we want to build is a thriving community of technical documentation creators, contributors, and readers. We want this because, we believe, this is the way to drive up the quality of the documentation. More readers, more feedback, more doc updates. And driving up the quality of the corpus of technical documentation leads to trust which in turn leads to more engagement and, hence, more of a thriving community.
3a8082e126