mAirList DB Restorer (v0.50.27 Beta) – Automatisierte Metadaten-Pflege für lokale Datenbanken

Deutsch / German Allgemein
1

Moin zusammen!

Mit Torbens ausdrücklicher Genehmigung möchte ich euch heute ein Tool vorstellen, an dem ich in den letzten Wochen intensiv geschraubt habe: den mAirList DB Restorer.

Jeder, der eine Musikdatenbank pflegt, kennt das Problem: Fehlende Jahreszahlen, leere Genre-Felder, unvollständige Labelcodes oder fehlende Alben. Das Tool nimmt diese mühsame Handarbeit ab. Es analysiert eine lokale mAirList SQLite-Datenbank (.mldb), sucht über die APIs von MusicBrainz und Discogs nach den fehlenden Metadaten und schreibt die korrigierten Werte nach eurer Kontrolle sicher in die Datenbank zurück.

Bevor ich zu den Details komme, vorab ein paar klare Worte zu einem Thema, bei dem ich weiß, dass viele hier im Forum ambivalent dazu stehen: Dieses Tool ist mit Unterstützung von Künstlicher Intelligenz (Google Gemini) entstanden.

Mir ist völlig klar, dass das bei einigen Stirnrunzeln auslöst. Aber für mich zählt am Ende, was das Tool leistet und wie viel Arbeit es mir abnimmt. Für die Entwicklung in diesem Umfang hätte ein menschlicher Programmierer – gemessen an der Arbeitszeit und der Komplexität – einen ansehnlichen Betrag aufgerufen. Da ich nicht erwarte, dass sich jemand aus der Community hinsetzt und das mal eben in seiner Freizeit kostenlos für mich baut, bin ich diesen Weg über die KI gegangen.

Mir ist deshalb wichtig, dass wir uns hier im Thread auf das Tool selbst konzentrieren und nicht darauf, wie es entstanden ist. Wer das Skript nutzen möchte, ist herzlich eingeladen, es auszuprobieren. Wer es ablehnt, lässt es einfach links liegen. Konstruktive Kritik, Bug-Reports oder Feature-Wünsche zu den tatsächlichen Funktionen nehme ich natürlich sehr gerne entgegen!

Was das Tool unter der Haube macht (Kern-Features)

  • Smart Cleaning & VIP-Listen: Artist und Titel werden vor der Suche bereinigt (z. B. “feat.”, “ft.”). Notorische Schreibweisen (wie “AC/DC”) werden über ein festes VIP-Dictionary priorisiert.
  • Laufzeit-Matching (Maxi-Erkennung): Das Skript gleicht API-Treffer mit der echten lokalen Track-Laufzeit (+/- Toleranz für Cue-Punkte) ab, um zielsicher Extended Versions, Radio Edits oder Maxi-Mixes zuzuordnen.
  • Ausreißer-Filter: Berechnet den Mittelwert gefundener Release-Jahre und ignoriert absurde API-Ausreißer (z. B. Release-Jahr 1945 für einen 2004er Track).
  • OAD-Schutz (Ignore-Lists): Virtuelle oder physische Ordner (z. B. “OAD” oder “Jingles”) können konsequent von der Suche ausgeschlossen werden.
  • Ergonomischer Review-Prozess: Alle Vorschläge werden in einem Terminal-Workflow geprüft. Mit der O-Taste kann jederzeit auf den ursprünglichen Datenbank-Wert zurückgefallen werden; eigene Texteingaben triggern direkt einen Live-Re-Fetch.
  • Massenbearbeitung (Wartungs-Modus): Ein separates Menü erlaubt das nachträgliche Standardisieren von Genres, das Korrigieren von Groß-/Kleinschreibung (Title Case mit Sonder-Regeln) oder das Löschen von Alt-Attributen (“Platinum Notes”, “Lyrics”) zur DB-Verkleinerung.

Wichtige Einschränkungen (Stand jetzt)

  • Lokale Datenbanken: Das Tool funktioniert aktuell nur mit lokalen SQLite-Datenbanken (.mldb). Eine Unterstützung für Netzwerkdatenbanken steht auf der Wunschliste für spätere Updates.
  • Sprach-Kompatibilität: Die Feld-Zuordnung beim Schreiben in die Datenbank ist derzeit auf deutsche, englische und niederländische mAirList-Installationen optimiert. Weitere Sprachen rüste ich bei Bedarf gerne nach.

Wichtiger Sicherheitshinweis & Disclaimer

  • Keine Garantie: Weder die APIs noch das Skript sind unfehlbar. Falsche Metadaten können gelegentlich vorkommen. Die Nutzung erfolgt auf eigene Gefahr!
  • Immer mit einer Kopie arbeiten: Das Tool schreibt direkt und ohne Undo-Funktion in die Datenbank. Niemals auf der aktiven, von mAirList geöffneten Datei arbeiten! Immer eine Kopie (z. B. auf dem Desktop) erstellen.

Download & Installation

Das Projekt mitsamt einer ausführlichen Schritt-für-Schritt-Anleitung (Manual_DE.md) findet ihr direkt auf GitHub:

:backhand_index_pointing_right: GitHub-Repository: Github Repo

Für den schnellen Start ohne Git-Client:

  1. Geht auf die GitHub-Seite.
  2. Klickt auf den grünen Button “<> Code”.
  3. Wählt “Download ZIP”.
  4. Entpackt die ZIP-Datei in einen Ordner eurer Wahl auf dem PC.
  5. Installiert einmalig Python (mit Haken bei “Add Python to PATH”) und die Pakete (pip install pandas requests rich) über die Eingabeaufforderung.
  6. Startet die Restore.bat und lest das beiliegende Handbuch.

Ich bin gespannt, wie es bei euch läuft!

2

Ich habe gar nichts gegen K„I“, ich weigere mich nur, die Bugs aus von Ahnungslosen erfragten Skripten zu klauben.

3

Das soll hier auch keiner, das obliegt mir… :upside_down_face:

Ich muss nur wissen, wo etwas klemmt (nicht im Code sondern in den Funktionen) oder optimiert werden könnte. Mir fällt auch nicht alles auf, auch wenn ich mir Mühe gebe, soviel wie möglich abzufangen.

Und ich bin fleissig auf der Suche, speziell auch um die ‘Usability’ zu erhöhen und die dazugehörige Dokumentation. Prinuipiell funktioniert alles, wie es soll, aber es gibt immer noch eine Mengge Stellschrauben. Deshalb Beta-Status, deshalb die 10.000 eingebauten Warnungen, sowohl im Tool selbst als auch in der Doku. :thinking:

4

Mittelwert?
Da merke ich auf und melde Skepsis an. Wenn es hier schon zu unterschiedlichen Recherche-Ergebnissen kommt, sollte das als Zweifelsfall markiert werden. Da ist menschliche Korrektur nötig, und der “Datenbank-Redakteur” :slightly_smiling_face: muss entscheiden, welcher Wert unter welcher Voraussetzung “gewinnt”.
Beim Stichwort “Mittelwert” habe ich Bedenken.

Das ist ein Punkt, bei dem ich bei “meinem” Sprachmodell die Notbremse gezogen habe.
Myka und ich haben parallel an der vergleichbaren Idee gearbeitet, aber er war schneller “auf dem Markt”.
Auch bei mir kam der Moment des “mach es mit Python”. Ich habe auch nichts dagegen, Python zur Programmierung zu nutzen, aber eben nicht mehr, wenn es um die Weitergabe an die breite Öffentlichkeit geht.

Meinen Radiokollegen würde ich das nicht empfehlen, wenn sie extra dafür Python installieren müssten - einmalig hin oder her.

Es kommt ein anderer Aspekt hinzu: Da ich mich nie auf ein Sprachmodell alleine verlasse und wichtige Aussagen immer von der Konkurrenz gegenprüfen lasse: Ich werde bei mir Python installieren, weil ich ein Programm nutzen möchte, das Python als Basis zwingend braucht. Zwei “KI”-LLMs haben mir das Programm vorgeschlagen; die eine hat die Python-Voraussetzung glatt verschwiegen, die andere gab mir gleich einen wertvollen Tipp:

Empfehlenswert: eine virtuelle Umgebung (python -m venv venv), damit das […]-Projekt nicht mit anderen Python-Sachen auf dem System kollidiert – bei nur einem Projekt aber auch verzichtbar

Das brachte mich ins Grübeln. Weiß ich denn, wie es auf dem PC desjenigen aussieht, der den “DB Restorer” nutzen möchte? Und dass er daran denkt, das zu beachten, wenn auch ihm die “KI” was mit Python auf den Rechner gepackt hat?
Merke: “KI” liebt Python und empfiehlt das besonders schnell.

Ich lasse meine konkurrierenden Sprachmodelle noch etwas weiter basteln, bis ich eine Lösung gefunden habe, die noch ein wenig anwenderfreundlicher ist. Und wenn es nicht klappt, veröffentliche ich nichts.

Nix für ungut, Myka, viel Erfolg für dein Projekt. Das ein oder andere Informatik-Stirnrunzeln (API-Abfrage-Frequenz) kennst du ja bereits und ich hoffe, dass das in deine Beta schon eingearbeitet wurde.

5

Vielen Dank, und ja, das wurde es (1,5 Sekunden Timeout).

Zur Python-Nutzung: In einem der nächsten Updates wird noch nachgeliefert, dass das Tool sich die nötigen Pakete selbst holt. Sobald die Kernfunktionen zufriedenstellend laufen, wird aus dem Skript eine ausführbare EXE-Datei, bei der Python + benötigte Bibliotheken bereits integriert ist (und vielleicht sogar ein richtiges Windows-GUI, aber das ist mehr als nur Zukunftsmusik).

Zutreffender wäre wohl “am ehesten wahrscheinlich”. Beim Review der gefundenen Daten (Hinweis: Ohne “Review” gibt es keine Speicherung in der DB) schlägt das Tool den Wert vor, den man entweder direkt übernehmen kann, oder den Originalwert aus der DB nehmen oder händisch einen Wert eintragen kann. Im letzteren Fall sucht das Tool erneut, basierend auf den geänderten Werten.

Prinzipiell ist es schlicht nicht möglich, eine hundertprozentige Trefferquote zu erreichen, die Gründe dafür liegen auf der Hand. Das Tool übernimmt nicht blind, die Ergebnisse werden in drei Konfidenz-Stufen eingeteilt, und selbst bei Stufe “hoch” wird man trotzdem gefragt.

Ich weiß, es steht noch eine Menge Optimierungsarbeit an, aber mit dem aktuellen Versionsstand wird wirklich schon eine Menge abgefedert. :slight_smile:

Danke für deine konstruktive Meinung, das ist für mich Gold wert! :hugs:

6

@Myka Tipp: Es gibt bei Discogs den Wert „Erste bekannte Veröffentlichung“.

Das nutze ich mit einem VB-Script in MediaMonkey und es passt eigentlich immer (bei Titeln vor 2015).

Dann braucht man auch keine Ausreißer bei Compilations fürchten (hallo „Abba „Gold““) :smirking_face::nerd_face:

7

Das halte ich für ein erstrebenswertes Ziel.

8

Gesagt, getan:

:face_blowing_a_kiss:

9

Das interessiert mich, wo finde ich diesen Wert?