Radio?Mario! | Warum aus einem Radioplayer ein CD-Ripper mit Mehrraum-Streaming wurde

Internetradio → CD-Archiv → Mehrraum-Wiedergabe · Tauri 2 · Rust und Vanilla JavaScript

Das hier ist eine Eigenentwicklung, und sie hat den typischen Verlauf genommen. Am Anfang stand ein überschaubarer Wunsch, am Ende stehen dreiundzwanzigtausend Zeilen Code und drei Programmteile, die miteinander wenig zu tun haben und trotzdem zusammengehören.

Wie es anfing

Ich wollte Internetradio hören, ohne dafür einen Browsertab offen zu halten, und ohne dass ein Anbieter mitschreibt, was ich höre. Es gibt ein freies Verzeichnis mit über dreißigtausend Sendern und einer offenen Schnittstelle. Daraus einen kleinen Spieler zu bauen, ist ein Wochenendprojekt.

Dann kam der zweite Gedanke. Wenn die Anwendung ohnehin Audio abspielt und Titel erkennt, könnte sie auch die CDs einlesen, die im Regal stehen. Und wenn sie schon ein Archiv verwaltet, könnte sie das auch auf die Lautsprecher im Haus verteilen.

Genau so entstehen die Projekte, die man ein Jahr später noch anfasst.

Der erste Teil: Radio

Die Senderliste kommt aus dem offenen Verzeichnis, filterbar nach Land, Sprache, Genre und Beliebtheit. Dazu kommen die Dinge, die man beim täglichen Hören merkt und die in fertigen Programmen oft fehlen.

• Eine Titelverfolgung, die aus dem Datenstrom mitliest, was gerade läuft, und daraus eine Liste über die Zeit baut.
• Aufnahme auf Tastendruck.
• Eine Lautstärkeanhebung, die sich je Sender merkt, wie viel nötig war. Sender sind unterschiedlich laut, und das nervt genau so lange, bis es jemand löst.
• Eine Spektrumanzeige, die tatsächlich das anzeigt, was läuft.

Dazu Anbindungen an mehrere Musikdienste und an Videoplattformen, damit man die Anwendung nicht verlassen muss, wenn man einen Titel nachhören will, den man im Radio aufgeschnappt hat.

Der zweite Teil: der CD-Ripper

Hier steckt die meiste Arbeit, und hier war der Anspruch von Anfang an ein bestimmter. Es gibt seit vielen Jahren ein Programm, das für sauberes Einlesen von Audio-CDs als Maßstab gilt. Was dieses Programm kann, sollte meines auch können.

Zwei Lesearten

Die schnelle nutzt den Weg, den das Betriebssystem ohnehin bereitstellt. Reicht für die meisten Scheiben.

Die sichere liest bitgenau, mit einstellbarem Versatz für das jeweilige Laufwerk. Jedes Laufwerk liest ein paar Abtastwerte früher oder später als das Original, und wer das nicht ausgleicht, bekommt eine Kopie, die sich nicht gegen die Referenz prüfen lässt. Das dauert länger und ist der Weg für Scheiben, bei denen es darauf ankommt.

Die Prüfung, die den Unterschied macht

Nach dem Einlesen wird für jeden Titel eine Prüfsumme berechnet und gegen eine öffentliche Datenbank abgeglichen, in der die Prüfsummen anderer Leute für dieselbe Pressung liegen. Stimmen sie überein, ist die Kopie belegbar korrekt.

Das Ergebnis wird ehrlich ausgewiesen. Bestätigt, bestätigt nach älterem Verfahren, in der Datenbank aber andere Pressung, gar nicht in der Datenbank, oder übersprungen. Der Unterschied zwischen „nicht gefunden» und „gefunden und abweichend» ist wichtig, und die meisten Programme verwischen ihn.

Was pro Scheibe entsteht

Die Tonspuren, wahlweise in mehreren Formaten gleichzeitig über vier parallele Encoder. Das Titelbild aus einer öffentlichen Datenbank. Eine Indexdatei, mit der sich die ursprüngliche Scheibe rekonstruieren lässt. Und ein Protokoll im gewohnten Format mit Prüfsummen, Pegeln und dem Ergebnis der Lautheitsanpassung.

Dazu ein Eintrag in der Archivdatenbank, damit man später weiß, was man hat.

Die Scheibe rein, den Rest macht die Anwendung

Der Teil, den ich selbst am meisten benutze. Ein Hintergrunddienst schaut alle paar Sekunden nach, ob eine Scheibe eingelegt wurde, erkennt selbst, um was für eine es sich handelt, und behandelt sie entsprechend.

Eine Audio-CD wird gerippt, verschlagwortet und ausgeworfen. Eine Datenscheibe wird zu einem Abbild. Bei Film-Scheiben übernimmt ein externes Werkzeug, ein Nachschlagedienst besorgt Titel und Jahr, und daraus wird ein sauber benannter Ordner.

Jeder Vorgang landet in einer Warteschlange mit Zustand und Verlauf, mit Meldungen in Echtzeit. Wer will, bekommt eine Nachricht auf einen Dienst seiner Wahl, wenn etwas fertig ist oder schiefgeht.

Der dritte Teil: Musik im ganzen Haus

Das Archiv soll nicht nur am Rechner spielen, sondern auf den Lautsprechern, die ohnehin herumstehen. Die Anwendung sucht sie im Netz und kann jedem einzeln etwas anderes schicken.

Hier lagen die drei technisch interessantesten Probleme, und die sind mir am Ende die liebsten.

Der Umweg, den ich weggeworfen habe

Für Apples Übertragungsweg gab es zunächst einen Behelf über ein fremdes Werkzeug, dem man den Ton durch eine Pipe schiebt. Das funktionierte ungefähr. Geräte wurden mal gefunden und mal nicht, ein Teil des Handschlags fehlte, und mehrere Lautsprecher liefen nicht synchron.

Die Lösung war, aufzuhören, es selbst machen zu wollen. Das Betriebssystem kann ein zusammengesetztes Ausgabegerät bauen, das mehrere Ziele gleichzeitig bedient. Man legt es an, setzt es als Standard und überlässt Apple den Handschlag, die Zeitsynchronisierung und die Verschlüsselung. Weniger eigener Code, deutlich weniger Ärger.

Ein Lautsprecher, der an Verschlüsselung scheitert

Eine verbreitete Lautsprechermarke kommt mit vielen verschlüsselten Datenströmen nicht zurecht und quittiert das mit einer nichtssagenden Fehlermeldung über einen unzulässigen Dateityp. Die Lösung ist ein kleiner Vermittler, der lokal läuft, den verschlüsselten Strom entgegennimmt und unverschlüsselt weiterreicht. Im eigenen Netz ist das vertretbar.

Eine Anzeige, die im falschen Teil rechnete

Die Spektrumanzeige lief zunächst im Browserteil der Anwendung, wo solche Berechnungen üblicherweise stattfinden. Auf dieser Plattform gibt es dort allerdings ein Verhalten, das die Anzeige einfrieren lässt. Die Rechnung ist deshalb in den Rust-Teil gewandert. Das ist mehr Aufwand und funktioniert.

Zahlen zum Projekt

• Rund 10.700 Zeilen Rust in fünfzehn Bausteinen
• Rund 12.900 Zeilen im Vordergrund, ohne Rahmenwerk
• Der Ripper allein ist der größte Baustein
• Bauziele für alle drei großen Betriebssysteme über einen automatischen Bauvorgang

Bewusst kein Vordergrund-Rahmenwerk. Bei einer Anwendung, die vier Jahre laufen soll, ist mir das Rahmenwerk von heute die Baustelle von übermorgen.

Was es nicht ist

Es ist kein Produkt. Der Quelltext liegt in einem nicht öffentlichen Verzeichnis, die Veröffentlichungen sind Entwürfe, und es gibt nichts zum Herunterladen.

Der Ripper ist außerdem klar auf ein Betriebssystem zugeschnitten. Er lässt sich auf den anderen übersetzen, tut dort aber nichts Sinnvolles, weil er auf plattformeigene Wege für den Zugriff auf das Laufwerk setzt. Das war eine bewusste Entscheidung gegen eine Zwischenschicht, die ich für einen einzigen Benutzer nicht pflegen wollte.

Und es braucht externe Werkzeuge für Umwandlung, sicheres Lesen und Lautheitsanpassung. Die Anwendung prüft beim Start, was vorhanden ist, und bietet an, den Rest nachzuinstallieren.

Was ich dabei gelernt habe

Zwei Dinge, die über dieses Projekt hinausgehen.

Selbst machen ist nicht immer die Lösung. Der Umweg für die Tonverteilung war eigener Code, der ungefähr funktionierte. Die bessere Lösung war, eine Betriebssystemfunktion zu nutzen, die es seit Jahren gibt. Weniger eigener Code ist fast immer weniger Ärger.

Ehrliche Zustände sind mehr wert als schöne. Beim Prüfen einer Kopie ist der Unterschied zwischen „nicht gefunden» und „gefunden und abweichend» entscheidend. Ein Programm, das beides als Haken anzeigt, ist bequemer und nutzlos.