Zusammenfassung

  • RFC 9639 standardisiert FLAC als verlustfreie Rekonstruktion der ganzzahligen PCM-Samples, die dem Encoder übergeben wurden.
  • Schon 49 codierte Byte können mehr als 2 MiB PCM ergeben; korrekt decodierbar und unter untrusted input sicher verarbeitbar sind verschiedene Aussagen.
  • Ein belastbarer Beleg verbindet Verwahrung, Encoder-Eingang, Stream und Container, Prüfungen, PCM-Vergleich, Kanäle, Metadaten, Implementierungen, Ressourcen und Ergebnis.

Der Eingang war 49 Byte groß. Der mögliche PCM-Ausgang lag über zwei Mebibyte. Ein Parser, der nur auf die kleine Datei sah, plante für das falsche Objekt.

RFC 9639 nennt dieses Verhältnis ausdrücklich in seinen Sicherheitsüberlegungen. FLAC kann Samples exakt rekonstruieren; genau deshalb muss Software aus komprimierter Struktur große Ausgaben erzeugen. Verlustlosigkeit beseitigt keine Ressourcenobergrenze. Sie sagt auch nichts über die Herkunft der Samples oder die Wahrheit ihrer Beschriftung.

Exakt bezogen auf welchen Eingang?

FLAC codiert ganzzahliges PCM. Stimmen decodierte Samples mit dem Encoder-Eingang überein, ist eine starke Gleichheitsaussage erfüllt. War der Eingang bereits resampelt, abgeschnitten, kanalvertauscht oder die falsche Aufnahme, wird auch dieser Zustand exakt konserviert.

Der Beleg muss deshalb Sample-Rate, Bittiefe, Kanalzahl und -reihenfolge, Sample-Gesamtzahl und einen externen Eingangs-Fingerprint nennen. Hinzu kommen Encoder-Version und Parameter, Decoder-Version und Vergleichsverfahren. „Verlustlos“ ohne Referenzobjekt ist keine reproduzierbare Feststellung.

Prüfflächen bleiben getrennt

Jeder Frame besitzt CRC-8 im Header und CRC-16 am Ende. STREAMINFO kann einen MD5-Wert über die uncodierten Audiodaten tragen. Ein externer Hash kann dagegen sämtliche Datei- oder Containerbytes identifizieren.

Ein gültiger Frame beweist keine vollständige Folge. Ein passender Audio-MD5 deckt Containerindex, Bild und Kommentar nicht ab. Ein Dateihash bestätigt nicht den genannten Künstler. STREAMINFO erlaubt zudem unbekannte Werte: Null bei Framegrößen oder Samplezahl sowie einen vollständig nullgesetzten MD5.

RFC 6151 grenzt MD5 weiter ein. Für kollisionsresistente Authentisierung ist es ungeeignet; als eingebettete Fehlererkennung gehört es zu einem anderen Bedrohungsmodell. Herkunft erfordert eine vertrauenswürdige externe Identität und gegebenenfalls eine Signatur mit klar benanntem Objekt.

Metadaten sind Aussagen, keine Zeugen

Vorbis-Kommentare und Bilder können Titel, Künstler, Datum und Lizenz tragen. Das Format bewahrt diese Behauptungen, überprüft sie aber nicht. Jede relevante Angabe braucht Quelle, Prüftermin und Konfliktstatus.

Auch Kanäle zeigen diese Grenze. FLAC definiert Standardreihenfolgen. Eine WAVEFORMATEXTENSIBLE-Kanalmaske kann eine andere Lautsprecherbelegung beschreiben, ordnet Samples aber nicht selbst um. Sender und Empfänger müssen dieselbe Zuordnung anwenden; die Abhängigkeit vom Kommentar verlässt zudem das streamable subset.

Identische Samples an anderen Ausgängen ergeben eine andere Wiedergabe. Ein Mehrkanalbeleg verbindet deshalb Produktionsunterlagen oder Testsignale mit dem tatsächlich beobachteten Routing.

Containerwerte dürfen widersprechen

Native FLAC-Daten können in Ogg liegen oder mit Matroska- und MP4-Strukturen zusammentreffen. Container wiederholen Zeit, Dauer, Rate oder Kanalangaben. Wenn sie vom eingebetteten Stream abweichen, ist der Konflikt selbst Evidenz.

Ein System sollte beide Lesarten, Parser und Prioritätsregel erhalten und das Verhalten benannter Anwendungen prüfen. Der PCM-MD5 entscheidet keine Containerzeit; eine gültige Sample-Tabelle beweist keine PCM-Gleichheit.

Das streamable subset erhöht die praktische Kompatibilität, zertifiziert aber keinen beliebigen Decoder. RFC 9639 weist darauf hin, dass frühe oder minderwertige Implementierungen nur häufige Funktionen unterstützen können. Interoperabilität braucht eine Matrix aus Produkt, Version, Merkmal, Output-Fingerprint, Fehlerpfad und Ressourcenlimit.

Sicherheitsbeleg neben Verlustlosbeleg

Große Metadatenmengen, arithmetische Grenzfälle und starke Dekompression verlangen Limits für Bytes, Felder, Zeichen, Samples, Speicher und Laufzeit. Annahme beweist nicht Sicherheit; Ablehnung kann eine lokale Schutzrichtlinie statt Formatwidrigkeit ausdrücken.

Die Kette beginnt bei exakt empfangenem Objekt, Verwahrung und extern verankertem Fingerprint. Sie dokumentiert PCM vor dem Encoder, Vorverarbeitung, Build und Parameter. Stream und Container erhalten getrennte Identitäten. Nullwerte in STREAMINFO bleiben sichtbar; Frame-CRC, Audio-MD5 und PCM-Vergleich werden separat ausgewiesen.

Danach werden Rate, Tiefe, Dauer, Kanalordnung, Containerzeit und Metadatenherkunft abgeglichen, ohne Unterschiede zu löschen. Benannte Decoder laufen in erklärten Ressourcenbudgets. Wird erfolgreiche Wiedergabe versprochen, muss deren Beobachtung hinzukommen.

So behält jede Schicht ihre Autorität: Verwahrung identifiziert, der Encoder transformiert, der Stream transportiert, Checks erkennen begrenzte Änderungen, der Decoder rekonstruiert, Metadaten beschreiben, der Container terminiert und die Wiedergabekette wirkt.

Quellen