2 Einführung¶

2.1 Zielsetzung¶

Wo ist also das konkrete Problem, das libmunin nun lösen soll? Das erklärte Ziel ist es eine Bibliothek zu schaffen, die einen auf Musik spezialisierten Empfehlungsdienst implementiert. Allgemein gesprochen ist ein Empfehlungsdienst ein Dienst, der zu bestimmten Objekten ähnliche Objekte vorschlägt. Zur Ermittelung der ähnlichen Objekte nutzt er Metadaten welche die einzelnen Objekte beschreiben. Die Metadaten werden durch Methoden des Information–Retrieval beschafft und durch Methoden des Dataminings analysiert. Der Nutzer wird zudem während der Laufzeit beobachtet um mit der Zeit exaktere Empfehlungen abzugeben.

In unserem konkreten Fall soll also ein Prototyp eines Empfehlungsdienstes entwickelt werden, bei dem die oben genannten Objekte einzelne Lieder darstellen.

Einsatzmöglichkeiten eines auf Musik spezialisierten Empfehlungsdienstes:

1. Einsatz in Mediaplayern für große, meist lokale Musiksammlungen.
2. Einsatz bei Music Streaming Plattformen als Backend für Empfehlungen.
3. Einsatz bei Music Shops, um ähnliche Artikel vorzuschlagen.
4. Einsatz bei Webradios als DJ-Software zur Erstellung einer automatischen, intelligenten Playlist.
5. Einsatz in sozialen Netzwerken, um Menschen mit ähnlichem Musikgeschmack zu finden.

Weitere Einsatzmöglichkeiten sind natürlich denkbar und bei kreativen Nutzern zu erwarten.

Ein zusätzlicher Vorteil von libmunin: Man entgeht einerseits der Werbung, die bei den meisten Diensten zwischen allen paar Liedern gespielt wird, andererseits ist man nicht einer Vorauswahl der Musiklabels unterworfen. Denn meist wird nur die momentan populäre Musik bei den oben genannten Plattformen gespielt. Zudem ist dort die Musik kommerzieller Natur. Freie, Creative Commons lizenzierte Musik, wie man sie beispielsweise auf Jamendo ¹ findet, sucht man anderswo vergebens. Mit libmunin kann man hingegen seine lokale, selbst zusammengestellte Musiksammlung verwenden.

2.2 Vorhandene Alternativen¶

Um Ideen zu sammeln und Fehler zu vermeiden, die andere bereits gemacht haben, werden einige Alternativen und deren Herangehensweise an das Problem betrachtet. Es werden einige ausgewählte Plattformen aller Couleur gezeigt und deren Funktionsweise und Besonderheiten kurz erklärt.

2.2.1 Bekannte Plattformen¶

last.fm: [Link–4] Der wohl bekannteste Musikempfehlungs–Service im Netz. Benutzer können sich mit ihrem Account ein personalisiertes Webradio (auch Station genannt, siehe Abb. 2.1b) zusammenstellen. Dabei wählt man ein Lied auf der Seite aus und lässt sich darauf basierend weitere Lieder oder Künstler (siehe Abb. 2.1a) vorschlagen, die in eine ähnliche Richtung gehen. Für viele Musicplayer gibt es Plugins, die die gespielten Lieder zu last.fm übermitteln. Diesen Vorgang nennen die Betreiber scrobbeln [Link–5]. Durch diese Informationen werden dann spezialisierte Empfehlungen getroffen. Die Informationen kommen dabei also von den Nutzern, nicht von den eigentlichen Songdaten.

(a) Anzeige ähnlicher Künstler auf last.fm. Hier zum Künstler ,,The Beatles”.

(b) Eine Station zu der Band Knorkator, auf Spotify (Empfehlungen von last.fm).

Figure 2.1: Screenshots von Last.fm.

YouTube: [Link–6] YouTube ist vorrangig als Video–Plattform bekannt. Durch die enorme Beliebtheit laden dort Nutzer allerdings auch Musik, verpackt als Video, hoch. Interessant dabei ist, dass in der Sidebar stets Empfehlungen für weitere Videos angezeigt werden (siehe Abb. 2.2). In den meisten Fällen dann auch weitere Musikvideos. Dabei haben die meisten Videos auch etwas mit dem Aktuellem zu tun.

Einige der Attribute (vergleiche [2]), die in die Empfehlung mit eingehen:

• Videometadaten (Qualität, Beschreibung, Titel)
• Upload–Datum
• ,,Plays" und tatsächliche ,,Plays" (also ob das Video lang genug angeschaut wurde)

Figure 2.2: Die Vorschläge zu einem Musikvideo auf YouTube.

Myspace: [Link–7] Obwohl das soziale Netzwerk Myspace seine besten Tage hinter sich hat, haben viele Bands noch auf der Seite ein Profil unter dem man sich oft kostenlos Musik anhören kann (siehe Abb. 2.3). Ähnlich wie bei anderen populären sozialen Netzen kann man diese Seite liken. Diese Information wird dann dafür genutzt einem Benutzer Bands vorzuschlagen, die auch seine Freunde mögen — unter der Annahme, dass die Freunde einen ähnlichen Musikgeschmack haben.

Figure 2.3: Die Vorschläge die MySpace basierend auf den ersten Song macht.

Amazon: [Link–8] Den Grundstein für die Empfehlungen bei Amazon bildet die Warenkorbanalyse [4]. Dabei werden die Warenkörbe der Benutzer analysiert und es werden Assoziationsregeln erstellt. Bevorzugtermaßen Regeln, die unerwartete Zusammenhänge aufdecken. Ein Kauf ist eher eine klare Absichtserklärung, als ein Klick auf YouTube. Das typische Lehrbeispiel ist dabei: ,,Wer Bier kauft, kauft auch Windeln" ². Diese Regeln werden dann genutzt, um neue Artikel für bestimmte Artikel vorzuschlagen (siehe Abb. 2.4). Auch die personalisierte Shopping–Historie fließt in die Empfehlungen mit ein.

Figure 2.4: Zu fast jedem Artikel erhält man Empfehlungen was man noch kaufen könnte. Hier zu Knorkator – The Schlechtest of.

Musicovery: [Link–9] Diese Seite kategorisiert eine große Anzahl von Musikstücken (siehe Abb. 2.5) nach Stimmung (dunkel bis positiv) und Tempo (ruhig bis energiegeladen). Diese zwei Attribute werden an den Achsen eines Koordinatensystems aufgetragen. So erhält der Benutzer die Möglichkeit einen Punkt darin zu selektieren und basierend auf diesen Eigenschaften sich Empfehlungen liefern zu lassen.

Figure 2.5: Die Moodmap auf Musicovery.com.

2.3 Vorhandene Arbeiten¶

Zum Thema Muisc Recommendation gibt es bereits einige wissenschaftliche Arbeiten. Drei ausgesuchte Arbeiten werden im Folgenden aufgelistet und deren Kernaussagen im Bezug auf dieses Projekt erläutert:

• A self-organizing map based knowledge discovery for music recommendation systems [8]

  Statt dem Computer die Ähnlichkeit zwischen zwei Liedern bestimmen zu lassen, verwendet diese Arbeit Reviews von Amazon, um daraus Beziehungen zwischen Künstlern abzuleiten.

  Dieser Ansatz fällt unter Social–based–Recommendations. Man nutzt also das Wissen vieler Menschen um Ähnlichkeiten abzubilden. Dies steht im Gegensatz zu Content–based–Recommendations. Bei dieser Methode wird die Ähnlichkeit anhand von Audio- und Metadaten automatisch ermittelt.

  Vorteil: Elegant und oft sehr akkurat.

  Nachteil: Unvollständig, nicht für jeden Künstler ist ein Review vorhanden.

• A music search engine built upon audio-based and web-based similarity measures [5]

  Das in diesem Paper vorgestellte System kommt der Vorstellung von libmunin schon recht nahe. Die Audio- und Metadaten der einzelnen Lieder werden analysiert und abgespeichert. Fehlende Metadaten werden automatisch aus dem Netz bezogen (Reviews und Liedtexte). Statt die Musikstücke aber zueinander in Relation zu setzen, werden die Informationen für eine skalierbare Suchmaschine benutzt, die basierend auf natürlicher Sprache (Beispielsuche: rock with great riffs) passende Lieder findet.

• Music for my mood [6]

  Die Ähnlichkeit zwischen zwei Stücken wird über die Stimmung, welche durch Audioanalyse bestimmt wird, in einem Lied definiert. Man wählt dann, ähnlich wie bei Musicovery, Lieder nach seiner aktuellen Stimmung.

2.4 Schlussfolgerungen¶

Folgende Ideen erscheinen übernehmenswert (Quellen in Klammern):

• Ein System welches von seinen Nutzern lernt. (last.fm)
• Umfangreiche Einbeziehung von Metadaten. (YouTube)
• Nutze zum Lernen die ,,Warenkorbanalyse" um Assoziationsregeln abzuleiten. (Amazon)
• Nutze Audioanalyse (Mirage) um Ähnlichkeiten festzustellen. Beispielsweise die Stimmung, beziehungsweise. ,,Mood", in einem Lied. (Musicovery)

Es ist natürlich empfehlenswert aus den ,,Fehlern" anderer zu lernen, daher sollte man folgende Probleme beim Design und der Implementierung berücksichtigen:

• Kaltstart, also die Verzögerung beim ersten Start, möglichst klein halten. (mufin audiogen)
• Verwaltung großer Datenmengen sollte möglich sein. (Mirage)
• Bibliothek Programmiersprachen unabhängig halten. (Mirage)
• Keine strikte Abhängigkeit von Audiodaten. Ein Betrieb nur mit Metadaten sollte möglich sein. (Mirage)
• Libertäre Lizenz wählen um allgemeine Verfügbarkeit zu gewährleisten. (mufin audiogen)

2.5 Anforderungen¶

Nachdem man sich also das Umfeld angeschaut hat, kann man versuchen Anforderungen abzuleiten, die eine gute Schnittmenge aus den obigen Plattformen und Arbeiten bildet, welche dann libmunin erfüllen sollte.

Performanz: Später ist damit zu rechnen, besonders im geplanten Client– und Server–Betrieb, dass sehr viele Anfragen gleichzeitig gestellt werden. Um lange Antwortzeiten zu verhindern, sollte das Ausstellen von Empfehlungen sehr performant erfolgen.

Die eigentliche Arbeit muss daher in einem vorgelagerten Analyseschritt erfolgen. Die daraus gewonnenen Kenntnisse können in einer geeigneten Datenstruktur gespeichert werden. Beim Ausstellen von Empfehlungen muss diese dann nur noch ausgelesen werden.

Empfehlungen bilden eine Kette: Wird eine Anfrage an libmunin gestellt, so wird ein Iterator zurückgegeben der alle libmunin bekannten Lieder, nach Relevanz absteigend sortiert, ausgibt.

Handhabung großer Datenmengen: Bei vielen Datamining–Anwendungen ist die Menge der Dokumente der Flaschenhals. In unserem Fall also sind die Dokumente einzelne Lieder. Herkömmliche private Musiksammlungen können bereits Größen von mehreren zehntausend Liedern erreichen. Betreiber von Streaming–Plattformen haben noch weitaus größere Datenmengen.

Lizenz: Die Lizenz sollte einen libertären Einsatz ermöglichen und sicherstellen, dass Weiterentwicklungen in das Projekt zurückfließen. Die GPLv3 Lizenz [Link–13] erfüllt diese Bedingungen. Der kommerzielle Einsatz ist erwünscht.

Begründbarkeit: Empfehlungen sollen begründbar sein. Es muss möglich sein, festzustellen welche Merkmale eines Songs zu der Empfehlung geführt haben.

Anpassungsfähige API: Die bereitgestellte API muss auf die stark variierende Qualität und Form von Musiksammlungen eingestellt sein. Viele existierende Musiksammlungen sind unterschiedlich gut mit Metadaten (Tags) versorgt. So sind manche Tags gar nicht erst vorhanden oder sind je nach Format und verwendeten Tagging–Tool/Datenbank anders benannt.

Das fertige libmunin soll mit Szenarien zurecht kommen, wo lediglich die Metadaten der zu untersuchenden Songs zur Verfügung stehen, aber nicht die eigentlichen Audiodaten. Dies kann vorteilhaft sein, wenn man keinen Zugriff auf die Audiodaten hat, aber die Metadaten bei Musikmetadatenbanken wie MusicBrainz vervollständigen kann.

Unabhängigkeit von der Programmiersprache: libmunin soll von mehreren Programmiersprachen aus benutzbar sein. Dieses Ziel könnte entweder durch verschiedene Languagebindings erreicht werden, oder alternativ durch eine Server/Client Struktur mit einem definierten Protokoll in der Mitte.

Portabilität ist für das Erste zweitrangig. Für den Prototypen sollen lediglich unixoide Betriebssysteme, im Speziellen Arch Linux [Link–14], dem bevorzugten Betriebssystem des Autors, unterstützt werden.

Demonstrations und Debuggeranwendung: Eine Demonstrationsanwendung soll entwickelt werden, die zur Fehlersuche, Verbesserung und als Einsatzbeispiel dient. Als Demonstrationsanwendung eignet sich ein Musicplayer, der dem Nutzer mithilfe libmunin Musikstücke vorschlägt und diese Empfehlung auch begründen kann. So kann die Anwendung auch als Debugger für Entwickler von libmunin dienen.

Die Demoanwendung sollte dabei auf dem freien MPD-Client Moosecat [Link–15] aufsetzen. Moosecat ist ein vom Autor seit 2012 entwickelter GPLv3 lizensierter MPD-Client. Im Gegensatz zu den meisten, etablierten Clients hält er eine Zwischendatenbank, die den Zustand des MPD–Servers spiegelt. Dadurch wird die Netzwerklast und die Startzeit reduziert und Features wie Volltextsuche werden möglich. Er wird in Python, Cython [Link–16] und C entwickelt und befindet sich noch in einem frühen Entwicklungsstadium.

Einfaches Information Retrieval: In den meisten privaten Musiksammlungen sind die wichtigsten Attribute getaggt. Sprich in der Audiodatei sind Werte wie Artist, Album und Titel hinterlegt. Manche Attribute sind allerdings schwerer zu bekommen, wie beispielsweise die Liedtexte zu einem bestimmten Titel oder auch das Genre eines Albums.

Es sollte aus Komfortgründen auf einfache Art und Weise möglich sein externe Bibliotheken zur Datenbeschaffung in libmunin einzubinden. Für diesen Einsatz ist libglyr [Link–17] gut geeignet. Libglyr ist eine, vom Autor seit Ende 2010 entwickelte C-Bibliothek Musikmetadatensuchmaschine, um schwer zu besorgende Daten wie Liedtexte, Coverart und andere Metadaten im Internet zu suchen und optional lokal zwischenzuspeichern. Sie ist GPLv3 lizensiert und wird unter anderem im Gnome Music Player Client (gmpc), vielen Shellskripten und in dem oben genannten Moosecat eingesetzt.

Anpassungsfähigkeit an den Benutzer: Mit der Zeit soll libmunin bessere Empfehlungen liefern als am Anfang. Es soll dabei auf explizite und auf implizite Weise lernen. Beim expliziten Lernen gibt der Benutzer ,,Tipps" (beispielsweise kann er ein Lied oder eine Empfehlung bewerten), beim impliziten Lernen wird, ohne das Zutun des Nutzers, das Verhalten des Benutzers beobachtet und daraus werden Schlussfolgerungen getroffen.

2.6 Zielgruppe¶

libmunin soll eine Bibliothek für Entwickler sein. Es stellt also keine einfach zu nutzende Anwendung oder Website bereit. Es kann aber für Entwickler als Backend dafür dienen.

Vom Autor selbst sind die folgenden Projekte anvisiert:

Moosecat: Implementierung als Plugin für Intelligente Playlisten.

Shellskripte: Mittels eines Kommandozeilen–Frontends von libmunin wäre ein einfacher Einsatz in Shellskripten möglich. Das Programm könnte versuchen die gängigsten Musiksammlungen einzulesen und auf Kommando Empfehlungen generieren.

Mopidy: [Link–18] Mopidy ist eine alternative Implementierung zum MusicPlayerDaemon (MPD) in Python mit erweiterten Features. Sie bietet eine Anbindung zu Music–Streaming–Plattformen wie Spotify. Dabei ist es kompatibel mit den existierenden MPD-Clients. Da die Entwickler von Mopidy eine Möglichkeit suchen um Dynamische/Intelligente Playlisten zu implementieren [Link–19], wäre dies ein guter Anlaufpunkt.

Footnotes