Zurück zum Blog
19. Oktober 2026Sergei Solod13 Min. Lesezeit

Die besten Audio-Codecs und der Aufbau einer sicheren Pipeline für wahrnehmungsbasierte Kompression

Opus, AAC, MP3, FLAC und ALAC im Vergleich: Klangqualität, Kompatibilität und Kompressionseffizienz. Außerdem wird erklärt, wie man FFmpeg-Kodierungen prüft, ohne Metadaten zu verlieren oder Ergebnisse der Stapelverarbeitung zu beschädigen.

AudiokompressionOpusFFmpegWahrnehmungsbasierte AudioqualitätVerlustfreies Audio

Bei der Wahl des besten Audioformats geht es nicht darum, die kleinstmögliche Datei zu erzeugen. Eine sinnvolle Entscheidung berücksichtigt die wahrgenommene Klangqualität, die Wiedergabekompatibilität, die Kodierdauer, die Latenz, die Speicherkosten und alle Informationen, die bei der Konvertierung erhalten bleiben müssen. Ein Codec kann das hörbare Signal recht gut bewahren und gleichzeitig unbemerkt Coverbilder, mehrere Künstlerangaben, Loop-Marker, Cue-Punkte oder anwendungsspezifische Metadaten verwerfen. Eine technisch erfolgreiche Transkodierung ist deshalb nicht zwangsläufig eine korrekte Dateikonvertierung.

Für die effiziente Bereitstellung von Audio in allgemeinen Anwendungsfällen ist Opus mit variabler Bitrate ein guter Ausgangspunkt. AAC bleibt eine starke Option für breite Kompatibilität, MP3 ist für ältere Wiedergabegeräte weiterhin nützlich, und FLAC ist die sicherere Wahl, wenn die verlustfreie Erhaltung der Audiosamples wichtiger ist als die Dateigröße. Das sind Ausgangspunkte, keine allgemeingültigen Sieger. Die schwierigere technische Frage lautet, wie ein automatischer Kompressor entscheiden soll, wann er überhaupt nichts neu kodieren darf.

Welchen Audio-Codec sollte man wählen?

FormatKompressionWichtigster EinsatzbereichWesentliche Einschränkung
OpusVerlustbehaftetEffiziente Kodierung von Sprache und Musik, Streaming und Audio mit geringer LatenzUnterstützung durch Container und Zielgeräte prüfen; erneute Kodierung kann Metadaten verlieren
AAC-LCVerlustbehaftetBreite Gerätekompatibilität und Unterstützung für MP4Effizienz hängt von Encoder und Bitrate ab; Varianten für niedrige Bitraten gesondert bewerten
MP3VerlustbehaftetÄltere Abspielgeräte, einfache Downloads und bewährte KompatibilitätBei vergleichbarer wahrgenommener Qualität meist weniger effizient als moderne Codecs
FLACVerlustfreiArchivierung, Übergabe für das Mastering und Erhaltung von PCM-SamplesDateien bleiben deutlich größer als bei wahrnehmungsbasierter Kodierung; Metadaten erfordern weiterhin Sorgfalt
ALACVerlustfreiVerlustfreies Audio in Arbeitsabläufen rund um AppleDer MP4-Container kann Strukturen enthalten, die sich nicht sauber in andere Formate übertragen lassen
WAV / PCMÜblicherweise unkomprimiertes PCMBearbeitung, Datenaustausch, Testsignale und direkter Zugriff auf SamplesGroße Dateien; WAV kann wichtige RIFF-Chunks ohne Audiodaten enthalten

Für eine moderne Webanwendung, die mehrere Audioquellen anbieten kann, ist Opus als primäres Format sinnvoll; AAC ist eine geeignete Alternative, wenn die Kompatibilität es verlangt. Wenn ein Archiv vor allem die reversible Erhaltung der Samples gewährleisten muss, sollte das Original aufbewahrt und FLAC gegebenenfalls als zusätzliche verlustfreie Repräsentation verwendet werden. Liegt eine Datei bereits als MP3, AAC oder Opus vor, ist es häufig besser, sie unverändert zu lassen, statt sie erneut verlustbehaftet zu kodieren. Jede weitere verlustbehaftete Kodierung kann neue Verzerrungen verursachen; ein anderer Codec stellt bereits entfernte Informationen nicht wieder her.

Die Unterscheidung zwischen Codec, Encoder und Container ist wichtig. Opus ist ein Codec, libopus eine weitverbreitete Encoder-Implementierung; Ogg, WebM und unterstützte MP4-Konfigurationen kommen als Container infrage. AAC wird häufig in MP4/M4A gespeichert. Die Dateiendung .m4a verrät nicht, ob die Audiodaten als AAC oder verlustfreies ALAC vorliegen. Statt Qualität oder Kodierung aus dem Dateinamen abzuleiten, sollte man die tatsächlichen Streams untersuchen. Der MDN-Leitfaden zu Audio-Codecs erläutert die Unterscheidung zwischen Format und Container; RFC 6716 definiert Opus.

Warum die Bitrate allein nichts über die Audioqualität beweist

Die Bitrate misst, wie viele kodierte Daten pro Sekunde anfallen, nicht, wie viel hörbare Information erhalten bleibt. Zwei Encoder können bei derselben Bitrate unterschiedliche Artefakte erzeugen. Eine leise Sprachaufnahme stellt andere Anforderungen an die Kompression als dichte Musik mit ausgeprägten Transienten. Der Vergleich von Dateigrößen kann irreführend sein, wenn Inhalt, Codec, Kanalkonfiguration und Encoder-Einstellungen nicht berücksichtigt werden.

  • Variable Bitrate (VBR) ermöglicht es dem Encoder, komplexen Passagen mehr Bits und einfacheren weniger Bits zuzuweisen. Sie ist einer starren konstanten Bitrate meist vorzuziehen, sofern ein vorhersehbarer Netzwerkdurchsatz nicht die wichtigste Vorgabe ist.
  • Die Abtastrate bestimmt, wie häufig die dekodierte Wellenform abgetastet wird. Durch Hochskalieren einer Quelle mit niedriger Abtastrate kehren fehlende Hochfrequenzinformationen nicht zurück. Unterschiedliches Resampling von Referenz und Kandidat kann zudem Qualitätsvergleiche erschweren.
  • Die Bittiefe beschreibt die Quantisierungsgenauigkeit von PCM, nicht die Klangtreue eines verlustbehafteten Codecs. Das Dekodieren einer bereits beeinträchtigten Quelle mit hoher Bittiefe stellt verlorene Details nicht wieder her.
  • Die Kanalanordnung gehört zum Signal. Eine Abmischung auf Mono kann die Dateigröße senken, ist aber keine zulässige automatische Optimierung, wenn die Stereobühne des Materials wichtig ist.
  • Latenz, Encoder-Verzögerung und Padding sind für interaktive Wiedergabe, lückenlose Übergänge und präzise gelooptes Audio relevant. Die Dauer allein macht nicht jedes Synchronisationsproblem sichtbar.

Als Ausgangspunkt für Versuche eignen sich bei Stereomusik mit Opus ungefähr 128–192 kbit/s und bei Monosprache deutlich niedrigere Bitraten, jeweils angepasst an das Material und die Wiedergabeanforderungen. Diese Werte sind Suchparameter und keine Grenzwerte, die unhörbare Unterschiede garantieren. Beim Streaming mit niedriger Bitrate lohnt sich die Prüfung von Technologien wie xHE-AAC, sofern die jeweilige Einsatzumgebung sie unterstützt. Neue neuronale Audio-Codecs können für spezielle Sprach- oder Forschungssysteme interessant sein. Eine Veröffentlichung oder Demonstration belegt jedoch nicht, dass sich ein solcher Codec ohne Weiteres anstelle eines breit unterstützten Auslieferungsformats einsetzen lässt.

Mit FFprobe die Quelle untersuchen und mit FFmpeg Kandidaten kodieren

Zuerst sollten der tatsächliche Audiostream, die Abtastrate, die Kanäle und die Dauer ermittelt werden. So vermeidet man die Annahme, jeder MP4-ähnliche Container enthalte Audio oder jede bekannte Dateiendung sei dekodierbar.

ffprobe -v error -select_streams a -show_entries stream=codec_name,sample_rate,channels,channel_layout:format=duration -of json input.m4a

Für eine unkomplizierte WAV-Quelle, die mit entsprechender Berechtigung verarbeitet werden darf und deren zusätzliche Chunks nachweislich entbehrlich sind, sieht ein beispielhafter hochwertiger Opus-Encode so aus:

ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a libopus -b:a 160k -vbr on -compression_level 10 -application audio output.opus

Für die Bereitstellung mit breiter MP4-Kompatibilität lässt sich mit dem nativen AAC-Encoder von FFmpeg ein AAC-LC-Kandidat erzeugen:

ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a aac -b:a 192k output.m4a

Für eine verlustfreie Audio-Repräsentation:

ffmpeg -hide_banner -nostdin -i input.wav -map 0:a:0 -vn -c:a flac -compression_level 8 output.flac

Das sind Beispiele für einzelne Dateien, keine sichere Pipeline zur Stapelkonvertierung. Sie belegen nicht, dass jedes Metadatenfeld, jeder zusätzliche Stream, jeder Cue-Punkt oder jeder Container-Chunk erhalten bleibt. Beim verlustfreien Befehl muss die Gleichheit der dekodierten PCM-Daten in einer einheitlichen Sample-Darstellung geprüft werden, bevor von einer reversiblen Audiokonvertierung gesprochen werden kann. Die Kodierung mit libopus samt VBR- und Komplexitätseinstellungen ist in der FFmpeg-Dokumentation zu Codecs beschrieben. Im Browser sollte die Wiedergabe mit dem tatsächlichen Codec-Container-Paar getestet werden, nicht nur anhand der Dateiendung.

So findet man die kleinste akzeptable Datei

Ein wahrnehmungsbasierter Optimierer löst im Kern ein Suchproblem mit Nebenbedingungen: Die Ausgabedatei soll möglichst klein sein und zugleich technische Prüfungen, eine Mindestanforderung an die Qualität und ausdrückliche Erhaltungsvorgaben erfüllen. Der Suchraum umfasst Codec-Einstellungen, Bitrate, Kanalbehandlung und Encoder-Komplexität. Kleiner ist nicht automatisch besser; ein Kandidat mit niedriger Bitrate darf nicht allein deshalb akzeptiert werden, weil der Encoder erfolgreich beendet wurde.

  1. Einen SHA-256-Fingerabdruck der Quelle erfassen und ihre Streams sowie die Containerstruktur untersuchen.
  2. Festlegen, ob verlustbehaftete Kodierung zulässig ist. Bereits verlustbehaftet kodierte Eingaben und Dateien mit nicht unterstützten Metadaten standardmäßig unverändert lassen.
  3. Zuerst einen konservativ eingestellten Opus-Kandidaten kodieren und anschließend gezielt niedrigere Bitraten ausprobieren, statt blind alle möglichen Einstellungen zu durchlaufen.
  4. Jeden Kandidaten dekodieren und prüfen, ob Audio vorhanden ist, die erwarteten Kanäle bestehen bleiben, die zeitliche Zuordnung plausibel ist und das Dekodieren fehlerfrei endet.
  5. Referenz und Kandidat anhand passend ausgerichteter Ausschnitte mit einer wahrnehmungsbasierten Metrik vergleichen. Zusätzlich unabhängig auf Stereointegrität, Aussetzer, Clipping und andere mögliche, von der Metrik übersehene Fehler prüfen.
  6. Den kleinsten Kandidaten wählen, der die Vorgaben erfüllt und eine nennenswerte Einsparung bringt. Andernfalls das Original Byte für Byte erhalten.
  7. Sicherstellen, dass die Quelle während der Verarbeitung nicht verändert wurde; erst nach Validierung des gesamten vorbereiteten Ergebnisses veröffentlichen.

Ein nützlicher Optimierer erfasst COMPRESSED, PRESERVED und FAILED als unterschiedliche Ergebnisse. Eine Datei unverändert zu lassen, kann die richtige Optimierungsentscheidung sein und ist kein Fehler. Eine konfigurierbare Mindesteinsparung verhindert, dass für eine kaum merkliche Größenreduzierung Qualität und Rechenzeit geopfert werden.

Was ViSQOL messen kann – und was nicht

ViSQOL ist ein wahrnehmungsbasiertes Qualitätsmaß mit vollständigem Referenzsignal. Es vergleicht eine Referenzwellenform mit einer beeinträchtigten Wellenform und liefert einen geschätzten MOS-LQO-Wert. Damit lassen sich Kodierkandidaten sinnvoll ordnen. Das Ergebnis ist jedoch eine Modellvorhersage, weder ein menschlicher Hörtest noch ein Beweis für unhörbare Unterschiede.

Betriebsmodus und Vorverarbeitung sind entscheidend. Der Audiomodus von ViSQOL erwartet Eingangsdaten mit 48 kHz und mischt mehrkanaliges Audio für den Vergleich auf Mono herunter. Der Sprachmodus verwendet ein anderes Modell und erwartet 16 kHz. Die höchsten Vorhersagewerte des Audiomodells liegen bei ungefähr 4,75 und entsprechen nicht einer universell perfekten 5. Deshalb ist es nicht gerechtfertigt, einen einzelnen Wert wie 4,45 als wissenschaftlich nachgewiesenen Grenzwert für jede Aufnahme anzusehen. Grenzwerte müssen anhand der Inhalte und Höranforderungen kalibriert werden.

Mittelwerte können lokale Schäden verdecken. Ein Kandidat mag über weite Teile eines Titels akzeptabel klingen, aber einen einzelnen Beckenschlag, einen scharfen Konsonanten oder einen kurzen Transienten verzerren. Eine sorgfältigere Strategie prüft schwierige Passagen und kann zusätzlich überlappende Zeitfenster über die gesamte Datei auswerten. Dabei wird der schlechteste relevante Wert berücksichtigt, statt sich nur auf den Durchschnitt zu verlassen. Eine vollständige Abdeckung verursacht zusätzlichen Aufwand für das Dekodieren und die Berechnung der Metrik. Referenzfenster sollten mit einem begrenzten Speicherplatzbudget zwischengespeichert werden, damit lange Aufnahmen den temporären Speicher nicht erschöpfen.

Auch eine vollständige Prüfung löst nicht alle Probleme: Ein auf Mono basierender Wert beweist weder die Erhaltung der Stereobreite noch die korrekten Phasenbeziehungen. Eine fehlerhafte zeitliche Ausrichtung kann den Vergleich verfälschen; manche Artefaktarten werden von einem bestimmten Modell nur unzureichend erfasst. Deshalb sind gesonderte Signalprüfungen und kontrollierte Hör- oder ABX-Tests mit repräsentativem Material nötig, bevor ein Grenzwert als produktive Abnahmeregel übernommen wird. Bei den vorliegenden Implementierungsarbeiten testeten automatisierte Integrationstests die ViSQOL-Schnittstelle mit einem Testersatz. Sie belegten weder die tatsächliche Genauigkeit von ViSQOL noch die Unhörbarkeit von Unterschieden auf einem macOS-Zielsystem.

Warum korrekte Audiodaten noch keine korrekte Ausgabedatei ergeben

Das wichtigste während der Entwicklung erkannte Fehlermuster war der Verlust von Containerdaten, der sich als erfolgreiche Kompression tarnt. Audiodecoder stellen häufig einen abspielbaren Stream bereit und ignorieren andere Strukturen. Wer nur diesen Stream transkodiert, kann eine gültige Ausgabedatei erzeugen, in der Informationen unbemerkt fehlen, die der ursprüngliche Eigentümer erhalten wollte.

WAV und AIFF enthalten mehr als nur Samples

RIFF/WAV-Dateien können Cue-Punkte, Loop-Metadaten, Broadcast-Metadaten, zusätzliche Formatfelder und unbekannte Chunks enthalten. AIFF verfügt über eigene Strukturen für Marker und Instrumente. Eine Datei kann sich einwandfrei dekodieren lassen und dennoch Nicht-Audiodaten enthalten, die bei einer gewöhnlichen Opus-Kodierung verloren gehen. Eine vorsichtige Verarbeitung muss als sicher bekannte Strukturen prüfen und das vollständige Original bewahren, wenn sich ein Chunk nicht zuverlässig einordnen lässt. Selbst ein Block, der üblicherweise zum Auffüllen dient, kann Bytes ungleich null enthalten. Bei einer Vorgabe zur bytegenauen Erhaltung ist es unsicher, solche Blöcke pauschal als entbehrlich anzusehen.

FLAC kann strukturierte Informationen bewahren, die bei der Konvertierung zu Opus verloren gehen

FLAC unterstützt Metadatenblöcke für Bilder, Cuesheets, Anwendungsdaten, Seek-Tabellen und Vorbis-Kommentare. In diesen Kommentaren dürfen Schlüssel mehrfach vorkommen. Ein kontrollierter Test mit getrennten Einträgen ARTIST=Alice und ARTIST=Bob zeigte, warum eine scheinbar erfolgreiche Konvertierung semantisch falsch sein kann, wenn das Ergebnis nur ARTIST=Alice;Bob enthält. Diese Darstellungen sind nicht zwingend gleichwertig. Ein vorsichtiger Konverter sollte wiederholte Schlüssel und nicht unterstützte Kommentarkodierungen erkennen und dann das Original erhalten, statt die Struktur unbemerkt abzuflachen. Die FLAC-Formatübersicht erklärt das Modell der Metadatenblöcke.

MP4/M4A erfordert Strukturprüfungen statt bloßer Prüfung von Tag-Namen

Eine M4A-Datei kann gewöhnliche Künstler- und Titel-Tags sowie private oder unbekannte Atome enthalten. Unbekannte Atome können auf verschiedenen Ebenen vorkommen, auch innerhalb ansonsten vertrauter Metadatenboxen. Es genügt nicht, nur den Namen eines äußeren Atoms zu prüfen: Ein nicht erkanntes untergeordnetes Element oder eine unerwartete Datendarstellung kann verloren gehen, obwohl sich der ALAC- oder AAC-Stream einwandfrei dekodieren lässt. Sicherer ist es, eine bewusst eng begrenzte Menge nachweislich unbedenklicher Atomstrukturen zu erkennen und mehrdeutige Eingaben ohne Transkodierung zu bewahren.

Ebenso kann eine Datei mit bekannter Endung ausschließlich Untertitel oder Video oder mehrere Streams enthalten. Sie sollte weder zwangsweise einem Audio-Encoder übergeben noch als fehlgeschlagener Audioauftrag verworfen werden. Sie ist als zusätzliche Datei aufzubewahren, sofern die Containerprüfung und die Integritätsprüfung der Quelle erfolgreich sind. Aus der Dateiendung allein darf nicht auf einen Audiostream geschlossen werden.

Einen Stapeloptimierer als Transaktion bauen – nicht als Schleife zum Überschreiben von Dateien

Die zweite wichtige technische Lehre betrifft die Veröffentlichung der Ergebnisse. Ein Optimierer darf ein zuvor korrektes Ergebnis niemals zerstören, nur weil eine spätere Datei fehlschlägt, ein Prozess unterbrochen wird oder ein Kandidat kleiner erscheint. Sicherer ist es, das endgültige Verzeichnis als verwaltetes Artefakt mit nachvollziehbarer Herkunft und einem wiederherstellbaren Commit-Verfahren zu behandeln.

  1. Vorprüfung: FFmpeg, FFprobe, benötigte Encoder und optionale Werkzeuge zur Qualitätsbewertung prüfen. Eingabe- und Ausgabepfade vor jeder Erstellung auflösen; Pfadverschachtelungen über symbolische Links zurückweisen.
  2. Bestandsaufnahme: Dateien und Verzeichnisse erfassen, nicht unterstützte Dateisystemobjekte zurückweisen und Namenskollisionen bei Regeln ohne Groß-/Kleinschreibungsunterscheidung oder mit Unicode-Normalisierung erkennen. Beachten, dass die maximale Länge eines Dateinamens häufig in Bytes und nicht in Zeichen gemessen wird.
  3. Vorbereitung: Kandidaten in einem eigenen temporären Arbeitsverzeichnis auf demselben Dateisystem wie das spätere Ziel anlegen. Originaldateien unverändert lassen.
  4. Prüfung: Fingerabdrücke von Quelle und Ausgabe bilden, den gesamten Ordner validieren und die vorgesehenen Inhalte mit dem vorbereiteten Manifest vergleichen. Den Pfad für unverändert übernommene Dateien nicht übergehen, nur weil keine Kodierung stattfand.
  5. Commit: Mit Sperre, Transaktionsjournal, kontrollierten Umbenennungen und geprüftem Backup einen vollständigen Ordner veröffentlichen. Mehrere Umbenennungen bilden keine einzelne atomare Transaktion; die Wiederherstellungslogik muss Zwischenzustände verstehen.
  6. Wiederherstellung: Nur Ausgaben wiederherstellen, deren Zugehörigkeit und Hashes sich überprüfen lassen. Unbekannte oder verdächtige Reste unter Quarantäne stellen, statt sie automatisch zu löschen.

Manifestdateien gehören selbst zur Angriffs- und Fehleroberfläche. Ihre Größe muss begrenzt sein; sie müssen defensiv geparst und als reguläre Dateien geöffnet werden, ohne symbolischen Links zu folgen oder an benannten Pipes unbegrenzt zu blockieren. Auch Map-Schlüssel und wiederhergestellte Pfade müssen validiert werden: Ein harmlos aussehender JSON-Wert darf eine Wiederherstellungsoperation niemals aus dem vorgesehenen Ausgabeverzeichnis herausführen. Spezielle JavaScript-Eigenschaftsnamen dürfen nicht in ungeschützten Dictionaries mit Prototypenkette gespeichert werden.

Außerdem können sich Quelldateien während einer längeren Kodierung ändern. Ein Hash nur bei der ersten Erfassung genügt nicht. Derselbe anfängliche Fingerabdruck muss erneut geprüft werden, wenn eine unveränderte Quelle kopiert wird, wenn ein wahrnehmungsbasierter Kandidat verworfen wird und unmittelbar vor der Veröffentlichung. Ein kontrollierter Test mit künstlich ausgelöstem Fehler zeigte den Grund: Wurde eine Eingabedatei nach ihrer Prüfung ersetzt, konnte eine frühere Implementierung eine erfolgreich erhaltene Datei melden, obwohl die veröffentlichten Bytes aus einem anderen Zustand der Quelle stammten. Die korrigierte Regel weist diesen Durchlauf zurück, statt ein irreführendes Ergebnis zu veröffentlichen.

Bei der Validierung Fehlerpfade ebenso gründlich testen wie Codecs

Codec-Tests sollten gewöhnliches WAV und FLAC, Mono und Stereo sowie Material mit deutlich ausgeprägten Transienten umfassen. Strukturtests sollten doppelte FLAC-Kommentare, verschachtelte MP4-Metadaten, zusätzliche WAV/AIFF-Chunks, Dateien ohne Audiostream, lange Namen, Kollisionen bei Ausgabedateinamen und während der Verarbeitung veränderte Dateien abdecken. Wiederherstellungstests sollten eine Unterbrechung zwischen aufeinanderfolgenden Umbenennungen erzwingen und bestätigen, dass ein zuvor gültiges Ergebnis erhalten bleibt oder wiederhergestellt wird.

Erfolgreiche Tests sind nicht mit einem Nachweis der Hörqualität gleichzusetzen. Die hier beschriebenen Entwicklungsarbeiten umfassten echte Kodier- und Dekodierprüfungen mit FFmpeg sowie absichtlich fehlerhafte oder ungewöhnliche Testdateien und Integrationstests mit simulierten Antworten der Wahrnehmungsmetrik. Diese Prüfungen belegen bestimmte Sicherheitseigenschaften, nicht aber einen statistisch repräsentativen Codec-Vergleich, eine vollständige Abdeckung aller Container oder die Validierung auf jedem Betriebssystem. Dieselbe Unterscheidung sollte sich in den Berichten eines Audio-Optimierers wiederfinden: Eine dekodierte Datei, eine anhand einer Wahrnehmungsmetrik geprüfte Datei und eine von Menschen gehörte und geprüfte Datei stehen für drei unterschiedliche Vertrauensstufen.

Eine praktische Entscheidungsregel für produktiv eingesetztes Audio

Für neue, entbehrliche Auslieferungskopien aus vertrauenswürdigen verlustfreien Mastern sollte man zunächst hochwertiges Opus mit VBR verwenden und das Ergebnis unter realistischen Hörbedingungen prüfen. AAC kann angeboten werden, wo die Auslieferungsumgebung es erfordert. MP3 sollte erhalten bleiben, wenn die Kompatibilität dafür spricht. Originale, Bearbeitungsdateien und Dateien mit unersetzlichen Nicht-Audiodaten sollte man unverändert bewahren und FLAC nur dann einsetzen, wenn sich eine verlustfreie Konvertierung anhand der Erhaltungsvorgaben verifizieren lässt. Eine Transkodierung von einem verlustbehafteten Format in ein anderes sollte standardmäßig vermieden werden.

Der zuverlässigste Optimierer ist daher nicht derjenige, der jede Datei komprimiert. Es ist derjenige, der für jede Eingabe erklären kann, warum er einen Codec gewählt hat, warum die Ausgabe die geltenden Qualitäts- und Integritätsprüfungen bestanden hat und warum der Verzicht auf erneute Kompression manchmal die einzig richtige Entscheidung war.