NotShazam — l’algorithme de Shazam réimplémenté en Go

(github.com/cgzirim)

3 points par GN⁺ 2024-08-02 | 1 commentaires | Partager sur WhatsApp

SeekTune est un projet qui implémente l’algorithme de reconnaissance de chansons de Shazam, en intégrant les API Spotify et YouTube pour permettre de trouver et télécharger des morceaux
Son exécution nécessite Golang, FFmpeg, NPM et YT-DLP ; le serveur et le client peuvent être lancés via Docker Compose ou dans un environnement natif
L’intégration Spotify se fait en configurant le Client ID et le Client Secret de l’application développeur dans server/.env ; l’application récupère et met automatiquement en cache les jetons d’accès nécessaires
La base de données par défaut est SQLite ; MongoDB peut être utilisé en définissant DB_TYPE=mongo comme variable d’environnement, et en l’absence d’utilisateur ou de mot de passe, la connexion se fait à mongodb://localhost:27017
La CLI prend en charge le téléchargement depuis des liens Spotify, l’enregistrement d’audio local, la correspondance de fichiers enregistrés, ainsi que la suppression des empreintes et des chansons ; les éléments enregistrés sans ID YouTube ne s’affichent pas comme résultats de correspondance dans le frontend

Présentation du projet

SeekTune est une application qui implémente l’algorithme de reconnaissance de chansons de Shazam
L’implémentation s’appuie sur les ressources indiquées dans la section dédiée du README
Elle intègre les API Spotify et YouTube afin de trouver et télécharger des chansons
Des liens vers une démo et vers le processus de création sont fournis
- Demo in Video
- How it was made (YouTube)

Installation et modes d’exécution

Les outils requis sont Golang, FFmpeg, NPM et YT-DLP

La commande de clonage du dépôt est la suivante

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

Configuration de l’API Spotify
- Il faut créer une application Spotify et obtenir un Client ID ainsi qu’un Client Secret
- Créer un fichier .env dans le répertoire server et définir les valeurs suivantes
```
SPOTIFY_CLIENT_ID=your-client-id
SPOTIFY_CLIENT_SECRET=your-client-secret
```
- L’application récupère et met automatiquement en cache les jetons d’accès nécessaires
Exécution avec Docker
- Docker et Docker Compose sont nécessaires
- La compilation et l’exécution se font avec la commande suivante
```
docker-compose up --build
```
- Après le lancement, l’application est accessible à l’adresse http://localhost:8080
- Pour l’arrêter, utiliser la commande suivante
```
docker-compose down
```
Exécution native
- Installation des dépendances du backend
```
cd server
go get ./...
```
- Installation des dépendances du client
```
cd client
npm install
```

Utilisation de la CLI

L’application cliente se lance depuis le répertoire client
```
npm start
```

Le backend se lance dans un terminal séparé

cd server
go run *.go serve [-proto <http|https> (default: http)] [-port <port number> (default: 5000)]

Il est possible de télécharger une chanson à partir d’un lien Spotify
```
go run *.go download <https://open.spotify.com/.../...>;
```
- Les liens copiés depuis l’application mobile Spotify ne fonctionnent pas
- Il est possible d’utiliser les liens copiés depuis l’application desktop ou web
Il est possible d’enregistrer dans la base de données un fichier musical local ou un répertoire, avec prise en charge de tous les formats audio
```
go run *.go save [-f|--force] <path_to_song_file_or_dir_of_songs>
```
- -f ou --force enregistre la chanson même si aucun ID YouTube n’est trouvé
- Sans ID YouTube, le frontend n’affiche pas la correspondance
Il est possible de trouver une correspondance pour une chanson ou un fichier enregistré
```
go run *.go find <path-to-wav-file>
```
La suppression des empreintes et des chansons est prise en charge
```
go run *.go erase
go run *.go erase db
go run *.go erase all
```
- Par défaut, seule la base de données est supprimée
- erase all supprime à la fois la base de données et les fichiers de chansons
Si *.go ne fonctionne pas, ./... peut être utilisé

Exemple de sortie

L’exemple de téléchargement récupère les informations du titre Spotify, télécharge ensuite le morceau et enregistre les empreintes

$ 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

L’exemple de correspondance affiche les 20 meilleures correspondances et la prédiction finale pour Voilà - André Rieu.wav
- Le meilleur résultat est Voilà by André Rieu, avec un score de 5390686.00
- Le temps de recherche affiché est 856.386557ms
- La prédiction finale est également affichée comme Voilà by André Rieu

Choix de la base de données

La base de données par défaut est SQLite
Pour utiliser MongoDB, installer MongoDB et définir les variables d’environnement de connexion
- DB_TYPE : définir sur "mongo" pour utiliser MongoDB
- DB_USER : nom d’utilisateur MongoDB
- DB_PASS : mot de passe MongoDB
- DB_NAME : nom de la base de données MongoDB à utiliser
- DB_HOST : nom d’hôte ou adresse IP du serveur MongoDB
- DB_PORT : numéro de port du serveur MongoDB
L’URI de connexion à la base de données est construite à partir des variables d’environnement
Si DB_USER ou DB_PASS est absent, la connexion se fait par défaut à mongodb://localhost:27017

Ressources et licence

How does Shazam work - Coding Geek : ressource principale
Song recognition using audio fingerprinting
How does Shazam work - Toptal
Creating Shazam in Java
Le projet est distribué sous MIT License

1 commentaires

GN⁺ 2024-08-02

Avis de Hacker News

Une partie de la technologie de Shazam vient du CCRMA sur le campus de Stanford, un lieu particulier étroitement lié aux débuts de l’histoire de l’informatique
Il est intéressant de constater que les applications des premières technologies informatiques ont été étonnamment souvent liées à l’audio. Les exemples s’enchaînent : la boîte à musique de John Bardeen, l’aide auditive qui fut la première application commerciale du transistor, l’oscillateur audio fabriqué dans le garage HP de Palo Alto, l’iPhone dans la continuité de l’iPod, Internet bâti sur les fils de cuivre qui transportaient les lignes téléphoniques analogiques, jusqu’aux Bell Labs
L’hypothèse selon laquelle les humains apprennent peut-être d’abord à maîtriser le domaine des kHz avant de passer aux domaines MHz/GHz paraît assez séduisante
- C’est sans doute parce que l’audio est relativement facile à manipuler électroniquement
  Un signal audio peut être converti assez facilement en signal électrique, alors que pour les graphismes, le simple fait de les rendre visibles sur un écran est déjà bien plus complexe. Un haut-parleur, qui transforme un signal électrique en onde sonore, est aussi un dispositif très simple si l’on regarde sa structure essentielle
  En plus, l’audio marque fortement les gens ; donc si je voulais montrer la puissance de l’électronique ou de l’informatique, j’aurais moi aussi choisi l’audio
- Ça ressemble à une interprétation vraiment forcée
Si c’est une vraie reproduction de Shazam, cela pourrait être couvert par un brevet Apple au moins jusqu’en mars 2025 : https://patents.google.com/patent/US7627477
- L’article de Shazam décrivant l’algorithme, “An Industrial-Strength Audio Search Algorithm” (https://www.ee.columbia.edu/~dpwe/papers/Wang03-shazam.pdf), n’a pas de date de publication claire, mais d’après https://www.researchgate.net/publication/220723446_An_Industrial_Strength_Audio_Search_Algorithm, il semble s’agir d’un article de 2003
  Le brevet en question a été déposé aux États-Unis le 21/10/2004. Je ne suis pas juriste, mais cela pourrait constituer un élément défavorable à ce brevet aux États-Unis
- Je me souviens qu’il y a environ dix ans, sur HN, Shazam avait menacé juridiquement la publication de l’algorithme, et qu’un billet populaire ou du code source avait été retiré
  Je crois que la capture du PDF Google Drive dans l’article original correspondait à ce document
- L’idée centrale consiste à créer une empreinte simple à partir de la transformée de Fourier rapide du signal audio, puis à utiliser un index simple et une recherche de similarité simple
  Mais pour que cette méthode fonctionne, il faut disposer des signatures de toute la musique sur Terre ;)
- Donc cela veut dire que ce serait difficile à faire appliquer en dehors des États-Unis
- Autrement dit, il faut cloner le dépôt maintenant
La présentation du cofondateur de Shazam, Avery Wang, à DAFx17 était excellente
Elle aborde un peu les bases théoriques de l’algorithme et examine aussi des problèmes réels comme le bruit de fond : https://www.youtube.com/watch?v=YVTnj3OIhwI
- Je l’ajoute à ma liste de vidéos à regarder. La lecture de cet article a été l’un de mes premiers moments waouh avec les algorithmes de calcul
J’ai l’impression que la précision de Shazam a baissé récemment, et que SoundHound donne au contraire de meilleurs résultats
Shazam renvoie beaucoup de résultats issus des traditions musicales asiatiques, ce qui est bien en soi, mais le problème est que ce ne sont pas les bons morceaux. S’ils ont élargi le périmètre musical pris en compte, il faudrait aussi améliorer l’algorithme ; pour l’instant, j’ai l’impression qu’il y a davantage de collisions de tables de hachage
Référence : https://github.com/cgzirim/not-shazam/…
- SoundHound a toujours été meilleur que Shazam. Il reconnaît aussi les chansons chantées par quelqu’un ou les morceaux très peu audibles
- En août 2021, j’ai comparé les bibliothèques de reconnaissance musicale de Shazam, SoundHound et BeatFind
  Ma conclusion était que BeatFind et Shazam connaissaient le plus grand nombre de morceaux, mais qu’ils étaient aussi complémentaires, et que chaque service avait au moins un morceau qu’il était le seul à reconnaître
  Le test mélangeait plusieurs genres et niveaux de notoriété, mais un échantillon plus large aurait été préférable. Je n’ai pas non plus testé les bruits comme des voix humaines, ni la musique filtrée entendue à travers un mur
  Fait amusant, “Night Driver” affichait “1 Shazams”, donc j’étais probablement la première personne à l’avoir shazamé, tandis que pour “THEY'RE TAKING THE HOBBITS TO ISENGARD!”, tout le monde sait où ils emmènent les hobbits, mais aucun des services ne l’a reconnu
Le projet a l’air agréable à utiliser et à modifier, mais personnellement je pense qu’il est encore un peu tôt pour le publier
Les instructions d’exécution semblent imprécises, et MongoDB est nécessaire mais les explications sur la connexion et l’utilisation manquent. Si possible, il vaudrait mieux rendre la base de données interchangeable et proposer une option moins contraignante, comme sqlite
Si MongoDB ne peut pas être remplacé, il faudrait fournir un Dockerfile et docker compose pour pouvoir l’exécuter et le tester facilement. Côté client, npm install signale 8 vulnérabilités critiques ; même si ce n’est peut-être pas réellement problématique, ça fait hésiter à poursuivre les tests
Même sans se soucier des brevets ou du droit d’auteur, il vaudrait mieux changer le nom. GitHub étant lui-même aux États-Unis, le projet pourrait être retiré en cas de demande DMCA
Enfin, ce serait bien d’avoir aussi une fonction pour ajouter un morceau à partir d’un fichier WAV. Tous les audios que je veux tester ne sont pas sur Spotify ou YouTube
Je ne dis pas ça pour décourager, mais quand ces petites finitions manquent, les gens ont facilement tendance à ignorer un projet ou à le sous-estimer. Si j’ai le temps, je pourrai peut-être envoyer une PR, et comme j’aimerais expérimenter la correspondance audio dans des domaines autres que la musique, ce projet me semble être le plus facile à modifier
- Je suis d’accord qu’il faut davantage de travail de finition sur le projet
  Je vais améliorer les instructions de configuration, donner la priorité à l’ajout d’une base de données basée sur des fichiers pour plus de flexibilité, ainsi qu’à la résolution des vulnérabilités npm. La possibilité de générer directement des empreintes depuis des fichiers WAV est aussi une bonne idée, je vais regarder ça en priorité
  J’ai bien compris le risque juridique lié au nom du projet et je compte le changer. Si vous avez de bonnes suggestions de nom, je suis preneur
- C’est pour recevoir ce genre de retours précieux que je poste sur HN. Bonne synthèse
Je n’ai pas encore regardé le dépôt en détail, mais je me demande d’où viennent les données qui servent de cible à la recherche
Est-ce qu’il charge une bibliothèque, ou bien est-ce qu’il interroge une grosse bibliothèque récupérée quelque part ?
- Les données viennent de la base de données d’empreintes connectée au serveur. Ces empreintes sont créées à chaque ajout de morceau
J’avais ça sur ma bucket list, j’ai toujours voulu construire un truc de ce genre, c’est vraiment génial
- Ravi que ça t’inspire. N’hésite pas à le cloner et à l’améliorer
Ce serait assez intéressant s’il y avait une manière de partager les empreintes de façon communautaire
- Ce serait bien d’avoir ce genre de mécanisme non seulement pour l’audio, mais aussi pour les images et les clips vidéo
  Si je me souviens bien, BitTorrent utilise une table de hachage distribuée, mais les hachages portent sur le contenu entier ; ce n’est donc pas très utile pour retrouver l’original d’œuvres dérivées dont l’attribution est mal faite
  Pour retrouver l’image d’origine, Tineye est parfois utile
- MusicBrainz semble prendre ça en charge : https://musicbrainz.org/doc/AcoustID
Si on fournit des morceaux Spotify, ne serait-il pas plus naturel que le résultat sorte aussi sous forme de morceau Spotify ?
- En fait, oui. Mais Spotify ne permet pas le téléchargement direct, donc il a fallu trouver le morceau sur YouTube et le télécharger depuis là
Les téléphones Google ont une fonction intégrée de reconnaissance musicale, et j’ai entendu dire que c’était l’une des meilleures implémentations dans ce domaine
Je me demande si quelqu’un sait quelle approche ils ont utilisée. À part ça, j’ai toujours eu l’impression que SoundHound était meilleur que Shazam
- De mémoire, il me semble qu’il y avait un petit algorithme ou morceau de matériel qui ne réveillait le système que lorsque de la musique était en cours de lecture
  Ainsi, le téléphone n’avait pas besoin d’être actif en permanence, et ensuite n’importe quel algorithme de détection existant pouvait probablement prendre le relais. Pour moi, cette étape à très basse consommation avait quelque chose de magique, mais je n’en ai jamais lu les détails