SongSlope 2

Bachelorarbeit

Bearbeitet von: Hans-Peter Dietz

Betreuer: Dominikus Baur

Aufgabenstellung

Musik weckt Assoziationen beim Hörer: Beim Hören von Lied A fällt mir Lied B ein und ich möchte möglicherweise zu diesem wechseln. Allerdings unterstützt aktuelle Software diesen Vorgang nicht direkt - oft ist die Suche in einer langen Liste notwendig. In dieser Arbeit soll ein Plugin für einen Mediaplayer mit großer Nutzerbasis (iTunes, Songbird) erstellt werden, das beim Abspielen eines Lieds dessen bisherige Vorgänger und Nachfolger anzeigt (basiered auf der Last.FM Listening History des Benutzers). Mithilfe dieses Plugins soll eine Online-Nutzerstudie durchgeführt werden, um den tatsächlichen Wert des Tools nachzuweisen.

Konkrete Aufgaben

  • Erstellung einer Literaturliste von verwandten/relevanten wissenschaftlichen Arbeiten
  • Erstellung einer ausführlichen Dokumentation im Medieninformatik-Wiki
  • Design und Implementierung eines Prototypen
  • Nutzerstudie
  • Erstellung einer mindestens 50-seitigen Ausarbeitung, die den Hintergrund, die Implementierung und die Ergebnisse beschreibt und sich an diese Vorgaben (http://www.medien.ifi.lmu.de/lehre/arbeiten/richtlinien.xhtml) hält
  • Halten eines Abschlußvortrags im Oberseminar

Zeitplan

Beginn: 26.4.2010 (1.5.2010) (Teilzeit 20h/Woche)

Woche 1-4:
  • Literaturrecherche
  • Einarbeitung in Entwicklungsumgebung

Woche 5-8:
  • Design
  • Beginn Implementierung

Woche 9-13:
  • Implementierung

Woche 14-15:
  • Nutzerstudie

Woche 16-20:
  • Ausarbeitung

Gliederung

Entwürfe

Use Cases
  • Standalone: SongSlopeII dient in diesem Fall als alleiniges Tool zur Generierung von Playlists aus der History des Users. Es werden ohne weitere Nachfrage History-Stränge abgespielt. Dabei erinnert das PlugIn an das von iTunes bekannte Genius, nur dass es sich statt Moods/Genres/Songs der History des Users bedient. Hierbei ist eine Hybridisierung mit dem Discovery-Use Case denkbar, indem nicht nur Lieder aus der eigenen History/Mediathek, sondern auch die anderer User einbezogen werden (es sollte eine Konfigurationsmöglichkeit geben).
  • Background: SongSlopeII blendet zum momentan abgespielten Lied Histories ein, ohne automatisch Lieder dieser abzuspielen. Abgespielt wird also primär die vom User gewählte Playlist, es steht dem Nutzer allerdings frei jederzeit auf ein(en) eingeblendetes(n) History-Lied(-Strang) zu klicken, um zu diesem Song/Strang zu springen. Hier bietet es sich an eine Konfigurationsmöglichkeit zu schaffen, die es ermöglicht entweder weitere Lieder der History (den kompletten Strang) zu hören, oder nach dem ausgewählen Lied zurück zur vorher gewählten Playlist zu springen. Eine einfache CheckBox sollte diesen Zweck gut erfüllen.
  • Discovery: SongSlopeII versucht in diesem Modus die Histories fremder (unbekannter/bekannter/benachbarter) Nutzer zu finden und abzuspielen. Damit liesen sich sogar ganze Playlists anderer (lastFM-)User wiedergeben. Lieder die sich nicht in der eigenen Mediathek befinden könnten über Streaming von YouTube o. ä. eingebunden werden. In diesem Fall wäre zu bedenken, dass der User eventuell bei YouTube verweilen könnte und nicht mehr weiter mit SongSlopeII interagiert. Um dies zu umgehen gilt es herauszufinden, ob man einen YouTube-Player direkt in die SongSlopeII-View integrieren kann, um nach Abspielen des Liedes weiter in der History voranzuschreiten. Andernfalls ist ein Einbinden durch den in Songbird integrierten Browser über Links denkbar. Dies ermöglicht es dem Nutzer also neue Lieder/Genres zu entdecken und könnte mit Hilfe des unten genannten "Say-Thank-You"-Gimmicks sogar für neue Bekanntschafen sorgen.

Soziale Komponente
Da sich Menschen in sozialen Gefügen oftmals über ihren Musikgeschmack definieren - und dieser sogar ganze Subkulturen prägt - wäre es denkbar entsprechende "Gimmicks" auch in SongSlopeII zu integrieren. Eine erste Idee wäre einen "Say-Thank-You"-Button einzublenden, falls der User viele Lieder aus der History eines bestimmten anderen (lastFM)-Nutzers in (relativ) kurzer Zeit (~2 Wochen) hört. Durch einen Klick auf diesen Button könnte dann ein automatisch generiertes "Thank you" in die Shoutbox des "History-Providers" eingetragen werden. Natürlich sollte es dann auch möglich sein ein "Thank you" zu forcieren - etwa weil dem Nutzer ein Lied aus der History eines Anderen besonders gut gefällt.

Darstellung Eigen-/Fremdhistory
Es gilt mehrere Designfragen bezüglich der Darstellung von Eigen- und Fremdhistories zu klären:
  • Unterscheidung zwischen Eigen- und Fremdsträngen: Hier bietet sich meines Erachtens in erster Linie eine farbliche, auch durch ein Icon betonte, Unterscheidung an
  • Darstellung der Länge des History-Strangs: Da es nicht möglich sein wird den kompletten Inhalt jedes verfügbaren Historystrangs (unabhängig von eigen/fremd) jederzeit darzustellen, muss hier nach einer Alternative gesucht werden. Anbieten würde sich etwa eine Anzeige von horizontalen Balken deren Breite die Länge (Einheit? --> Lieder/Minuten) des jeweiligen Historystrangs hinter einem Lied darstellt.
  • Filterung/Favorisierung von Histories: Bei der Anzeige der Histories muss entschieden werden, welches Lied "oben" steht und damit eine vermeindlich favorisierte Stellung einnimmt. Hier wären mehrere Alternativen denkbar: Die Liste der Lieder wird alphabetisch sortiert; es wird nach lastFM-Ähnlichkeits-Ranking sortiert; es erfolgt eine zufällige Anzeige. Prinzipiell sind alle Möglichkeiten sinnvoll - eine alphabetisch sortierte Liste erleichtert die Suche - ähnliche Lieder werden gerne gehört - zufällige Anzeigen mindern die Chance dass der Nutzer ständig die gleichen Lieder zu hören bekommt. Meines Erachtens wäre auch hier eine Konfigurationsmöglichkeit wünschenswert.
  • Anzahl der angezeigten Hisories: Es gilt zu entscheiden wieviele Lieder/Histories angezeigt werden. Eine Liste mit 150 Einträgen ist oft unübersichtlich und viele User werden es womöglich vorziehen einfach das Erste zu wählen (--> hier könnte eine zufällige Sortierung helfen). Andererseits kann eine Einschränkung auf wenige (~10) Histories dem User restriktiv erscheinen. Eine Lösung hierfür muss noch gefunden werden - allerdings wäre auch hier wieder eine Konfigurationsmöglichkeit denkbar - etwa ein Balken mit den Markierungen "5" - "15" - "all", wobei bei der Einstellung "all" eine scrollbare Liste einzublenden wäre.
GUI Entwürfe
Ausgangssituation: (Songbird mit neuer MediaView-Extension)
Konzept SongSlope-Media-View:
  • Erklärung:
    • Kästchen-"C": Album-Cover
    • Balken hinter Kästchen-"C": Länge des History-Stranges - Color-Coded um Eigen-/Fremdhistories zu unterscheiden
    • Kuchendiagramm (unten links): Zusammensetzung der angezeigten Histories aus Eigen-/Fremdhistories
    • Slider (unten links): Anzahl der angezeigten Histories
  • Erklärung:
    • Default-View eingestellt alle Histories anzuzeigen
    • Da bei der Anzeige aller Histories nicht genügend Platz wäre für eine "Cover-Flow-ähnliche"-Darstellung, wird auf Tabellen zurückgegriffen mit den Feldern:
      • Artist
      • Title
      • History Length
    • Ein Klick auf einen Tabelleneintrag/Zeile führt zum abspielen des Liedes
    • Ein Klick auf einen History Length-Eintrag führt zum Wechsel in die "Browse"-Ansicht
  • Erklärung:
    • Browsen eines konkreten History-Strangs (z.B. durch klicken auf den Längen-Balken)
    • Initial zwei Möglichkeiten denkbar:
      • Momentan abgespieltes Lied fokusiert
      • Angezeigtes Lied der History auf die geklickt wurde fokusiert
    • Back-Button (oben rechts): zurück zur default-Anzeige
    • Pfeile (unten links/rechts): scrollen in der History [Zusätzliches "Drag"-Feature zum scrollen geplant]
  • Erklärung:
    • Standardansicht mit eingeblendetem "Say-Thank-You"-Button

Implementierung

  • Zweisprachig? (Deutsch/Englisch) / Einsprachig? (nur Englisch)
  • Datenhaltung Listening Histories: Listening Histories können groß werden - es ist also ratsam ressourcenschonende Ansätze zu verfolgen; etwa die Listening-History einmal zu Programmstart komplett abzurufen, dann zwischenzuspeicher (persistent?) und dann neu abgespielte Lieder selbst an die "temporäre" History anzuhängen, anstatt bei jedem Songwechsel die komplette History abzurufen * Wieviele und welche anderen User nach Histories abgrasen?

GUI-Design: Box Model
  • Erklärung: Box-Model von Songbird; sind Boxen deren Inhalt vertikal angeordnet wird, sind Boxen deren Inhalt horizontal angeordnet wird [Im Bild leider genau verkehrt herum beschriftet!]
Standard Workflow: State-Diagram
  • Erklärung:
    • Nach Laden des Players wird überprüft, ob ein History-File vorhanden ist
    • Ist dieses vorhanden:
      • wird die History aus dem File geladen und mit Hilfe dieser Empfehlungen erstellt
      • danach wird die History von last.fm geladen, um mit einer aktuellen History arbeiten zu können; dies geschieht im Hintergrund, während das Plugin bereits voll einsatzfähig ist und dient in erster Linie der Performace-Steigerung
    • Ist diese nicht vorhanden:
      • wird die History von last.fm geladen und ein Label <"Loading last.fm Listening History"> eingeblendet
    • Die Extension startet den eigentlichen Event-Loop, der bei jedem Track-Change, den neuen Track in die History aufnimmt und neue Empfehlungen abgibt.

Momentaner Stand: IMPLEMENTIERUNG BEENDET - Prototyp lauffähig
  • Erklärung:
    • Begin der Implementierung der Standardansicht - Anzeigen des momentan abgespielten Songs mit Cover
    • Abholen der kompletten User History
    • Ablegen der User History in einer Datei im Profil-Verzeichnis von SongBird beim Beenden
    • Einzeigen eines "Loading last.fm Listening History"-Labels während die History geladen wird
    • Parsen der History Datei
    • Abholen der Neighbors
    • Falls History-File vorhanden wird dieses zuerst geparsed und dann (1min Delay) die History von last.fm upgedated
      • Hintergrund: SongSlopeII is durch die geparste History bereits fähig Recommendations abzugeben und die History wird erst später (im Hintergrund) aktualisiert --> bessere Performance
    • Anzeigen der Pre- und Post-Stränge des Benutzers und der Neighbors
    • Klick auf das Cover bei einem Strang fügt das Lied nach dem akutell gepspielten in die Playlist ein, hebt es hervor und startet dessen Wiedergabe
    • Animationen für die Übergänge (sind im Video leider etwas "ruckelig", da das Screen-Capture-Tool enorm Ressourcen verbraucht)
    • Logging der Nutzer-Klicks, falls erlaubt
    • Demovideo auf YouTube

Studie

Literatur

Vorgegeben:
  • North et al.: Uses of Music in Everyday Life (Music Perception 2004)
    • Musik wird überall konsumiert --> Android/iPhone-App wünschenswert (nur 50,1% zu Hause)
    • Musik wird meist "nebenbei" konsumiert (73,6% der Zeit)
    • Hörumgebung bestimmt den "Wert" der musikalischen Erfahrung
    • Hörerfahrung abhängig von anwesenden Personen (am besten alleine, ansonsten abhängig von der Gesellschaft)
    • Die Masse an verfügbarer Musik verringert deren individuellen Wert
    • Menschen setzen Musik gezielt ein um in unterschiedlichen interpersonellen und sozialen Kontexten bestimmte psychologische Reaktionen hervorzurufen.
  • Levitin et al.: Life Soundtracks: The uses of music in everyday life (Phillips Report 2007)
    • Musik aktiviert so ziemlich jede Hirnregion
    • Musik verusacht aktivität in Hirnregionen die mit dem autonomen Nervensystem verbunden sind und kann pysische Reaktionen wie Schwitzen, sexuelle Erregung und "Kalte Schauer über den Rücken" hervorrufen
    • Eine der Haupteinsatzzwecke von Musik ist die Stimmungsregulierung
    • Musik hilft den sozialen Kontext/die soziale Identität zu definieren
    • Musik hilft sich zu konzentrieren ("Theory of flow")
    • Menschen schätzen die Musikempfehlungen ihrer Freunde (Menschen erhalten Selbstvertrauen durch die zugehörigkeit zu sozialen Gruppierungen, welche u. a. durch den Musikgeschmack definiert werden)
    • Es ist äußerst wichtig für Menschen wählen zu können ob/welche Musik sie hören
  • Voida et al.: Listening in: Practices surrounding iTunes music sharing (CHI 2005)
    • Leute sind wenig interessiert an "komplett" fremden Musik-Libraries (d. h. ohne jegliche Überlappung/Ähnlichkeit der Songs)
    • Discovery mit iTunes auf das Subnetz beschränkt --> SongSlopeII sollte das besser können wink
    • Der erste Eindruck (die ersten paar Lieder) einer fremden Library haben starken Einfluss darauf, ob der User wieder zu dieser Library zurück kehrt --> Übertragbar auf (Fremd-)Histories (?) --> Merken welche angeklickt/nicht angeklickt wurden (erledigt last.fm für uns) --> beim nächsten Mal präferieren?
    • Musik prägt soziale Kontakte/Gefüge, Media-Player sollte dies unterstützen --> "Danke-Schön-Feature"
  • Bentley et al.: Personal vs. commercial content: the similarities between consumer use of photos and music (CHI 2006)
    • Menschen definieren sich und andere über ihren/deren Musikgeschmack
    • "users are satisficing rather than optimizing - Grund dafür: zuviel Auswahl (siehe Schwartz)
    • Menschen "skippen" lieber als aktiv Songs auszuwählen - und wenn sie begonnen haben Songs zu "skippen" verringert das die Schwelle weitere Songs zu überspringen
    • Enttäuschung bei den ersten (wenigen) Versuchen [ein neues Lied/History] führt dazu dass Menschen zurück zur Standard-Wahl springen (effektiv: Playlist)
    • Assoziationen die durch das Anhören von Songs hervorgerufen wurden (Ereignisse/Gefühle) rufen oft Erinnerungen an andere Songs hervor ("Ecken"-Konzept: Song A -> Event/Emotion -> Song B)
    • "Sometimes when I listen to things it triggers [...] me that I want to listen to one of those [...] CDs" --> Song-Album-Assoziation
    • Menschen nutzen die Listening-Histories anderer gerne um sich darüber auszutauschen (Mobile-Prototyp)
Recherche: (gelesen)
  • Downie et al.: Exploring mood metadata: Relationships with genre, artist and usage metadata
    • Es gibt Zusammenhänge zwischen dem Künstler/Genre und der Stimmung der gewählten/gehörten Musikstücke (Stimmung ~ Emotion ~ Ereignis)
  • Pampalk et al.: MusicRainbow: A new user interface to discover artists using audio-based similarity and web-based labeling
    • Schönes GUI-Konzept - keine konkret verwertbaren Infos
  • Pauws et al.: PATS: Realization and user evaluation of an automatic playlist generator
    • Hörumgebung definiert in erheblichem Maße die momentan preferierte Musik
    • Musikgeschmack/Hörgewohnheiten verändern sich mit der Zeit --> Chronologische Ordnung der Histories interessant
  • Crampes et al.: An integrated visual approach for music indexing and dynamic playlist composition
    • [Keine konkret verwertbaren Infos]
  • Pampalk et al.: Dynamic playlist generation based on skipping behavior
    • Menschen "skippen" oft, anstatt eine Playlist manuell umzustellen --> darauf sollte reagiert werden (schon besprochenes "merken"-Feature von Song/History-Choices)
  • Pampalk et al.: Improvements of audio-based music similarity and genre classification
    • Einbeziehung mehrerer, auch user-generierter, Webressourcen zur Ähnlichkeitsbestimmung zwischen Songs wichtig, da eine Quelle oft nur einen "Blickwinkel" (Timbre, Pitch, Genre, etc) abdeckt
  • Logan et al.: A content-based music similarity function
    • Songvorschläge zur Discovery sind nötig, da zu große/unüberschaubare Auswahl vorhanden
  • Simon: Invariants of human behavior
    • Menschen benutzen Heuristiken zur Problemlösung (z. B. zum Suchen von passender Musik) - Stichwort Satisficing
  • Lamere et al.: Using 3D visualizations to explore and discover music
    • Interessantes GUI Konzept
    • Primärzweck der Musik ist Unterhaltung/Stimmungserzeugung, nicht die Aneinander-reihung von Liedern auf komplexe Weise --> Playlist-Generierung sollte einfach und intuitiv sein
  • Brown et al.: Music sharing as a computer supported collaborative application
    • Musik (und damit auch Listening-Histories) wurde schon vor der Digitalisierung geteilt
    • Musik hilft soziale Kontakte zu knüpfen und zu festigen
    • Menschen schätzen die (Musik-)Empfehlungen ihrer Freunde mehr als die anderer, da sie glauben von diesen besser eingeschätzt/verstanden zu werden (gilt auch für Kaufentscheidungen)
    • Mixtape-Analogie
    • "Some enthusiasts even went as far as saying that if someone liked the same music they liked, this created an instant bond which would make friendship far more likely."
    • Menschen mit starken Übereinstimmungen bezüglich ihres Musikgeschmacks haben oft auch weitere übereinstimmende Persönlichkeitsmerkmale
    • Es gibt Menschen die ihr eigenes System entwickelt haben um Napster zum Collaborative Filtering zu missbrauchen
  • Ebare: Digital music and subculture: Sharing files, sharing styles
    • Musikgeschmack ist Basis von Konversationen und sozialen Gefügen
  • Kasaras, K.: Music in the age of free distribution: MP3 and society
    • [Keine konkret verwertbaren Infos]
  • Levitin: This is your brain on music: The science of a human obsession
    • "Musical activity involves nearly every neural subsystem."
    • Es werden die gleichen Hirnzentren zur Stimmungs-Regulierng, Freude und Belohnung sowie beim Musik hören aktiviert
  • Sloboda: Music structure and emotional response: Some empirical findings
    • Musik kann emotionale Stati einleiten, welche wiederum physische Reaktionen hervorrufen
    • Musik hat positiven Einfluss auf Psyche, Motivation und das Selbstbild der Menschen
  • McCarthy et al.: MusicFX: An arbiter of group preferences for computer supported collaborative workouts
    • [Interessante Idee bezüglich Collaborative Filtering, allerings keine konkret verwertbaren Infos]
  • Davis, S.: Can music educate feeling?
    • Musik kann unser Gefühlsleben positiv beeinflussen
    • Musik kann Gefühle beeinflussen, allerdings nicht aktiv anlernen/hervorrufen/trainieren (d. h. die Assoziation muss gegeben sein)
  • Vignoli et al.: Mapping music in the palm of your hand, explore and discover your collection
    • [Keine konkret verwertbaren Infos]
  • Butz, A. et al.: MusicSim: Integrating audio analysis and user feedback in an interactive music browsing UI
    • Menschen wollen ihre Library nach Stimmung/sozialer Aktivität oder akustischer Ähnlichkeit durchsuchen --> Lied in Playlist gewählt --> Kontext gegeben --> SongSlope sollte passende Histories zeigen
    • Musik wird mit sozialen Ereignissen verbunden --> Lied-A - Ereignis - Lied-B - Konzept
    • Album-Konzept sehr wichtig --> Cover-Art muss unbedingt in SongSlopeII
    • Genre nur von Interesse, wenn der Interpret unbekannt ist, ansonsten ist der Interpret ausschlaggebend
  • Logan, B.: Music recommendation from song sets
    • [Keine konkret verwertbaren Infos]
  • Pampalk, E.: Islands of Music: Analysis, organization and visualization of music archives
    • [Schöne Visualisierung - keine konkret verwertbaren Infos]
  • Cunningham et al.: An ethnographic study of music information seeking: implications for the design of a music digital library
    • Gezielte Suche ist oft gefolgt von ungezielter Suche --> Hat der User einen Song gefunden den er abspielt, kann SongSlopeII die ungezielte Suche gut unterstützen
    • Ungezielte Suche kann eine gezielte Suche inspirieren --> Hat der User begonnen in den Histories zu "browsen" kann ihn dass wieder zu einer gezielten Suche nach einem bestimmten Musikstück führen --> Lied A - Lied B - Assoziation!
    • "Current music retrieval systems generally strictly differentiate between searching and browsing, forcing users to choose to engage in one or the other [...]". --> Das kann SongSlopeII gut unterstützen/verbessern
    • Musik wird häufig an Hand von Cover-Art identifiziert/eingeordnet --> Cover-Art sehr wichtig! Unbedingt in SongSlopeII einbinden!
    • Menschen erinnern sich an Cover-Art aus der Kindheit und verbinden dadurch Erinnerungen mit Musik, welche Assoziationen zu weiterer Musik zulässt --> Lied A - Ereignis/Emotion - Lied B - Konzept!
    • Coverart ist teilweise einziges Auswahlkriterium für Musik
  • Logan, B.: Content-based playlist generation: exploratory experiments
    • [Keine konkret verwertbaren Infos]
  • Tseng, Y.-H.: Content-based retrieval for music collections
    • [Keine konkret verwertbaren Infos]
  • Platt, J. C.: Fast embedding of sparse music similarity graphs
    • [Keine konkret verwertbaren Infos]
  • Baur, D. et al.: Gaining musical insights: Visualizing multiple listening histories
    • Genre könnte bei fremden/unbekannen Liedern wichtig sein --> sollte in irgend einer Form eingeblendet werden
  • Baur, D. et al.: Pulling strings from a tangle: Visualizing a personal music listening history
    • Personalisierung (z. B. in Form von Histories) ist ein zentraler Punkt bei Musik-Empfehlungs-Systemen
    • SongSlopeII beruht (im Discovery-Use-Case) auf Crowdsourcing
    • Jede History kann als Playlist betrachtet werden
    • "Songs that follow one another in this adjusted history [...] can be assumed to have some connection in the user's mind [...]." --> Lied A - Lied B - Konzept!
    • Die SongSlopeII UI spiegelt im wesentlichen die UI-Idee "Connecting Strings by Knots" wieder
    • Liederreihenfolge bleibt im Gegensatz zu anderen Recommendation-Systemen erhalten
    • Songs die vom User übersprungen werden (in Playlists oder Alben) tauchen in der History nicht auf --> Personalisierung
    • "[...] in order to pick up the community idea behind Last.fm it might be interesting to combine listening histories for different users to a single visualization [...]" --> Genau das haben wir vor
    • Im Wesentlichen spiegelt das Paper die Basisidee von SongSlopeII wieder und bearbeitet viele der Themen, die im Paper als "further research" genannt werden
  • Baur, D. et al.: Rush: Repeated recommendations on mobile devices
    • Benutzerfreundlichkeit: Favorisierter History Zweig sollte mittig erscheinen
  • Vignoli, F.: Digital music interaction concepts: A user study
    • "Album"-Konzept sehr wichtig (besonders Cover) --> wichtig für GUI
    • Genre für Einordnung unbekannter Musikstücke wichtig --> wichtig bei fremden Histories/Liedern
    • QBE meist sehr wünschenswert
  • Kim, J. et al.: Categories of music description and search terms and phrases used by non-music experts
    • Menschen verbinden Ereignisse/Gefühle mit Musikstücken (im Kontext Suchen/Beschreiben) --> "Ecken"-Konzept: Lied A ~ Ereignis/Gefühl ~ Lied B
  • Lambiotte, R. et al.: Uncovering collective listening habits and music genres in bipartite networks
    • [Keine konkret verwertbaren Infos]
  • Schwartz, B.: The Paradox of Choice (Interview/Podcast)
    • Zuviele Wahlmöglichkeiten sind evil --> nicht zuviele Histories anbieten! (default Wert niedrig (~5), höhere durch customizing, wie besprochen)
  • Andric, A. et al.: Automatic playlist generation based on tracking user's listening habits
    • Durch die Masse an verfügbarer Musik kennen die User oftmals nicht jedes Lied ihrer Library
    • Es gibt eine gewisse Assoziation von Nähe/Distanz zwischen zwei Liedern --> Lied A - Lied B - Assoziation
    • Reihenfolge der Lieder in einer Playlist ist wichtig --> diese sollte theoretisch von SongSlopeII erhalten bleiben
    • Das Interesse an bestimmten Playlists/Lieder verhält sich wellenförmig --> SongSlopeII sollte darauf eingehen, indem nicht nur die "Neuesten", sondern vergleichbar mit Rush, auch ältere Histories angezeigt werden
    • Problem der ersten Playlist --> Übertragbar auf SongSlopeII-User ohne last.fm-History
Recherche: (noch zu lesen)
  • Pauws et al.: Programming and enjoying music with your eyes closed (CHI2000)
-- DominikusBaur - 26 Apr 2010 -- HansPeterDietz - 08 May 2010 -- HansPeterDietz - 19 May 2010 -- HansPeterDietz - 04 Jun 2010 -- HansPeterDietz - 05 Jun 2010 -- HansPeterDietz - 30 Jun 2010 -- HansPeterDietz - 09 Aug 2010
Topic revision: r22 - 09 Aug 2010, HansPeterDietz
 
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Medieninformatik-Wiki? Send feedback