Spotify Codes – Part 2 | Hacker News Reader

Spotify Codes – Part 2

boonepeter.github.io

126 pointshealeycodes16 comments

I personally would just prefer a QR code that uses the spotify URI. At least there are open source scanners that would read them.

QR codes are big ugly squares, so I can understand why some popular apps decide to roll their own.

But it certainly makes them way less convenient and universal. Can’t just open your camera app.

It took me maybe 45 seconds just now to find the scanning feature in Spotify, in a real world situation I probably would have given up and just used search after about 10 seconds.

The do have to be big, they do have to be squares (in terms of general shape), but ugly? Actually no! Check this out: https://qr-code-styling.com/

I've used this for a project where we wanted QR codes that fit a particular color theme. As long as you maintain a certain amount of contrast between the code and the background (and test your work, this is very much "you break it you fix it" territory) you can have rounded dots, rounded corner dots, colors (even gradients!) and an arbitrary image in the center.

Again, you need to try out this library with whatever design you're intending, and if you push some of the parameters too far you'll lose certain QR scanners, but the spec is way more flexible than most people know.

Beauty is subjective, of course, but for me at least, these stylized QRs don't look _much_ better than regular ones. And may make it harder for recognition too, for customers used to the big ugly squares-on-squares format

> And may make it harder for recognition too

Compared to a standard QR code sure, but I've seen these Spotify codes plenty of times and just thought they were decoration until this link.

I wish QR codes were just 3-point simplices with barycentric triangle pixels. That ought to be enough. You could even shape the QR triangle any way (affine transform) you like, at the risk of readability of course.

I had no idea how far you could push a QR code. Like, you could make the corner markers round, and it still scans just fine.

Moreover, QR Codes can convey full URLs and text payloads, whereas proprietary app codes (Spotify / Snapchat / Facebook Messenger (retired?) / etc.) can only hold maybe 100 bits, which is only enough to have a unique ID that you must query the server to be useful in any way.

The code has a CRC code embedded. Why is it that every article mentioning CRC codes brings up that you can write them as polynomials? AFAICT it never makes a difference in implementation. What am I missing?

I think it is easier to extend a polynomial multiplication (known concept) with a finite field than to directly introduce a carryless multiplication. Also there are multiple different bitwise representations for the same polynomial, so separating them might avoid some confusion.

Thanks. I suppose that there is value in expressing the operations in a form that all agree is well defined.

That bitwise XOR is polynomial addition (and subtraction) in F_2[x] (polynomials with coefficients mod 2)?

More immediately, it’s about the only way to unambiguously write which polynomial you mean, independent of endianness and similar notational issues. (The error correction properties don’t care about the way you arranged the bitstream into bytes or words.)

But I find the knowledge that I am just implementing long division helpful, too. I did transcribe the beast mindlessly from a reference book a couple of times before I got it, but debugging it that way is pure hell.

Has anyone found any similar information on Apple's codes used for App Clips? They are round, with five concentric circles formed of dashes.

I've been googling, but can't find any analysis of their structure.

There haven't been any analysis to the best of my knowledge.

I saw some Twitter threads early on with people trying to figure it out but those efforts seemed to have died out.

Apple's code is a simple circular barcode, essentially. I worked in one such format long time ago (ShotCode) - they have some benefits like resistance to motion blur and being easy to parse in low res cameras (compared to qr codes, for instance), but can't encode a lot of data (main drawback). ShotCode's reading algo is proprietary, like Apple's, but they're rather simple to implement.

some analysis here: https://www.xeraina.ch/reports/P6_2015_Circular_Codes.pdf

Great closure from Peter, wish he'd take on Apple's App Clip codes as well. They look like those absolute quadrature encoders with rounded edges.

Even making QR codes fill up a circular shape with noise & rotating it by 45 degrees[for those 3 smaller square markers to line up well] would make it more appealing.

Reply on news.ycombinator.com