feat(windows): Audio-CDs rippen — die letzte Luecke ist zu

Commander: „mach es"

Gemeint war die Lücke, die seit Wochen so im SAVEPOINT stand: **Audio-CDs
laufen unter Windows nicht.** `cdparanoia` und `abcde` sind Linux-Werkzeuge.

## Nicht abcde nachbauen — den Windows-Weg gehen

Eine Audio-CD hat kein Dateisystem. Die `Track01.cda`, die Windows zeigt,
sind 44 Byte grosse Platzhalter; die Musik liegt roh in 2352-Byte-Sektoren.
Windows bietet dafuer zwei Steuercodes an:

    IOCTL_CDROM_READ_TOC   Inhaltsverzeichnis (MSF je Spur, Audio/Daten)
    IOCTL_CDROM_RAW_READ   die Sektoren selbst

Gegengeprueft, dass die berechneten Codes den dokumentierten entsprechen:
0x24000 und 0x2403e.

Kodiert wird mit dem FLAC-Encoder vom offiziellen Xiph-Spiegel (1.5.0), den
Rippy beim Einrichten holt — wie MakeMKV. KEIN Pflichtwerkzeug: Ohne ihn
laeuft alles ausser Audio-CDs, und ein Fehlschlag darf das Einrichten nicht
truebe machen.

## Zwei Fallen, beide gemessen

**Die Leseadresse zaehlt in 2048er-Einheiten**, obwohl ein Audio-Sektor 2352
Bytes hat. Das ist dokumentiert und sieht falsch aus; mit 2352 liest man an
der falschen Stelle.

**`flac.exe` braucht `libFLAC.dll` daneben.** Mit nur der exe endete jeder
Aufruf mit 0xC0000135 — „DLL nicht gefunden" — und zwar ohne eine einzige
Zeile Ausgabe. Jetzt wird der ganze Win64-Ordner ausgepackt.

## Was geprueft ist

Ein Laufwerk und eine Audio-CD lassen sich in der Ampel nicht herstellen.
Deshalb steht alles Rechenbare in reinen Funktionen — MSF↔LBA, das Zerlegen
der TOC-Bytes, WAV-Kopf, Blockaufteilung, Dateinamen — und der Ablauf
bekommt Laufwerk und Encoder eingespritzt. 28 Tests dafuer.

Zusaetzlich mit dem ECHTEN Encoder gemessen: zwei Spuren erzeugten Tons
gerippt, und **FLAC bestaetigt seine eigenen Dateien** (`flac -t`, Code 0).
Am echten Laufwerk gegengeprueft, dass das Inhaltsverzeichnis gelesen wird —
die eingelegte Blu-ray meldet sich korrekt als DATEN-Track und wird nicht als
Musik behandelt.

Was noch fehlt: MusicBrainz-Tags. Die Dateien heissen `Track 01.flac`. Der
Weg dafuer steht (`tags_je_spur`), die Disc-Kennung fuer die Abfrage nicht.

915 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

SAVEPOINT.md

@@ -1,6 +1,56 @@
 # SAVEPOINT — Rippy
 
-## Aktueller Stand: v4.0-rc7 — vier Befunde, drei mit derselben Wurzel (29.08.2026)
+## Aktueller Stand: v4.0-rc8 — Windows vollständig (29.08.2026)
+
+> **Der Rundgang durch die Docker-Reste ist durch, und die Audio-CD-Lücke ist
+> zu.** 915 Tests grün.
+
+### Die letzte Lücke: Audio-CDs
+
+`cdparanoia` und `abcde` gibt es für Windows nicht — ein Nachbau ihrer
+Shell-Logik wäre ein zweites Projekt gewesen. Gebaut ist stattdessen der Weg,
+den Windows selbst anbietet:
+
+* **Lesen** macht Rippy selbst über zwei Win32-Steuercodes. Eine Audio-CD hat
+  kein Dateisystem; die `Track01.cda`, die Windows zeigt, sind 44 Byte große
+  Platzhalter. Die Musik liegt roh in 2352-Byte-Sektoren.
+* **Kodieren** macht der FLAC-Encoder, den Rippy beim Einrichten holt
+  (offizieller Xiph-Spiegel, Fassung 1.5.0). Kein Pflichtwerkzeug: Ohne ihn
+  läuft alles außer Audio-CDs.
+
+Gemessen: FLAC 1.5.0 geladen, zwei Spuren gerippt, **und FLAC selbst bestätigt
+seine Dateien** (`flac -t`, Code 0). Am echten Laufwerk gegengeprüft, dass das
+Inhaltsverzeichnis gelesen wird — die eingelegte Blu-ray meldet sich korrekt
+als *Daten*-Track und wird nicht als Musik behandelt.
+
+Zwei Fallen stecken in der Sache, beide dokumentiert und beide im Code
+begründet: Die Leseadresse zählt in **2048er**-Einheiten, obwohl ein
+Audio-Sektor 2352 Bytes hat. Und `flac.exe` braucht `libFLAC.dll` daneben —
+mit nur der exe endet jeder Aufruf mit „DLL nicht gefunden", ohne eine Zeile
+Ausgabe.
+
+### Was der Rundgang sonst noch fand
+
+**`/dev/{name}` in drei Endpunkten.** Das UI ruft sie mit der Kennung `G` auf,
+gebaut wurde `/dev/G` — **Auswerfen und „Disc scannen" antworteten unter
+Windows immer mit 404.** Beide Treiber lösen die Kennung jetzt selbst auf.
+
+**`os.path.isdir("/app")` zum zweiten Mal**, jetzt in `ablauf.py`: Rippy hielt
+sich für einen *fremden* Worker.
+
+**`shutil.which` in `schluessel.py`** — ausgerechnet im Modul, das es nur unter
+Windows gibt. Die Disc-Schlüssel-Automatik für 4K-UHD lief nie an.
+
+Dazu ein Wächter-Test: Er prüft ab sofort **mechanisch**, dass im Windows-Weg
+kein Container-Pfad ohne Begründung steht.
+
+### HandBrakes „Code 0"
+
+Code 0 heißt **Erfolg**. Rippy meldete trotzdem „fehlgeschlagen", weil die
+Datei nicht am erwarteten Ort lag: HandBrake bestimmt den Container aus dem
+**Preset**, nicht aus der Endung. Jetzt wird er erzwungen.
+
+## Letzter Stand davor: v4.0-rc7 — vier Befunde, drei mit derselben Wurzel (29.08.2026)
 
 > Setup auf dem Desktop, `7b0c41d`, **852 Tests grün**.
 
@@ -410,11 +460,13 @@ und `shutil.which("makemkvcon")` — das findet unter Windows nie etwas.
 Ergebnis an der echten Disc: `Neon Genesis Evangelion` (1995), Confidence
 0,8, Fingerabdruck `BD_EVG_D2|48149364736`.
 
-### ⚠️ BEKANNTE LÜCKE: Audio-CDs laufen unter Windows NICHT
+### ~~BEKANNTE LÜCKE: Audio-CDs laufen unter Windows NICHT~~ — geschlossen (29.08.2026)
 
 `cdparanoia` (Titelliste) und `abcde` (Rippen) sind Linux-Werkzeuge und
-werden nicht mitgeliefert. Die CD wird erkannt, aber nicht gerippt. Steht
-bewusst hier statt versteckt im Code.
+werden nicht mitgeliefert. Die CD wurde erkannt, aber nicht gerippt.
+
+**Seit dem 29.08.2026 geht es** — nicht mit einem Nachbau von abcde, sondern
+über den Weg, den Windows selbst anbietet. Siehe den aktuellen Stand oben.
 
 ### Die Lehre dieser Sitzung, viermal bezahlt