AudioMuse-AI: Sonische Playlists für selbstgehostete Medienserver

Welches Problem sonische Analyse löst und für wen

Musikserver kennen Titel, Interpret, Album und Genre. Wer eine Sammlung über Jahre zusammengetragen hat, stößt damit an eine Grenze: Die Tags sagen nichts darüber, wie ein Stück klingt. Zwei Aufnahmen können im selben Genre liegen und völlig unterschiedliche Energie, Tempo oder Klangfarbe haben. Genau an dieser Stelle setzt AudioMuse-AI an. Das Projekt beschreibt seinen Zweck selbst als Wiederentdecken vergessener Songs über sonische Analyse, ohne Metadaten und ohne externe APIs. Die Zielgruppe sind Betreiber selbstgehosteter Medienserver, nicht Endnutzer eines Streamingdienstes. Wer Navidrome, Jellyfin, LMS, Lyrion, Emby oder Plex selbst betreibt, kann AudioMuse-AI daneben stellen und die Analyseergebnisse in Form von Playlists zurück in den Server schreiben. Der Nutzen entsteht erst nach einer vollständigen Erstanalyse. Vorher gibt es nichts, worauf die Funktionen zugreifen könnten. Das ist keine Kleinigkeit, sondern der Einstiegspreis des Projekts.

Drei Container, eine Analyse, mehrere Server

Laut README besteht das Kernsystem aus Flask- und Worker-Containern. Der Flask-Teil nimmt die Anfragen entgegen, der Worker erledigt die Analysearbeit. Seit Version 3.2.0 läuft die Warteschlange auf PostgreSQL, Redis ist damit nicht mehr erforderlich. Das ist eine relevante Vereinfachung für das Deployment, weil ein Dienst weniger betrieben und gesichert werden muss. Interessanter ist der Umgang mit mehreren Servern. Ab Version 3.0.0 lassen sich beliebige Mischungen aus Navidrome, Jellyfin, LMS, Lyrion, Emby und Plex an eine einzige AudioMuse-AI-Instanz anbinden. Eine eingebaute Duplikaterkennung soll denselben Song über mehrere Server hinweg erkennen, sodass jedes Stück nur einmal analysiert wird und alle Server das Ergebnis teilen. Das ist der eigentliche Architekturgedanke: Analyse als geteilter Dienst, nicht als Funktion eines einzelnen Servers. Die Themenliste des Repositories nennt clap, librosa und onnx, dazu Docker und k3s. Für Details verweist das README auf docs/ARCHITECTURE.md, docs/ALGORITHM.md und docs/MULTI_SERVER.md. Wer die Analyse nachvollziehen will, muss diese Dateien lesen; das README selbst bleibt an dieser Stelle knapp.

Funktionen jenseits der einfachen Ähnlichkeitssuche

Die Funktionsliste ist lang, und nicht jede Position ist gleich nützlich. Clustering gruppiert klanglich ähnliche Stücke und erzeugt Playlists, die Genre-Grenzen ignorieren. Instant Playlists nehmen eine Beschreibung wie hohes Tempo, niedrige Energie entgegen und bauen daraus direkt eine Liste. Die Music Map stellt die Sammlung als zweidimensionale Karte dar, Song Paths suchen eine Klangbrücke zwischen zwei Titeln. Song Alchemy arbeitet mit ADD- und SUBTRACT-Markierungen und exportiert die Auswahl zurück in den Medienserver. Text Search und Lyrics Search gehen über den Klang hinaus. Bemerkenswert ist die Einschränkung bei der Textsuche nach Liedtexten: Sie funktioniert laut README nur mit den dort aufgeführten 72 Sprachen. Deutsch und Englisch sind enthalten, viele kleinere Sprachen nicht. Wer eine Sammlung mit Liedtexten außerhalb dieser Liste pflegt, bekommt dort schlicht keine Treffer. Die Release-Historie zeigt, wohin die Entwicklung geht: v3.5.0 trägt den Titel Hyperbolic Path, v3.5.1 ergänzt DCLAP Text Search Concept Weights, v3.5.2 ist ein Wartungsrelease. Die Textsuche ist also ein Bereich, der aktiv nachgeschärft wird.

Inbetriebnahme: Docker Compose, Podman oder Helm

Das README nennt drei Wege: lokal mit Docker Compose oder Podman, im Cluster über das Helm-Chart, oder als native Anwendung für macOS, Windows und Linux. Für Kubernetes verweist das Projekt auf ein separates Repository, AudioMuse-AI-helm. Unterstützt werden AMD64 und ARM64. Ein konkretes Compose-Beispiel steht im README nicht, es verweist auf das Deployment-Verzeichnis und auf docs/DEPLOYMENT.md sowie docs/PARAMETERS.md. Wer die Parameter durchgeht, findet dort die Konfigurationsschlüssel; das README selbst bleibt bei den Schaltern allgemein. Zwei Punkte sollte man vor dem Start klären. Erstens: Seit 3.2.0 ist PostgreSQL die Warteschlange, das neue Deployment-Beispiel im Repository ist die maßgebliche Vorlage, ältere Anleitungen mit Redis passen nicht mehr. Zweitens: Für das Plugin-System muss ein persistentes Volume in beiden Containern, Flask und Worker, gemountet sein. Fehlt es, sind installierte Plugins nach einem Neustart verloren. Das ist eine der wenigen Stellen, an denen das README eine Fehlerquelle ausdrücklich benennt, und sie betrifft beide Container gleichzeitig.

Die Erstanalyse ist der eigentliche Kostenfaktor

Alle Funktionen hängen an einem Schritt: der initialen Analyse. Das README formuliert es als Einstieg, nicht als Option. Für eine große Sammlung bedeutet das Rechenzeit auf der eigenen Hardware, und zwar bevor irgendetwas Nutzbares herauskommt. Wer eine GPU stellt, verkürzt das; das Projekt dokumentiert den GPU-Pfad in docs/GPU.md und liefert seit Version 3.3.0 ein Image namens -nvidia-arm für DGX Spark und andere Maschinen auf GB10-Basis. Dieses Image ist laut README ausdrücklich experimentell. Wer darauf setzt, sollte den Status kennen und nicht von Produktionsreife ausgehen. Der zweite wunde Punkt ist die Duplikaterkennung. Sie ist die Voraussetzung dafür, dass mehrere Server sich die Analyse teilen. Wie sie genau arbeitet, ob über akustische Ähnlichkeit oder über abgeglichene Felder, steht im README nicht; dafür ist docs/MULTI_SERVER.md die richtige Adresse. Wer zwei Server mit überlappender Sammlung betreibt, sollte dieses Verhalten prüfen, bevor er die Erstanalyse zweimal bezahlt.

Wo AudioMuse-AI das falsche Werkzeug ist

Nicht jede Sammlung braucht sonische Analyse. Wer kuratierte Alben hört und ohnehin weiß, was er auflegen will, gewinnt wenig. Auch als Ersatz für die Metadatenpflege taugt das Projekt nicht: Es umgeht Metadaten, es repariert sie nicht. Falsch ist der Ansatz dort, wo die Sammlung klein und überschaubar ist. Der Aufwand für Analyse, Datenbank und Containerbetrieb steht dann in keinem Verhältnis zum Ergebnis. Ein weiterer Grenzfall: Wer nur einen einzigen Medienserver betreibt und dessen eigene Such- und Filterfunktionen für ausreichend hält, bekommt durch den Mehrserver-Teil keinen Vorteil. Und wer die Liedtextsuche als Hauptargument betrachtet, sollte zuerst prüfen, ob die eigenen Texte in einer der 72 Sprachen vorliegen. Das ist keine Formalie, sondern entscheidet, ob die Funktion überhaupt greift. Die Lizenz ist ein eigener Punkt. AudioMuse-AI steht unter AGPL-3.0. Wer die Software nur selbst betreibt, hat damit in der Regel wenig Berührung. Wer sie jedoch verändert und als Netzwerkdienst Dritten zugänglich macht, sollte die Bedingungen der AGPL-3.0 kennen. Das ist keine Rechtsberatung, sondern ein Hinweis darauf, dass die Lizenzwahl bei selbstgehosteter Software dann relevant wird, wenn der Dienst nach außen sichtbar ist.

Alternative: Music Map und Song Paths direkt im Server

Der naheliegende Vergleich ist die Funktion, die viele Musikserver inzwischen selbst mitbringen: automatische Playlists auf Basis von Ähnlichkeit oder Hörverlauf. Der Unterschied liegt im Verfahren. Server-eigene Empfehlungen stützen sich typischerweise auf Metadaten, Genre-Zuordnungen oder darauf, was Nutzer tatsächlich abgespielt haben. AudioMuse-AI setzt dagegen ausdrücklich am Klang an und erklärt Metadaten für entbehrlich. Das führt zu anderen Ergebnissen: Ein Cluster kann Stücke zusammenwerfen, die kein gemeinsames Genre-Tag haben, aber ähnlich klingen. Umgekehrt kann es Stücke trennen, die im selben Genre stehen, aber unterschiedlich aufgenommen sind. Wer diesen Unterschied nicht braucht, für den ist die eingebaute Playlist-Funktion des Servers der günstigere Weg: kein zusätzlicher Container, keine Erstanalyse, keine Datenbank. Ein zweiter Vergleichspunkt ist der eigene MusicServer aus dem Projektumfeld, den das README als Open-Subsonic-ähnlichen Server mit integrierter sonischer Funktionalität beschreibt. Wer ohnehin einen neuen Server aufsetzt, kann diesen Weg prüfen, statt eine bestehende Installation um AudioMuse-AI zu ergänzen.

Wartung, Updates und was vor dem Start zu klären ist

Die Release-Kadenz ist eng: v3.5.0 am 27. August, v3.5.1 am 30. August, v3.5.2 am 4. September 2026. Wer regelmäßig aktualisiert, muss mit häufigen Image-Wechseln rechnen, und die Versionshinweise zeigen, dass einzelne Releases neue Konzepte einführen, etwa die Hyperbolic Path in 3.5.0. Das ist kein Grund zur Sorge, aber ein Grund, Updates nicht ungeprüft über eine laufende Instanz zu ziehen. Der Wechsel der Warteschlange von Redis auf PostgreSQL in 3.2.0 zeigt, dass sich auch die Deployment-Topologie zwischen Versionen ändern kann. Wer eine bestehende Installation betreibt, sollte vor einem Sprung über mehrere Minor-Versionen die Deployment-Dokumentation der Zielversion lesen, nicht die, mit der er ursprünglich installiert hat. Für Kubernetes gibt es das getrennte Helm-Chart-Repository, das den Upgrade-Pfad strukturierter macht als handgeschriebene Manifeste. Vor dem ersten produktiven Lauf sind drei Dinge zu prüfen: ob die Erstanalyse auf der vorhandenen Hardware durchläuft, ob das Plugin-Volume in beiden Containern gemountet ist, und ob die Deduplizierung bei mehreren Servern greift. Wer diese drei Punkte abhakt, hat die häufigsten Stolpersteine aus dem Weg geräumt.

Redaktionelles Fazit

Sinnvoll ist AudioMuse-AI für Betreiber, die ihre Sammlung bereits selbst hosten und bereit sind, die vollständige Erstanalyse abzuwarten. Wer nur gelegentlich ein paar Playlists braucht oder keine GPU für den optionalen Pfad stellen will, fährt mit der Suche des jeweiligen Servers einfacher. Vor dem Produktiveinsatz zu prüfen: ob die Erstanalyse auf der vorhandenen CPU in vertretbarer Zeit durchläuft, ob das Plugin-Volume in beiden Containern gemountet ist, und ob die eigene Sammlung doppelte Titel über mehrere Server hinweg enthält, damit die Deduplizierung greift.

Offizielle Quellen

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