dschlueter
1ca88b0d6d
Shorter, cleaner filenames consistent with Jellyfin conventions. Updated all references in source, tests, and documentation. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
77 lines
3 KiB
Markdown
77 lines
3 KiB
Markdown
# Refactoring-Plan: Workflow-Phasen in ripper.py
|
||
|
||
*Stand: 2026-02-19 — Entwurf zur Diskussion*
|
||
|
||
## Aktueller Zustand
|
||
|
||
`interactive_rip` ist eine ~400-Zeilen-Funktion mit zwei verschränkten Pfaden
|
||
(MB-Hit vs. Fallback), die alles in einem monolithischen Block erledigt.
|
||
Die `apply`-Seite ist bereits sauber getrennt (organizer → tagger → playlist).
|
||
|
||
## Vorschlag: 7 logische Phasen
|
||
|
||
### Phase 1: Album-Identifikation (EAN / Barcode)
|
||
- EAN-Eingabe per Tastatur oder Foto-Scan
|
||
- Vision-LLM: Barcode aus Foto extrahieren
|
||
- MusicBrainz-Lookup per EAN → Album-Struktur + MBID
|
||
- Ergebnis: `ean`, `mb_album`, `mb_mbid` (oder alles None)
|
||
|
||
### Phase 2: Cover-Beschaffung
|
||
- CAA-Download (front.jpg, back.jpg) per MBID
|
||
- Foto-Upload per Scanner-Server (Backcover, ggf. Frontcover)
|
||
- `prepare_cover()` für Jellyfin-Format
|
||
- Ergebnis: Cover-Dateien im album_root
|
||
|
||
### Phase 3: Backcover-Analyse (parallel zu Phase 4)
|
||
- Vision-LLM auf Backcover-Foto → vollständige Album-Metadaten
|
||
- Läuft als Background-Thread während des Rippens
|
||
- Ergebnis: `vision_album: Album | None`
|
||
|
||
### Phase 4: Audio-Ripping (pro Disc)
|
||
- Disc einlegen → abcde starten (cdparanoia + Encoder)
|
||
- CDDB-Lookup als Nebenprodukt von abcde
|
||
- CDDB-Bestätigung durch User (Fallback-Pfad)
|
||
- Audio-Dateien in album_root/CDn/
|
||
- Ergebnis: Audio-Dateien + `cddb_tracks` pro Disc
|
||
|
||
### Phase 5: Metadaten-Zusammenführung (Priorität: Vision > MB > CDDB)
|
||
- Vision-LLM-Ergebnis einsammeln (Timeout 120s)
|
||
- Beste Quelle auswählen nach Priorität
|
||
- Album-Name, Artist, Year, Genre, Tracklist konsolidieren
|
||
- Ergebnis: `final_album: Album`
|
||
|
||
### Phase 6: album.json erzeugen + Apply-Hint
|
||
- `final_album` serialisieren → album.json
|
||
- Kopierbaren `apply`-Befehl ausgeben
|
||
- **Hier endet `rip`** — User prüft/editiert JSON manuell
|
||
|
||
### Phase 7: Apply (bereits separater CLI-Befehl)
|
||
- Datei-Mapping erstellen (organizer)
|
||
- Umbenennen/Verschieben (sanitize_filename)
|
||
- Audio-Tagging (mutagen)
|
||
- Cover-Embedding
|
||
- M3U-Playlist generieren
|
||
|
||
## Strukturelle Beobachtungen
|
||
|
||
### Was heute vermischt ist
|
||
- Phase 1–6 stecken alle in `interactive_rip()` mit if/else-Verzweigung
|
||
für MB-Hit vs. Fallback
|
||
- Die Disc-Schleife (Phase 4) enthält Logik aus Phase 2 (Cover-Upload
|
||
während Disc-Insert) und Phase 3 (Vision-Thread starten)
|
||
- Phase 5 ist dupliziert: einmal im MB-Pfad (Zeile ~791), einmal im
|
||
Fallback-Pfad (Zeile ~956)
|
||
|
||
### Was eine Refaktorierung bringen würde
|
||
- Die zwei Pfade (MB-Hit / Fallback) konvergieren nach Phase 4 — ab Phase 5
|
||
ist die Logik identisch, aber heute kopiert
|
||
- Cover-Beschaffung ist über den ganzen Code verstreut (CAA-Download,
|
||
Scanner-Upload während Disc-Insert, Backcover-Save am Ende)
|
||
- Die Vision-LLM-Steuerung (Thread starten, Ergebnis einsammeln) könnte ein
|
||
eigenes Objekt/Kontext sein
|
||
|
||
### Offene Frage
|
||
Soll die Disc-Schleife (Phase 4) eine einheitliche Schnittstelle haben, die
|
||
beide Pfade bedient? Im MB-Pfad ist die Disc-Anzahl bekannt, im Fallback-Pfad
|
||
offen (while-Schleife mit "Nächste CD?"). Das ist der größte strukturelle
|
||
Unterschied.
|