NotShazam – Shazam-Algorithmus in Go neu umgesetzt

 (github.com/cgzirim)
3 Punkte von GN⁺ 2024-08-02 | 1 Kommentare | Auf WhatsApp teilen
  • SeekTune ist ein Projekt, das den Songerkennungs-Algorithmus von Shazam implementiert und Spotify- sowie YouTube-APIs integriert, um Songs zu finden und herunterzuladen
  • Für die Ausführung werden Golang, FFmpeg, NPM und YT-DLP benötigt; Server und Client können per Docker Compose oder in einer nativen Umgebung betrieben werden
  • Die Spotify-Integration erfolgt, indem Client ID und Client Secret einer Developer-App in server/.env gesetzt werden; die App ruft die benötigten Access Tokens automatisch ab und cached sie
  • Die Standarddatenbank ist SQLite; wenn per Umgebungsvariable DB_TYPE=mongo angegeben wird, kann MongoDB genutzt werden. Ohne Benutzername und Passwort wird eine Verbindung zu mongodb://localhost:27017 hergestellt
  • Die CLI unterstützt das Herunterladen über Spotify-Links, das Speichern lokaler Audiodateien, das Matching von Aufnahmen sowie das Löschen von Fingerprints und Songs; gespeicherte Einträge ohne YouTube-ID werden im Frontend nicht als Matching-Ergebnisse angezeigt

Projektüberblick

  • SeekTune ist eine Anwendung, die den Songerkennungs-Algorithmus von Shazam implementiert
  • Die Implementierung basiert auf den Materialien im Ressourcenabschnitt der README
  • Durch die Integration von Spotify- und YouTube-APIs können Songs gefunden und heruntergeladen werden
  • Links zu Demo und Entstehungsprozess werden bereitgestellt

Installation und Ausführung

  • Benötigte Tools sind Golang, FFmpeg, NPM und YT-DLP

  • Der Befehl zum Klonen des Repositorys lautet:

    git clone https://github.com/cgzirim/seek-tune.git
cd seek-tune

  • Spotify-API einrichten

    • Man muss eine Spotify-App erstellen und Client ID sowie Client Secret erhalten
    • Im Verzeichnis server eine .env-Datei erstellen und die folgenden Werte setzen
    SPOTIFY_CLIENT_ID=your-client-id
SPOTIFY_CLIENT_SECRET=your-client-secret
    • Die App ruft die benötigten Access Tokens automatisch ab und cached sie

  • Ausführung mit Docker

    • Docker und Docker Compose werden benötigt
    • Build und Start erfolgen mit folgendem Befehl
    docker-compose up --build
    • Nach dem Start ist die App unter http://localhost:8080 erreichbar
    • Zum Stoppen folgenden Befehl verwenden
    docker-compose down

  • Native Ausführung

    • Backend-Abhängigkeiten installieren
    cd server
go get ./...
    • Client-Abhängigkeiten installieren
    cd client
npm install

CLI-Nutzung

  • Die Client-App wird im Verzeichnis client gestartet 
    npm start
  • Das Backend wird in einem separaten Terminal gestartet 
    cd server
go run *.go serve [-proto <http|https> (default: http)] [-port <port number> (default: 5000)]
  • Songs können über Spotify-Links heruntergeladen werden 
    go run *.go download <https://open.spotify.com/.../...>;
    • Aus der Spotify-Mobile-App kopierte Links funktionieren nicht
    • Links aus der Desktop- oder Web-App können verwendet werden
  • Lokale Songdateien oder Verzeichnisse können in der Datenbank gespeichert werden; alle Audioformate werden unterstützt 
    go run *.go save [-f|--force] <path_to_song_file_or_dir_of_songs>
    • -f oder --force speichert den Song auch dann, wenn keine YouTube-ID gefunden wird
    • Ohne YouTube-ID zeigt das Frontend das Matching nicht an
  • Für Songs oder Aufnahmedateien kann ein Matching gesucht werden 
    go run *.go find <path-to-wav-file>
  • Das Löschen von Fingerprints und Songs wird unterstützt 
    go run *.go erase
go run *.go erase db
go run *.go erase all
    • Standardmäßig wird nur die Datenbank gelöscht
    • erase all löscht die Datenbank zusammen mit den Songdateien
  • Wenn *.go nicht funktioniert, kann ./... verwendet werden

Beispielausgabe

  • Das Download-Beispiel ruft zunächst die Spotify-Trackinformationen ab, lädt dann den Track herunter und speichert die Fingerprints 
    $ go run *.go download https://open.spotify.com/track/4pqwGuGu34g8KtfN8LDGZm/…
Getting track info...
Now, downloading track...
Fingerprints saved in MongoDB successfully
'Voilà' by 'André Rieu' was downloaded
Total tracks downloaded: 1
  • Das Matching-Beispiel gibt für Voilà - André Rieu.wav die Top-20-Matches und die finale Vorhersage aus
    • Das beste Ergebnis ist Voilà by André Rieu mit einem Score von 5390686.00
    • Die Suchzeit wird mit 856.386557ms angezeigt
    • Auch die finale Vorhersage wird als Voilà by André Rieu angezeigt

Datenbankauswahl

  • Die Standarddatenbank ist SQLite
  • Um MongoDB zu verwenden, MongoDB installieren und die Verbindungs-Umgebungsvariablen setzen
    • DB_TYPE: für die Nutzung von MongoDB auf "mongo" setzen
    • DB_USER: MongoDB-Benutzername
    • DB_PASS: MongoDB-Passwort
    • DB_NAME: Name der zu verwendenden MongoDB-Datenbank
    • DB_HOST: Hostname oder IP-Adresse des MongoDB-Servers
    • DB_PORT: Portnummer des MongoDB-Servers
  • Die Datenbank-Verbindungs-URI wird aus Umgebungsvariablen zusammengesetzt
  • Wenn DB_USER oder DB_PASS fehlen, wird standardmäßig eine Verbindung zu mongodb://localhost:27017 hergestellt

Referenzen und Lizenz

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-02
Meinungen auf Hacker News

  • Ein Teil der Shazam-Technologie entstand am CCRMA auf dem Stanford-Campus, einem besonderen Ort, der auch eng mit der frühen Computergeschichte verbunden ist.
    Interessant ist, dass Anwendungen früher Computertechnik auffallend oft mit Audio zu tun hatten. Die Beispiele reichen von John Bardeens Musikbox über Hörgeräte als erste kommerzielle Anwendung des Transistors, die Audio-Oszillatoren aus der HP-Garage in Palo Alto, das iPhone, das aus dem iPod hervorging, das Internet, das auf Kupferleitungen aufgebaut wurde, die einst analoge Telefonleitungen trugen, bis hin zu den Bell Labs.
    Vielleicht klingt auch die Hypothese recht reizvoll, dass Menschen zuerst lernen, mit dem kHz-Bereich umzugehen, bevor sie in den MHz-/GHz-Bereich wechseln.

    • Ich denke, das liegt daran, dass Audio vergleichsweise einfach elektronisch zu manipulieren ist.
      Audiosignale lassen sich relativ leicht in elektrische Signale umwandeln, während Grafik schon dadurch viel komplexer ist, dass man sie überhaupt auf einem Bildschirm sichtbar machen muss. Auch ein Lautsprecher, der elektrische Signale in Schallwellen umwandelt, ist, wenn man nur die Kernstruktur betrachtet, ein sehr einfaches Gerät.
      Außerdem hinterlässt Audio beim Menschen einen starken Eindruck; wenn ich also die Leistungsfähigkeit von Elektronik oder Computern demonstrieren wollte, hätte ich wohl ebenfalls Audio gewählt.
    • Das wirkt wie eine ziemlich erzwungene Verbindung.

  • Wenn das wirklich eine Nachbildung von Shazam ist, könnte es zumindest bis März 2025 unter einem Apple-Patent stehen: https://patents.google.com/patent/US7627477

    • Das Paper „An Industrial-Strength Audio Search Algorithm“ (https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf), in dem Shazam den Algorithmus beschreibt, hat kein klares Veröffentlichungsdatum, aber nach https://www.researchgate.net/publication/220723446_An_Industrial_Strength_Audio_Search_Algorithm scheint es ein Paper von 2003 zu sein.
      Das betreffende Patent wurde in den USA am 21.10.2004 angemeldet. Ich bin kein Rechtsexperte, aber in den USA könnte das wohl als Grundlage gegen dieses Patent dienen.
    • Ich erinnere mich, dass Shazam vor etwa zehn Jahren auf HN einmal mit rechtlichen Schritten gegen die Veröffentlichung des Algorithmus gedroht hatte und daraufhin ein populärer Beitrag oder Quellcode entfernt wurde.
      Vermutlich war der Google-Drive-PDF-Screenshot im Originalartikel genau dieses Material.
    • Im Kern geht es darum, aus der schnellen Fourier-Transformation des Audiosignals einen einfachen Fingerprint zu erstellen und dann einen einfachen Index sowie eine einfache Ähnlichkeitssuche zu verwenden.
      Damit diese Methode funktioniert, braucht man allerdings Signaturen für sämtliche Musik der Erde ;)
    • Das bedeutet also, dass es außerhalb der USA schwer durchzusetzen ist.
    • Mit anderen Worten: Jetzt das Repository klonen.

  • Der Vortrag von Shazam-Mitgründer Avery Wang auf der DAFx17 war gut.
    Er behandelt etwas den theoretischen Hintergrund des Algorithmus und schaut sich auch praktische Probleme wie Hintergrundrauschen an: https://www.youtube.com/watch?v=YVTnj3OIhwI

    • Das kommt auf meine Watchlist. Als ich dieses Paper gelesen habe, war das einer der ersten Momente, in denen ich bei Computing-Algorithmen wirklich wow dachte.

  • In letzter Zeit scheint die Genauigkeit von Shazam nachgelassen zu haben, und SoundHound liefert eher bessere Ergebnisse.
    Bei Shazam bekomme ich viele Ergebnisse aus asiatischen Musiktraditionen, was an sich gut ist; das Problem ist nur, dass es die falschen Stücke sind. Wenn der Umfang der auswählbaren Musik erweitert wurde, müsste wohl auch der Algorithmus verbessert werden, und im Moment fühlt es sich so an, als gäbe es mehr Hash-Table-Kollisionen.
    Siehe: https://github.com/cgzirim/not-shazam/…

    • SoundHound war Shazam schon immer überlegen. Es erkennt auch von Menschen gesungene Lieder oder sehr leise Stücke.
    • Im August 2021 habe ich die Musikerkennungsbibliotheken von Shazam, SoundHound und BeatFind verglichen.
      Mein Fazit war, dass BeatFind und Shazam die meisten Stücke kannten, sich aber auch gegenseitig ergänzten und jeder Dienst mindestens ein Stück hatte, das nur er erkannte.
      Im Test waren Stücke aus verschiedenen Genres und Bekanntheitsgraden gemischt, aber eine größere Stichprobe wäre besser gewesen. Außerdem habe ich keine Störgeräusche wie menschliche Sprache oder gefilterte Musik getestet, die durch eine Wand zu hören ist.
      Interessanterweise wurde „Night Driver“ als „1 Shazams“ angezeigt, sodass ich vermutlich die erste Person war, die es mit Shazam erkannt hat, und bei „THEY'RE TAKING THE HOBBITS TO ISENGARD!“ wissen zwar alle, wohin sie die Hobbits bringen, aber keiner der Dienste hat es erkannt.

  • Das Projekt sieht so aus, als ließe es sich gut nutzen und anpassen, aber persönlich finde ich, dass es für eine Veröffentlichung noch etwas zu früh ist.
    Die Anleitung zur Ausführung wirkt ungenau, und MongoDB ist zwar erforderlich, aber Erklärungen zu Verbindung und Nutzung fehlen. Wenn möglich, wäre es besser, die DB austauschbar zu machen und eine weniger aufwendige Option wie sqlite anzubieten.
    Falls MongoDB nicht ersetzt werden kann, sollten Dockerfile und docker compose bereitgestellt werden, damit man es einfach ausführen und testen kann. Beim npm install des Clients werden 8 kritische Schwachstellen gemeldet; auch wenn sie in der Praxis vielleicht kein Problem sind, zögert man dadurch, weiterzutesten.
    Auch wenn man Patente oder Urheberrecht außer Acht lässt, wäre es besser, den Namen zu ändern. Da GitHub selbst in den USA sitzt, könnte das Projekt bei einer DMCA-Meldung entfernt werden.
    Zum Schluss wäre auch eine Funktion gut, mit der man Songs aus WAV-Dateien hinzufügen kann. Nicht jedes Audio, das ich testen möchte, ist auf Spotify oder YouTube.
    Ich will damit nicht entmutigen; aber wenn solche kleinen Feinschliffe fehlen, neigen Leute dazu, ein Projekt zu ignorieren oder geringer zu bewerten. Wenn ich Zeit habe, schicke ich vielleicht einen PR, und ich möchte Audio-Matching außerhalb von Musik ausprobieren; dieses Projekt sieht dafür am leichtesten anpassbar aus.

    • Ich stimme zu, dass das Projekt mehr Feinschliff braucht.
      Ich werde die Konfigurationsanleitung verbessern und priorisiert prüfen, eine dateibasierte DB für mehr Flexibilität hinzuzufügen sowie die npm-Schwachstellen zu beheben. Die direkte Fingerprinting-Funktion für WAV-Dateien ist ebenfalls eine gute Idee; darum werde ich mich vorrangig kümmern.
      Das rechtliche Risiko des Projektnamens verstehe ich ebenfalls und werde ihn ändern. Falls jemand gute Namensvorschläge hat, gerne her damit.
    • Genau für solch wertvolles Feedback postet man auf HN. Gute Zusammenfassung.

  • Ich habe mir das Repository noch nicht im Detail angesehen, aber ich frage mich, woher die Daten kommen, in denen gesucht wird.
    Wird eine Bibliothek geladen, oder wird eine irgendwo beschaffte große Bibliothek durchsucht?

    • Die Daten kommen aus einer Fingerprint-Datenbank, die mit dem Server verbunden ist. Jedes Mal, wenn ein Song hinzugefügt wird, werden solche Fingerprints erstellt.

  • So etwas wollte ich schon immer mal bauen; das stand auf meiner Bucket List. Wirklich cool.

    • Freut mich, dass es dich inspiriert hat. Du kannst es gern klonen und weiterentwickeln.

  • Es wäre ziemlich gut, wenn es eine Möglichkeit gäbe, Fingerprints community-basiert zu teilen.

    • Schön wäre so etwas nicht nur für Audio, sondern auch für Bilder und Videoclips.
      Soweit ich mich erinnere, nutzt BitTorrent eine Distributed Hash Table, aber die Hashes beziehen sich auf den gesamten Inhalt und sind daher nicht besonders nützlich, um das Original von abgeleiteten Werken mit miserabler Quellenangabe zu finden.
      Für die Suche nach Bild-Originalen ist Tineye gelegentlich brauchbar.
    • MusicBrainz scheint das zu unterstützen: https://musicbrainz.org/doc/AcoustID

  • Wenn man Spotify-Songs eingibt, wäre es dann nicht natürlicher, als Ergebnis ebenfalls Spotify-Songs auszugeben?

    • Genau genommen ja. Allerdings erlaubt Spotify keine direkten Downloads, deshalb musste ich die Songs auf YouTube suchen und von dort herunterladen.

  • Google-Smartphones haben eine eingebaute Musikerkennung, und ich habe gehört, dass sie in diesem Bereich am besten umgesetzt ist.
    Ich frage mich, ob jemand weiß, welchen Ansatz sie verwendet haben. Unabhängig davon fand ich SoundHound immer besser als Shazam.

    • Aus der Erinnerung gab es wohl einen kleinen Algorithmus oder ein Stück Hardware, das nur aufwacht, wenn Musik läuft.
      Dadurch muss das Smartphone nicht ständig aktiv sein, und danach hätte man wahrscheinlich jeden bestehenden Erkennungsalgorithmus verwenden können. Für mich wirkte diese Ultra-Low-Power-Stufe wie Magie, aber ich habe die Details nie nachgelesen.