AudioMuse-AI : analyse sonore et playlists pour Navidrome, Jellyfin, LMS, Emby et Plex

Le problème : des métadonnées pauvres, une bibliothèque qui dort

La plupart des serveurs musicaux auto-hébergés classent par tags. Artiste, album, année, genre. Ces champs suffisent tant que la bibliothèque est petite et bien rangée. Dès qu'elle grossit, ils deviennent un filtre grossier : deux morceaux étiquetés « ambient » peuvent n'avoir aucun rapport à l'oreille, et une compilation mal taguée disparaît des recommandations. AudioMuse-AI attaque le problème par l'autre bout. Le README annonce une analyse sonore qui ne dépend ni des métadonnées ni d'API externes, et qui sert ensuite à retrouver des morceaux oubliés et à produire des playlists. Le public visé est précis : des personnes qui font tourner Navidrome, Jellyfin, LMS, Lyrion, Emby ou Plex chez elles, avec des fichiers locaux, et qui veulent des regroupements fondés sur ce que la musique sonne, pas sur ce qu'elle prétend être. Le projet est distribué sous AGPL-3.0 et se présente comme auto-hébergé, avec une option d'hébergement managé chez Elestio pour ceux qui refusent de maintenir l'infrastructure.

Ce que l'analyse produit réellement

Le README énumère les fonctionnalités débloquées après une analyse initiale, et cette liste est le vrai descriptif du produit. Le clustering regroupe automatiquement les morceaux soniquement proches et produit des playlists qui traversent les genres. Les Instant Playlists acceptent une consigne en langage courant du type « high-tempo, low-energy music » et génèrent une sélection. La Music Map projette la collection sur une carte 2D. Playlist from Similar Songs part d'un titre et retrouve ceux qui partagent sa signature. Song Paths construit un trajet entre deux morceaux. Sonic Fingerprint s'appuie sur les habitudes d'écoute. Song Alchemy permet de marquer des titres comme ADD ou SUBTRACT pour orienter le résultat, avec un aperçu 2D et un export vers le serveur. Deux fonctions reposent sur le texte : Text Search, qui accepte des requêtes mêlant humeur, instruments et genre, et Lyrics Search, qui cherche par thème ou par récit. Cette dernière ne fonctionne que pour les 72 langues listées dans le README, ce qui est une contrainte à lire avant de compter dessus. Les briques techniques citées dans les topics du dépôt sont CLAP, librosa, ONNX et un LLM, ce qui donne une idée de la chaîne : extraction de caractéristiques audio, embeddings, puis interprétation de requêtes textuelles.

Architecture : Flask, workers, PostgreSQL et plus de Redis

Le dépôt décrit l'application comme un ensemble de conteneurs Flask et Worker, et le README renvoie vers docs/ARCHITECTURE.md et docs/ALGORITHM.md pour le détail. Un point de conception mérite l'attention : depuis la version 3.2.0, la file de traitement est implémentée sur PostgreSQL, ce qui rend Redis inutile. Le README invite explicitement à consulter le nouvel exemple docker-compose. C'est un choix qui simplifie le déploiement, mais qui déplace la charge sur la base de données : la file et les données applicatives vivent dans le même moteur, et dimensionner PostgreSQL devient une décision structurante plutôt qu'un détail. Depuis la version 3.0.0, un même déploiement peut connecter plusieurs serveurs de médias, dans n'importe quelle combinaison des six pris en charge. Une détection de doublons reconnaît un même morceau présent sur plusieurs serveurs, de sorte qu'il n'est analysé qu'une fois et que le résultat est partagé. Pour une bibliothèque répartie entre deux instances, c'est un gain de temps de calcul direct. Le README mentionne aussi un système de plugins tiers depuis la version 2.6.0, avec une contrainte nette : il faut un volume persistant monté à la fois sur le conteneur Flask et sur le conteneur Worker, sinon les plugins installés disparaissent au redémarrage.

Installation : Docker Compose, Podman, Kubernetes ou binaire natif

Le README indique quatre voies : Docker Compose, Podman, un déploiement Kubernetes à l'échelle, ou des applications natives pour macOS, Windows et Linux. Les images couvrent AMD64 et ARM64, et une image `-nvidia-arm` a été ajoutée en version 3.3.0 pour les machines fondées sur le GPU GB10, dont le DGX Spark. Le README qualifie cette image d'expérimentale, ce qui est une mise en garde à prendre au sérieux. Pour Kubernetes, le projet renvoie vers un dépôt séparé, AudioMuse-AI-helm, qui contient le chart. Les intégrations côté serveur passent par des plugins distincts : un plugin Navidrome, un plugin Jellyfin, et un plugin Lyrion non officiel maintenu par un tiers. Les versions de serveurs citées dans les badges du README sont Navidrome 0.62.0, Jellyfin 12.0, LMS v3.69.0, Lyrion 9.0.2, Emby 4.9.1.80 et Plex 1.43.2 : ce sont les cibles annoncées, pas une garantie de compatibilité avec toutes les versions antérieures. La documentation de configuration est répartie dans docs/PARAMETERS.md, docs/AUTH.md, docs/DEPLOYMENT.md, docs/GPU.md et docs/ERROR_CODES.md. Le README ne donne pas de commande d'installation complète dans l'extrait fourni, seulement ces renvois : c'est dans ces fichiers, et non dans la page d'accueil, que se trouvent les clés de configuration réelles.

La limite qui compte : l'analyse initiale

Toutes les fonctionnalités listées dépendent d'une analyse préalable, et le README le formule sans détour : « start with an initial analysis ». C'est le vrai coût d'entrée. Une bibliothèque de plusieurs milliers de titres demande une passe d'extraction sur chaque fichier, et rien dans les éléments fournis ne permet d'estimer la durée. Le projet documente des paramètres et un déploiement GPU, ce qui suggère que le CPU seul n'est pas toujours confortable, mais aucune mesure n'est publiée ici. Il faut donc traiter cette inconnue comme telle : la faisabilité dépend de votre matériel et de la taille de votre collection, et vous ne le saurez qu'après avoir lu docs/PARAMETERS.md et docs/GPU.md. Deuxième limite, plus discrète : Lyrics Search ne couvre que 72 langues. Une bibliothèque chantée dans une langue absente de cette liste restera hors de portée de cette fonction, même si le reste de l'analyse fonctionne. Troisième point, l'outil s'intercale entre votre serveur de médias et vos fichiers. C'est un composant de plus à maintenir, avec sa base de données et ses workers, dans une chaîne qui fonctionnait déjà sans lui.

Face à un serveur musical classique

La comparaison la plus directe n'est pas un autre outil d'IA, c'est le moteur de playlists intégré à votre serveur. Navidrome, Jellyfin ou Plex savent déjà construire des listes à partir de genres, d'années, de notes et d'historique d'écoute. Cette approche a un mérite : elle est instantanée, ne consomme rien, et ne demande aucune analyse préalable. Sa faiblesse est structurelle, elle ne connaît que ce que les tags déclarent. AudioMuse-AI déplace le critère du tag vers le signal audio. La différence se voit sur deux cas concrets : une bibliothèque aux tags incomplets, où les filtres classiques ne trouvent rien, et une demande du type « high-tempo, low-energy », qu'aucun champ de métadonnées ne peut exprimer. En contrepartie, vous échangez une fonction instantanée contre une analyse à mener une fois, et un service à héberger. Si vos tags sont propres et que vos besoins se limitent à « plus de morceaux de cet artiste », le moteur natif suffit et AudioMuse-AI n'apporte rien qui justifie le détour.

Maintenance, licence et rythme de publication

Le rythme de publication est soutenu. Trois versions apparaissent dans les éléments fournis, toutes en août et septembre 2026 : v3.5.0 « Hyperbolic Path », v3.5.1 sur les poids de concepts pour la recherche textuelle DCLAP, puis v3.5.2 présentée comme une maintenance. Sur une fenêtre aussi courte, cela signifie des mises à jour fréquentes à suivre, avec le risque habituel : une migration de schéma ou un changement de comportement entre deux versions mineures. Le README signale d'ailleurs des ruptures récentes, la file sur PostgreSQL en 3.2.0 et le support multi-serveurs en 3.0.0, qui ont chacune modifié le déploiement. La licence est AGPL-3.0. Concrètement, si vous modifiez le logiciel et le mettez à disposition d'utilisateurs sur un réseau, l'AGPL impose de rendre le code source correspondant disponible. Pour un usage strictement personnel, la question ne se pose pas de la même façon. Je ne suis pas juriste et ce paragraphe ne constitue pas un avis juridique : si vous envisagez de reprendre le code dans un service accessible à des tiers, faites vérifier ce point. Le projet est également lié à un ensemble de dépôts séparés (chart Helm, plugins Navidrome et Jellyfin, plugin Lyrion tiers, serveur musical), ce qui multiplie les composants dont les versions doivent rester cohérentes entre elles.

Conclusion éditoriale

AudioMuse-AI convient à qui possède déjà une bibliothèque locale volumineuse et une machine capable d'absorber une analyse longue, et qui accepte de dépendre d'un service dont le rythme de publication est rapide. Ce n'est pas l'outil à retenir si vous cherchez un simple moteur de recommandation fondé sur l'historique d'écoute, ni si vous voulez éviter d'exposer vos serveurs de médias à un composant supplémentaire. Avant d'installer quoi que ce soit, lisez docs/PARAMETERS.md et docs/GPU.md et vérifiez que la taille de votre bibliothèque tient dans le temps de calcul que vous êtes prêt à lui accorder : c'est cette estimation, et non la liste des fonctionnalités, qui décidera si le projet vous sert ou vous encombre.

Sources officielles

1. License: AGPL-3.0
2. NeptuneHub/AudioMuse-AI on GitHub
3. Project website
4. README
5. Releases