6 Ausblick

6.1 Verbesserung der Algorithmik

Im Folgenden werden einige Ideen für mögliche Weiterenwicklungen an den vorgestellten Algorithmen gegeben. Einige davon sind vergleichsweise einfach umsetzbar. Andere könnten die Grundlage für fortführende Arbeiten sein.

6.1.1 Audioanalyse

Wie bereits erwähnt, ist libmunin's momentane ,,Audioanalyse" eher simpler Natur. Als konkrete Vorlage für eine verbesserte Audioanalyse könnte Mirage dienen. In seiner Arbeit stellt der Mirage–Autor [2] Dominik Schnitzer, einige Herangehensweisen zum performanten Vergleich von Audiodaten vor.

Angesichts der hohen Entwicklungsgeschwindigkeit in der Informatik und dem ,,hohem" Alter der Arbeit (\(2007\)), sollte allerdings beachtet werden, dass es bereits neuere Methoden geben könnte. Beispielsweise arbeitet Schnitzer nur mit MP3–Audiodaten 1. Eine Abhilfe wäre die relativ neue Bibliothek libaubio, die von Paul Brossier [Link–20] entwickelt wird. Zum Dekodieren der Audiodaten (libaubio erwartet bereits dekodierte PCM–Daten), könnte das weit verbreitete Audio–Framework GStreamer [Link–21] verwendet werden.

Aubio könnte folgendes leisten:

  • Exaktere Bestimmung des BPM–Wertes. Beziehungsweise könnte man auch einen Verlauf des BPM–Wertes, über das Musikstück aufzeichnen, um exaktere Vergleiche ziehen zu können.
  • Onset–Detection, also das Erkennen einzelner Noten, beziehungsweise Sounds, innerhalb eines Musikstücks. Die Bestimmung der Tonart wäre so in Ansätzen möglich.
  • Eine direkte Möglichkeit, die Stimmung in einem Lied zu analysieren, wird momentan zwar noch nicht geboten, aber die dazu benötigten Informationen, wie die Erkennung der Tonlage zu einem bestimmten Zeitpunkt werden angeboten. Die technischen Details dazu werden in [2] diskutiert.

Die Bibliothek selber ist in C geschrieben, bietet aber eine komfortable Python–Schnittstelle.

Eine weitere Idee, wäre der Versuch, möglichst intelligent reine Sprachdateien (wie Hörbücher), Instrumental–Lieder ohne Stimme (wie Intros) und normale Musik zu unterscheiden. Oft werden zu bestimmten Titeln unpassenderweise Intros vorgeschlagen, die man für gewöhnlich nur hören möchte, wenn man das gesamte Album von vorn bis hinten anhört. Auch hier wäre ein Einsatz von libaubio denkbar.

Footnotes

[1]Mirage verlässt sich dabei auf bestimmte Eigenschaften von MP3, um die Daten schneller in seine interne Datenrepräsentation zu konvertieren.

6.1.2 Andere Provider

Wie man im Playlistenvergleich unter Kapitel 2.5 gesehen hat, ist momentan der Vergleich der Metadaten, die Stärke von libmunin. Diese Fähigkeit könnte noch weiter ausgebaut werden, indem die Sprache der einzelnen Titel (denn nicht immer sind Liedtexte vorhanden) erkannt wird. Dann könnte man mittels eines Thesaurus synonyme Titel finden. Für Python existiert mit TextBlob [Link–22] hierfür eine passende Bibliothek.
Kommt beispielsweise in einem Liedtitel das Wort ,,Sofa" vor, so könnte ein Titel mit dem synonymen Wort ,,Couch" darin vorgeschlagen werden. Auch Taxonomien, also ähnliche Klassifikationen, sind denkbar. Man denke hier an einem Lied, welches das Wort ,,Katze" enthält und ein anderes das ,,Tier" beinhaltet.
In der momentanen Implementierung wird jedes Wort im Titel, auf seinen Wortstamm gebracht und mittels der Levenshtein–Distanzfunktion verglichen. Diese Lösung ist zwar leicht zu implementieren, ist aber algorithmisch teuer und verhindert lediglich Tippfehler oder leicht divergente Schreibweisen.

Auch interessant zu sehen wäre es, ob die Länge der einzelnen Stücke in irgendeiner Form mit der Ähnlichkeit korrelieren. Hier müssten statistische Auswertungen gemacht werden, um diesen Zusammenhang zu überprüfen. Falls sich ein Zusammenhang zeigen sollte, ließe sich eine einfache DurationDistanceFunction schreiben, welche ähnlich lange Stücke gut bewertet.

6.1.3 Empfehlungen

Schematische Darstellung der idealen Traversierungsreihenfolge

Figure 6.1: Schematische Darstellung der idealen Traversierungsreihenfolge. Die roten Knoten stellen die Seedsongs dar, die gelben und orangen Knoten sind direkte Nachbarn. Die grünen Knoten sind ,,irgendwo” dazwischen. Die Traversierungsreihenfolge sollte hier sein: Orange, Gelb, Grün.

Oft kommt es vor, dass es mehr als einen Seedsong gibt. Die momentane, simple Herangehensweise, ist für jeden einen Iterator zu erstellen und die einzelnen Iteratoren, im Reißverschlussverfahren zu verweben. Das ist durchaus valide, wenn man annimmt, dass die Seedsongs im Graphen verteilt und alle gleich wichtig sind. Oft ballen sich Seedsongs aber auf einem bestimmten Gebiet. Schematisch ist das in Abbildung 6.1 dargestellt. Besitzen zwei Seedsongs gemeinsame Nachbarn, dann sollten diese zuerst besucht werden.

Auch ist das Ausgabeformat von libmunin noch auf einzelne Songs als Empfehlung beschränkt. Nicht selten möchte man jedoch eine allgemeinere Auskunft wie ,,Gib mir einen ähnlichen Künstler/Album/Genre". Momentan wäre dies nur durch Auslesen der jeweiligen Attribute aus den einzelnen Empfehlungen möglich. Allerdings könnten hier von libmunin optimierte Traversierungsstrategien implementiert werden.

6.2 Erweiterungen

Die verwendeten Metadaten könnten ebenfalls erweitert werden. Für die Ähnlichkeit sind unter Umständen auch Attribute wie der Producer, die Band–Mitglieder oder die Herkunft der Band relevant. Einfache Beispiele wären hier: ,,Wer Songs von den Ärzten hört, der hört vermutlich auch gern Farin Urlaub Racing Team" — natürlich unter der Annahme, dass derselbe Künstler auch immer ähnliche Musik produziert.

Was das Lernen von libmunin angeht, so sollten auch ,,negative Impulse" behandelt werden. Wird ein bestimmtes Lied oder gar ein Künstler sehr oft übersprungen, könnte libmunin dies berücksichtigen, indem es bei der Traversierung diesen Knoten umgeht. Alternativ wäre auch ein nachträgliches Filtern der entsprechenden Lieder möglich.

Allgemein wäre auch eine Erweiterung von Assoziationsregeln denkbar. Momentan verbindet eine Regel immer zwei Mengen von Songs miteinander. Alternativ könnten aber auch verschiedene Genres, Künstler oder auch Alben in einer Regel miteinander verbunden werden. Das Erstellen solcher Regeln wäre relativ einfach mit der existierenden Implementierung. Was problematisch ist, ist diese neuen Regeln als Traversierungshilfe zu nutzen.

Ein weiterer Punkt, den man beim Lernen verbessern könnte, sind die Gewichtungen, die manuell für jedes Attribut festgelegt werden. Man könnte den Nutzer detaillierter beobachten und sehen, nach welchem Attribut er bevorzugt seine Lieder auswählt (beispielsweise nach Genre). Das entsprechende Attribut könnte dann höher gewertet werden.

Auch wäre ein zusätzliches Modul möglich, das libmunin nutzt, um Suchanfragen basierend auf natürlicher Sprache zu ermöglichen. So könnten Anfragen wie ,,Happy Indie Pop" aufgelöst werden. Im Beispiel würde sich Happy auf die Stimmung beziehen, Pop auf das Genre und Indie auf einen Independent–Künstler. Letztere Information könnte man aus der Künstlerbiografie extrahieren. Die Biografie kann automatisch von Tools wie libglyr besorgt werden oder man greift alternativ auf Amazon–Rezensionen zurück. So gesehen, bietet sich hier ein Erweiterungspotenzial in Richtung ,,Social–based–Recommendations". Also nutzt man das Wissen von vielen Menschen, um bestimmte Attribute zu bestimmen, anstatt diese mithilfe von Metriken zu errechnen. Die eigentliche Schwierigkeit bestünde aber darin, die einzelnen Wörter bestimmten Attributen zuzuordnen. Diese Idee basiert auf der Musiksuchmaschine von Peter Knees [14].

6.3 Fazit

Momentan ist libmunin vor allem eine Spielwiese für verschiedene Ideen, rund um die Frage, wie man einem Computer die Ähnlichkeit von zwei Musikstücken feststellen lässt. Trotzdem erstellt libmunin selbst als Prototyp in seiner Standardeinstellung bereits durchaus nützliche Playlisten. Aufgrund der kurzen Implementierungszeit für ein solches System, von etwas mehr als 3 Monaten, ist dies nach Meinung des Autors durchaus als Erfolg zu werten.

Die größte Schwäche ist aus Sicht des Autors der langsame Kaltstart, der einen produktiven Einsatz der Bibliothek verhindert. In der Weiterentwicklung, sollte dies die höchstpriosierte Aufgabe sein.

Die Neuerung dieser Arbeit ist weniger die vorgestellte Algorithmik. Der allergrößte Teil dieser, existiert natürlich bereits in ähnlicher Form, verstreut über viele verschiedene Softwarepakete. Die tatsächliche Neuerung ist, dass diese Funktionalität erstmals in einer allgemein nutzbaren und freien Bibliothek vorhanden ist.