Lokale Musik: Konzerte als Datenpunkt für Empfehlungen

Aus drei Jahrzehnten Konzerttickets wird ein Datensignal#

Es gibt kaum ein bedeutungsvolleres Bekenntnis zu einer Band, als sich ein Ticket zu kaufen, anzureisen und einen Abend lang in der Menge zu stehen. Ein gestreamter Song kostet nichts und sagt wenig. Streaming ist Beifang. Ein Konzert ist eine Entscheidung.

Genau dieses Signal wollte ich meinem Musik-Setup beibringen. Nur lagen die Daten dafür nirgends sauber vor — sie steckten in Jahre alten E-Mails und in einem Haufen voller gescannter Papiertickets. Das muss alles irgendwie importiert und sinnvoll genutzt werden können. Ich habe die beiden Haufen Claude gegeben, damit es sich dort durcharbeiten kann.

Runde 1: Alte Bestell-E-Mails#

Die erste Quelle waren Bestellbestätigungen als .eml-Dateien — einzeln gespeicherte Mails von Ticketshops. Sauber war daran wenig: Mal Deutsch, mal Englisch, mal reiner Text, mal HTML und natürlich die Daten in Tabellenstrukturen vergraben.

Aus jeder Mail wurden Künstler, Datum, Stadt, Ort und gegebenenfalls das Festival herausgelesen. Und überall, wo etwas mehrdeutig war — krude Datumsformate, Sammelbestellungen, Vorbands, abweichende Schreibweisen — wurde nachgefragt statt geraten.

Runde 2: Papiertickets#

Die älteren Konzerte existierten nur noch als eingescannte Papiertickets, gesammelt in ~/Downloads/konzerte/: verblasst, schief eingelegt, handschriftlich ergänzt.

Aus den Bildern wurden Künstler, Datum, Ort, Location und Preis übernommen. War ein Ticket schwer lesbar, wurde Stück für Stück im Dialog korrigiert. So wuchs die Historie rückwärts, bis ins Jahr 1994.

Festivals: Das Line-up rekonstruieren#

Auf dem Ticket steht oft nur der Festivalname — für die Bewertung zählt aber nicht „ich war auf Festival X”, sondern welche Künstler ich dort tatsächlich gesehen habe.

Also habe ich die Line-ups über setlist.fm ↗ und weitere Quellen rekonstruieren lassen. Man sieht auf einem Festival nie alle Bands. Darum wurde anschließend pro Festival einzeln entschieden, welche Künstler in die Liste kommen.

Was am Ende dabei herauskam#

198 Einträge zu 119 verschiedenen Künstlern. Jede Zeile ist ein einzelner Künstler-Besuch — ein Festival erzeugt also mehrere Zeilen, eine pro Band. Jeder Eintrag bleibt bewusst schlicht:

{"artist": "Bolt Thrower", "date": "2012-04-07", "city": "London",
 "country": "GB", "venue": "HMV Forum", "festival": "Boltfest 2012"}

Vollständig ist die Liste nicht, und das gibt sie auch nicht vor. Tickets gehen verloren, Erinnerungen verblassen, bei manchen Altfällen ist nur noch das Jahr sicher. Genau dafür darf das Datum auch nur den Monat oder das Jahr enthalten — die Auswertung kommt mit allen drei Genauigkeiten zurecht. Es ist ein „so gut, wie es die Quellen hergeben”, kein Anspruch auf Lückenlosigkeit.

Wofür das Ganze gut ist#

Die Konzerte fließen in die täglich neu berechnete Künstler-Bewertung ein und werden dort in mehreren Ebenen bewertet:

• Je frischer, desto stärker. Ein anstehendes Konzert (Ticket schon gekauft) wiegt am meisten, ein Besuch im letzten Jahr voll, ältere klingen gestaffelt ab. Die Bewertung spiegelt so, wofür ich mich gerade begeistere — nicht nur, was ich vor zwanzig Jahren mochte.
• Anreise zählt doppelt. Konzerte außerhalb meiner Heimatstädte Berlin und Hamburg werden doppelt gewichtet, denn die Band muss mir wichtig sein, wenn ich ihr hinterher reise.

Diese gewichteten Besuche summieren sich pro Künstler und gehen als stärkstes Einzel-Signal in die Gesamtbewertung ein. Weil diese Bewertung wiederum Release Radar, Discovery-Playlist, Künstler-Radio und die geplante Konzert-Mail speist, wirkt ein einziger Eintrag in concerts.json an vielen Stellen gleichzeitig: Eine Band, die ich live erlebt habe, rückt überall ein Stück nach vorn — und verblasst langsam wieder, wenn der letzte Besuch lange zurückliegt.

Das Setup hinter diesen Beiträgen#

Die Idee#

Ich baue Spotify-Funktionen wie Wrapped, Daylist, Radio, Release Radar und Discovery zu Hause nach, auf Basis meiner eigenen, in hoher Qualität gespeicherten Musiksammlung (FLAC-Dateien) und kostenloser Datenquellen. Ohne Abhängigkeit von Spotify, voll automatisiert, und Songs, die ich (noch) nicht besitze, kommen über YouTube dazu.

Jede dieser Funktionen erzeugt am Ende eine .m3u-Datei — eine simple Playlist-Textdatei, die entweder lokale Dateien oder YouTube-Links auflistet. Abgespielt wird sie im Mac-Player IINA.

KI als Kommandozeile#

Die Funktionen sind als Python-Skripte implementiert und können manuell oder automatisiert (cron) gestartet werden. bequemer ist allerdings ein KI-Tool, welches natürlichsprachige Anfragen interpretieren, ausführen und die erzeugte Playlist direkt abspielen lassen kann:

Erstelle und spiele ein Radio für “Against the Current”

Spiele Death Metal

Spiele 90er Metal/Crossover

Spiele die ersten beiden Alben von Gracie Abrams

Spiele das aktuelle Album von Taylor Swift

Die Datenquellen#

Vier Quellen liefern das Rohmaterial:

Dazu kommt eigene Handarbeit: kuratierte Lieblings-Playlists je Künstler oder Album (playlist_data/), eine Liste besuchter und geplanter Konzerte (concerts.json) und eine Einkaufsliste fehlender Musik.

Die Bausteine (Skripte)#

Kleine Python-Programme, jeweils für eine Aufgabe. Grob nach Zweck:

• Profile bilden — welche Künstler/Songs sind mir wichtig? interesting_artists.py (Künstler-Rangliste), track_plays_snapshot.py, loved_snapshot.py.
• Playlists erzeugen (die Spotify-Pendants) — daylist.py (Mix nach Tageszeit), radio.py (Künstler-Radio), discovery_yt_playlist.py (neue, unbekannte Künstler), on_repeat.py, rediscovery.py.
• Entdecken & pflegen — release_radar.py (neue Veröffentlichungen meiner Künstler, als E-Mail), einkaufsliste.py (was mir noch fehlt).
• Rückblicke — wrapped_month.py (monatliche „Wrapped”-Grafiken), generate_topsongs_csv.py (Jahres-Top-100).
• Migration — match.py ordnet einen Spotify-Playlist-Export den lokalen Dateien zu.

Wann was läuft (Automatik per Cron)#

Cron ist ein Zeitplaner des Betriebssystems: er startet Programme automatisch zu festen Zeiten. Mein Zeitplan:

Das Radio (radio.py) läuft bewusst nicht automatisch, sondern auf Zuruf, wenn ich ein Radio für einen bestimmten Künstler will.

Caches (warum es schnell und höflich bleibt)#

Abfragen an Last.fm, MusicBrainz und YouTube sind langsam und haben Limits — MusicBrainz erlaubt z.B. nur eine Anfrage pro Sekunde. Deshalb wird jede Antwort lokal zwischengespeichert (ein Cache unter ~/.cache/lastfm-mb/, aktuell ~150 MB). Die zweite Abfrage derselben Sache ist dann sofort da, und die Dienste werden nicht unnötig belastet.

Grob drei Gruppen: Last.fm (Hörhistorie, ähnliche Künstler, Tags), MusicBrainz (Künstler-Steckbriefe, Releases, Band-Mitglieder) und YouTube Music (ähnliche Künstler, Alben).

Wichtig: Manche Caches dürfen nicht ewig gelten — „ähnliche Künstler” und „neue Releases” sollen aktuell bleiben. Darum werden ausgewählte Bereiche wöchentlich gelöscht (donnerstags) bzw. beim Release Radar bewusst frisch geladen.