M4A in FLAC umwandeln

M4A ist ein Container, kein Codec, und darin steckt entweder AAC — verlustbehaftet — oder ALAC, Apple Lossless, was es nicht ist. Endung und Symbol sind bei beiden identisch, und der gesamte Wert dieser Umwandlung hängt genau an diesem Unterschied. Wer eine Musiksammlung umwandeln will, sollte dafür zwei Minuten aufwenden und die Frage danach nie wieder stellen.

Die Dateigröße verrät es schneller als jedes Programm. Ein vier Minuten langer AAC-Titel wiegt vier bis acht Megabyte, dieselben vier Minuten als ALAC zwanzig bis dreißig. Auf dem Mac nennt Befehl-I in den Informationen den Codec direkt; wer aus einer alten iTunes-Bibliothek eine „Musik"-App-Sammlung geerbt hat, sieht mit einer eingeblendeten Art-Spalte sofort, ob dort „Apple Lossless" oder „AAC" steht. Sammlungen sind fast immer einheitlich, fünf Dateien als Stichprobe reichen für die ganze Bibliothek.

FLAC ist verlustfrei in einem genauen und begrenzten Sinn: Es rekonstruiert Bit für Bit, was ihm übergeben wurde. Es hat keine Meinung dazu, ob das Übergebene überhaupt etwas taugte. Bekommt es Audio, das AAC bereits ausgedünnt hat, bewahrt es dieses ausgedünnte Audio perfekt, für immer, in einer drei- bis fünfmal so großen Datei.

Der Impuls dahinter ist nachvollziehbar — man will eine verlustfreie Bibliothek, also soll alles verlustfrei sein. Ein FLAC aus einem 256-kbps-AAC ist aber eine verlustbehaftete Aufnahme mit einem verlustfreien Etikett, und schlechter als das M4A auf zwei Arten: größer, und es sieht jetzt für jeden, der die Bibliothek durchsucht, wie ein Master aus. Das AAC als AAC zu belassen ist die ehrliche und die kleinere Option.

ALAC und FLAC lösen dasselbe Problem mit vergleichbarer Effizienz: Beide rekonstruieren die ursprünglichen Samples exakt und landen etwa bei der halben Größe einer entsprechenden WAV-Datei. Die Umwandlung zwischen beiden verliert nichts — nicht ein bisschen, gar nichts —, weil jeder der beiden Schritte exakt ist.

Was sich ändert, ist, wer die Datei lesen kann. FLAC wurde 2001 von Josh Coalson veröffentlicht, 2003 von Xiph.Org übernommen und als RFC 9639 standardisiert, und genau das erwarten Plex, Jellyfin, Navidrome, foobar2000, Roon, die meisten Netzwerk-Streamer und praktisch jedes Linux-Werkzeug. ALAC wird innerhalb der Apple-Welt gut gelesen, außerhalb davon unregelmäßig. Wer eine Sammlung von iTunes auf einen NAS oder Medienserver zieht — in vielen deutschen Haushalten eine FritzBox-, Synology- oder QNAP-Konfiguration —, trifft mit dieser Umwandlung die richtige Entscheidung, ohne Nachteil.

Wer eigene CDs digitalisiert hat — das Recht dazu deckt die private Kopie nach § 53 UrhG ab, solange keine Kopiersperre umgangen wurde —, hat sie oft mit iTunes oder der Musik-App als Apple Lossless gerippt, weil das lange die verlustfreie Voreinstellung im Apple-Ökosystem war. Genau diese Rip-Sammlungen sind der häufigste Fall echter ALAC-M4A-Dateien, und genau für sie ist diese Umwandlung gedacht.

Wer stattdessen aus Bequemlichkeit auf die Standardeinstellung „AAC, 256 kbps" gestoßen ist, sitzt auf der anderen Sorte Datei und profitiert von einer Umwandlung nach FLAC nicht. Die zwei Minuten aus dem ersten Abschnitt entscheiden, in welcher der beiden Gruppen die eigene Sammlung liegt.

Wer eine Bibliothek konsolidiert, zieht oft WAV in Betracht, und FLAC gewinnt auf jeder Achse, die für die Speicherung zählt. Es ist bei identischem Audio ungefähr halb so groß. Es trägt eine Prüfsumme mit sich, sodass eine auf der Platte beschädigte oder beim Kopieren verfälschte Datei erkannt werden kann, statt still falsch abgespielt zu werden.

Es speichert Metadaten auch ordentlich: Vorbis-Kommentare tragen Titel, Interpret, Album, Albuminterpret, Track- und Disc-Nummer, Genre, Datum, Kommentar und Text, und PICTURE-Blöcke tragen das Cover. Der RIFF-INFO-Block von WAV kennt sieben Felder in Latin-1 und kein Cover. Für eine Bibliothek, die in fünf Jahren noch durchsuchbar sein soll, ist das kein kosmetischer Unterschied.

Tausend vierminütige Titel als AAC-M4A bei der 256-kbps-Rate, die iTunes lange verwendet hat, ergeben ungefähr acht Gigabyte. In FLAC umgewandelt — ohne jede Verbesserung — werden daraus fünfundzwanzig bis dreißig, weil FLAC bereits dekodiertes verlustbehaftetes Audio nicht so dicht komprimieren kann wie eine echte Aufnahme; die Vorhersagemodelle des Encoders arbeiten schlechter an Material, das ein psychoakustisches Modell schon zurechtgeschnitten hat.

Dieselben tausend Titel als ALAC wären ebenfalls fünfundzwanzig bis dreißig Gigabyte, und als FLAC bleiben sie ungefähr dort. Das ist die ehrliche Gegenüberstellung vor dem Start: eine Migration, die den Speicherplatz etwa gleich lässt und die Kompatibilität verbessert, gegen eine, die ihn verdreifacht und nichts verbessert.

Die Dekodierung hier nutzt die Codecs des eigenen Geräts über WebCodecs, und ALAC gehört nicht zu den auf diesem Weg verfügbaren Codecs. Eine Apple-Lossless-M4A-Datei, die hier abgelegt wird, ergibt deshalb kein fehlerhaftes FLAC — die Umwandlung stoppt mit einer Meldung, dass nichts in der Datei umwandelbar war.

Das steht besser hier als dass man es selbst herausfindet. Für eine ALAC-Bibliothek ist ein Desktop-Werkzeug mit eigenem Decoder das richtige Mittel: FFmpeg, dBpoweramp unter Windows, XLD auf dem Mac. Die Umwandlung ist in allen dreien verlustfrei. Was diese Seite für den Besitzer einer ALAC-Sammlung leisten kann, ist zu bestätigen, dass die Migration richtig ist, und zu sagen, welches Werkzeug dafür läuft.

Eine schmale Ausnahme von allem oben Gesagten lohnt sich, weil sie die einzige ist. Wer eine Aufnahme wiederholt bearbeitet — schneiden, normalisieren, Effekte anwenden, exportieren, wieder öffnen, wieder exportieren —, bei dem summiert sich der Schaden bei jedem verlustbehafteten Zwischenspeichern, während ein FLAC-Zwischenstand das nicht tut.

Eine verlustbehaftete Quelle für die Dauer der Bearbeitung als FLAC zu führen und erst am Ende einmal in das gewünschte Zielformat zu exportieren, vermeidet Generationsverlust, obwohl der Ausgangspunkt schon komprimiert war. Das ist eine Entscheidung für die Bearbeitung mit einem definierten Ende, keine für ein Archiv — ist die Arbeit fertig, hat das FLAC-Zwischenstück seinen Zweck erfüllt und kann weg.

Der Vorbis-Kommentar-Block von FLAC übernimmt die gängigen Felder direkt, sodass eine umgewandelte Datei auf einem Medienserver mit Titel, Interpret, Album, Albuminterpret, Track- und Disc-Nummer, Genre, Datum, Kommentar und Text ankommt, dazu das Cover als PICTURE-Block, das Plex und Jellyfin anzeigen.

Was nicht übertragen wird, ist die Apple-spezifische Ebene: Kaufbelege, Store-Kennungen, eigene Atome und jedes iTunes-Feld ohne Vorbis-Entsprechung. Das wird verworfen statt als Datenmüll geschrieben, was die richtige Wahl ist — hängt die eigene Sammlung aber an einem selbst in iTunes hinzugefügten Feld, lohnt es sich, ein Album umzuwandeln und im Medienserver zu prüfen, bevor neunhundert folgen.

Bis zu 100 Dateien auf einmal ablegen; jede wird für sich umgewandelt, und alle kommen als ZIP zurück, mit einer Grenze von 100 MB je Datei, weil die Arbeit auf dem eigenen Prozessor läuft statt auf einem fremden Server. Diese hundert sind der ganze Stapel, keine Empfehlung — eine Datei darüber hinaus wird aufgelistet und liegen gelassen — und die Zahl ist ohnehin passend, weil FLAC-Kodierung echte Rechenarbeit ist und ein Tab bei hundert Titeln ein paar Minuten beschäftigt bleibt.

Der Datenschutz-Punkt hier ist nicht abstrakt. Eine Musikbibliothek ist ein ziemlich vollständiges Protokoll dessen, was jemand über fünfzehn Jahre gekauft, gehört und geschätzt hat, und sie einem Konverter zu übergeben heißt, genau dieses Protokoll weiterzureichen. Nichts auf dieser Seite verlässt den Tab; im Netzwerk-Tab der Entwicklerwerkzeuge zeigt sich während einer Umwandlung nur die Seite selbst und keine Anfrage, die Audiodaten trägt.

Viele Bibliotheken sind nicht einheitlich, auch wenn sie es sein sollten. Ein Teil kam aus eigenen CD-Rips, ein Teil aus dem iTunes Store, ein Teil aus einer Cloud-Synchronisation, die beim Hochladen unbemerkt in AAC umgewandelt hat. Vor einer Massenumwandlung lohnt es sich, nach Ordnern statt nach der gesamten Bibliothek auf einmal vorzugehen, weil sich Herkunft in der Praxis oft ordnerweise gruppiert.

Wer unsicher ist, wandelt zuerst einen einzelnen Ordner um, prüft die entstandene Dateigröße gegen das Original und zieht daraus den Schluss für den Rest. Das kostet zehn Minuten und verhindert, über Nacht eine ganze Bibliothek in eine Größe zu verwandeln, die dreimal so viel Platz braucht, ohne dass ein einziges Bit an Qualität dazugekommen ist.