I Recreated Shazam's Algorithm with Go

Shazam's technology came in part out of CCRMA, which is a very cool and special place on Stanford Campus, with deep connections to early computer history.

I think it is very interesting that so many of the early applications of computer technology have to do with audio. John Bardeen's music box, the first commercial application of the transistor in hearing aids, the HP garage in Palo Alto was originally building audio oscillators, the iPhone evolved from the iPod, the internet was built on copper made to carry analog telephone calls, Bell Labs (ping!), the list goes on.

A friend of mine has the hypothesis that maybe human beings end up figuring out how to do kHz stuff before they go on to do MHz/GHz stuff. Not a perfect explanation but kind of attractive...

FYI - If this is a true reproduction of Shazam, it’s under patent by Apple through at least March 2025[1].

[1] https://patents.google.com/patent/US7627477

I enjoyed this talk at the DAFx17 conference by Avery Wang, co-founder of Shazam. It goes a little into the theory behind the algorithm, and looks at some of the more practical issues (background noise, etc.): https://www.youtube.com/watch?v=YVTnj3OIhwI

Recently found Shazam is less accurate - somehow soundhound is giving me better results. On Shazam I'm getting a lot of results from Asian musical traditions which is great, if it wasn't the wrong song. Maybe they need to improve the algo if they've increased the range of music they will select from? Seems now there's a lot more hash table collision[1].

  [1] https://github.com/cgzirim/not-shazam?tab=readme-ov-file#resources--card_file_box

While the project does look nice to use and modify. I'm not sure I personally would have posted it yet.

- The instructions seem not to be the best to get it up and running (e.g. "cd not-shazam" and just a few lines later "cd not-shazam/client")

- MongoDB is needed but information on how to hook it up/use it are absent (I would make the DB swapable and provide something less intrusive like sqlite)

- If replacing MongoDB is not possible, I would provide a dockerfile and a docker compose to allow easy startup and testing.

- The client npm install has 8 critical vulnerabilities, these might not actually matter but it makes me hesitant to continue testing

- You might not care about the patent or the copyright, but I would still change the name at the very least. Github itself is located in the US and will remove the project if they receives a DMCA.

- Last, this might not be as important, I would add a way to add songs from wav files. Not everything I'd want to test this with is on spotify or youtube.

I'm not saying this to discourage you or anything, I just think the project needs that little extra bit of polish. Minor things will cause people to discredit or ignore a project. If I get around to it I might make a PR for the project. I want to experiment with audio matching outside of the music space, and your project seems like it'll be the easiest to modify.

Edit: Formatting

Haven't crawled through the repo (yet) but quick question - where does the data that is being searched over come from? Are you loading a library or searching some large library acquired from somewhere else?

This is really cool. I’ve been itching to try building this exact kind of thing as part of my bucket list.

It would be quite nice if there were a community-based way of sharing fingerprints.

If you insert Spotify songs, wouldn't it make more sense to output Spotify songs too?

I’ve heard that the Google phones have a built in music recognition feature that is the best implementation of this stuff. Anyone know what their approach was? Apart from that I always have felt Soundhound was better than Shazam

This is useless unless you have all the songs on earth

Algorithm don't matter, only data matters

This is cool, but you urgently need to change the name.

Isn’t the whole point of Shazam that you don’t know the song and want to find it? If you don’t know the song, hoeven you provide a Spotify link?

Shazam is historically interesting, but Google's "hum to search" algorithm is far superior, and even that is nearly four years old (since production).

I wonder how long until someone will simply smoosh a billion songs into a "large song model" and make all signal processing knowledge irrelevant.

I'd love a way to use local files instead of spotify/youtube to create the set of fingerprints that is searched.

Run it as a daemon that displays every song in a UI notification ?

really decent and nicely done Golang! I'll pull and play with it tomorrow!

I think you've leaked your developer key here... https://github.com/cgzirim/not-shazam/blob/main/spotify/yout...

Hardcoded sleeps for some reason, nice /s

https://github.com/cgzirim/not-shazam/blob/888070f3434acbc0a...

I enjoyed reading the Go source. As opposed to the time I had to read some Ruby code.