Es wurde eine Softwarebibliothek in Python implementiert, die ein Musikempfehlungssystem auf Graphen–Basis mit einer flexiblen Schnittstelle bietet. Das System lernt dabei vom Nutzer mittels expliziten (Vergeben von Ratings) und impliziten (Beobachtung des Endnutzers und Ableitung von Assoziationsregeln) Methoden.
Es wurde eine große Anzahl von sogenannten Providern zum Normalisieren der Eingabedaten, sowie eine entsprechend hohe Anzahl von Distanzfunktionen implementiert, welche diese Daten vergleichen können. Im Vergleich zu bestehenden Systemen ist man nicht von Audiodaten abhängig. Durch die freie Lizenz ist ein weitläufiger Einsatz möglich.
Insgesamt wurden hauptsächlich folgende Techniken aus diesem Gebiet genutzt:
Momentan ist libmunin nur von Python aus zu benutzen. Dies ist zum Teil dem Format geschuldet in dem die internen Daten abgespeichert werden: Dem Python-spezifischen pickle Format, welches beliebige Python–Objekte serialisieren kann, macht es natürlich schwierig Software zu schreiben, die eine serialisierte Session einlesen kann, ohne dabei auf libmunin oder Python zurückzugreifen.
Davon unabhängig ist libmunin momentan durch die Implementierung in Python auf diese Sprache eingeschränkt. Da viele Musicplayer in anderen Sprachen geschrieben sind, kann das durchaus zum Problem werden. Hier gibt es zwei bekannte Lösungsansätze. Der erste ist das Schreiben von Languagebindings für die Zielsprache. Das würde erheblichen Aufwand mit sich bringen, wenn mehr als einige wenige Sprachen unterstützt werden sollen. Die zweite Möglichkeit ist eine Aufteilung in Server (der dann in Python geschrieben wäre) und Client (der in einer beliebigen Programmiersprache geschrieben ist). Der Client könnte dann über ein definiertes Protokoll auf die Funktionen des Servers zurückgreifen, was beispielsweise die Herangehensweise von MPD ist.
Eine konkrete Umsetzung dieser Idee könnte relativ einfach mit D-Bus 1 erreicht werden. Der Server würde dabei die API von libmunin als D-Bus–Service implementieren. Der Client könnte eine der in zahlreichen Programmiersprachen verfügbaren DBus–Libraries nutzen, um im Server Methoden aufzurufen. Darüber ließe sich auch ein anderes Randproblem lösen: Momentan ist es aus Gründen fehlender Nebenläufigkeit nicht möglich, dass verschiedene Programme dies selbe Session nutzen. Der Server könnte hier die Synchronisierung übernehmen.
Footnotes
| [1] | Ein unter Unix sehr weit verbreitetes IPC-Framework und Messagebroker, bei dem Services in einem Bus bereitgestellt werden. Clients können dann, ähnlich wie bei RPC, Methoden auf den Services aufrufen. |
Die Ergebnisse die libmunin liefern kann, können nur so gut sein wie die Eingabedaten. Sind diese falsch oder unzureichend (durch schlechte Tags etwa), wird auch eine gute Distanzfunktion nur mittelmäßige Ergebnisse erzielen.
Momentan bietet libmunin bereits dem Nutzer Möglichkeiten an, um fehlende Liedtexte und Genre–Tags aus dem Internet zu beschaffen. In der Einleitung dieser Arbeit wurden aber schon freie Musikmetadatenbanken wie MusicBrainz erwähnt, die mittels eines Audiofingerprints die Metadaten eines Stückes nachschlagen können.
Glücklicherweise steht mit beets [Link–36] bereits ein entsprechendes, praktischerweise in Python geschriebenes Tool bereit — gewissermassen das libhugin 2 für Musik. In Zukunft könnte beets zusammen mit libglyr also den Information Retrieval Teil übernehmen, ohne dass libmunin das Rad dafür neu erfinden muss.
Footnotes
| [2] | libhugin ist das Schwesterprojekt zu libmunin. Die Bibliothek dient unter anderem zum Auffinden zahlreicher Arten von Film–Metadaten. [Link–37] |
Der Aufruf von einigen Distanzfunktionen macht nur dann Sinn, wenn bestimmte Kriterien erfüllt sind. So macht es beispielsweise meist wenig Sinn die moodbar zweier Songs zu vergleichen, wenn sich die Stücklänge um mehr als das Doppelte unterscheidet — die Daten wären einfach zu unterschiedlich.
Momentan ist es allerdings noch nicht möglich, für die moodbar-Distanzfunktion die Länge des Stückes abzufragen — da sie nur die für sie relevanten Daten bekommt, nicht die ganze Song–Instanz.
Alle Operationen von libmunin verlaufen momentan sequentiell. Dabei ließen sich zumindest einige Teile des Kaltstartes optimieren, indem eine gewisse Anzahl von Liedtexten (oder anderem Information Retrieval) parallel heruntergeladen werden. Auch das Analysieren von Audiodaten könnte beschleunigt werden, indem ein (bei normalen Festplatten) oder mehrere (bei SSDs) Threads Audiodaten einliest und diese dann an Workerthreads weiterleitet, die die eigentliche Analyse durchführen.
Wie oben erwähnt erfolgt die Speicherung der Session mittels Python's pickle Modul. Dieses serialisiert rekursiv die Objekt–Hierarchie, ausgehend vom Session Objekt. Da in libmunin der Graph allerdings als rekursive Datenstruktur implementiert ist, ,,verläuft" sich pickle darin — zu hohe Rekursionstiefen entstehen bei ausreichend komplexen Graphen.
Python hat ein eingebautes Rekursionslimit, welches ein wenig aussagekräftiges Segmentation Fault verhindern soll — Abstürze beim Speichern der Session sind die Folge. Hier ist dringend Abhilfe nötig.
Die Berechnung des Beats–Per–Minute-Wertes ist momentan in ein separates Tool ausgelagert. Dieses Tool hat das Problem, dass es bei fehlerhaften Dateien oder Formaten die es nicht versteht, falsche (beispielsweise Werte über 300 bpm) Werte zurückgibt. Da dies nicht von libmunin's Seite aus gelöst werden kann, sollte hierfür eine eigene Lösung implementiert werden.
Abgesehen von den obigen ,,Defiziten" hier noch einige stichpunktartige Richtungen in denen die Implementierung verbessert werden kann:
libmunin ist ein solides Fundament für weitere Entwicklungen und so flexibel, dass mit entsprechenden Providern und Distanzfunktionen sogar Empfehlungssysteme für andere Dokumente wie Videos, Bücher oder anderen Artikeln möglich wären.
Noch ist der Einsatz relativ kompliziert (momentan nur über MPD möglich) und erfordert, auch für kundige Entwickler, einiges an Einarbeitungszeit — zuviel für etwas das eigentlich still im Hintergrund arbeiten sollte. Auch die erstellten Empfehlungen sind, subjektiv gesehen, noch teilweise verbesserungswürdig. Besonders die momentane Audioanalyse ist sehr primitiver Natur und bietet einiges an Potenzial an Verbesserungen. Es wird momentan mehr auf Masse statt auf Klasse gesetzt und oft ist einiges an ,,Kaffeesatzleserei" enthalten. Zudem entsprechen manche Funktionsweisen dem Geschmack und Gewohnheiten des Autors (wie dem Vergeben von Ratings, was nicht jeder macht) – diese müssen nicht allgemein gültig sein.
Da das Projekt auch nach Abschluss dieser Arbeit, im Rahmen von Moosecat weiter entwickelt werden soll, hofft der Autor mit der Zeit mehr Richtung Klasse zu gehen. Nach einem öffentlichen Release in einschlägigen Foren, können dann auch erste Resonanzen gesammelt werden. Vor allem ist es interessant zu sehen, ob libmunin dann tatsächlich für andere Entwickler einsetzbar ist. Zumindest Interesse scheint vorhanden zu sein: Selbst ohne Veröffentlichung, haben etwa 50 Entwickler die Projektseite auf GitHub ,,gestarred" (vergleichbar mit einem Like auf anderen Seiten).