Summary
- RFC 9639 standardises FLAC’s lossless relationship between an encoded stream and the integer PCM samples supplied to its encoder.
- Frame CRCs, the optional-in-practice STREAMINFO MD5, external file digests, trusted signatures and playback observations answer different questions and must not borrow one another’s authority.
- A defensible preservation receipt joins source custody, encoder input, bitstream and container identity, parsed metadata, decoded PCM comparison, channel semantics, implementation behaviour, resource limits and downstream outcome.
The archive accepted a FLAC file, decoded it and obtained an MD5 match. Its dashboard turned green: recording preserved.
Only the narrower statement was established. The decoder had produced audio samples matching the digest placed in the stream by an encoder. The receipt did not identify the microphone capture, prove that the ingest operator chose the correct take, authenticate the encoder, validate the artist and date fields, or show that the left and right channels reached the intended outputs. Exact samples had returned. The identity of the recording had not been independently proved.
That boundary is the most important operational lesson in RFC 9639. The Standards Track specification gives FLAC a precise IETF description: frames, subframes, prediction, residual coding, metadata, checks and a streamable subset. Its precision makes strong evidence possible. Precision also makes overclaiming easier, because the green result is tempting to stretch beyond the object it measured.
Lossless has an object
FLAC encodes integer PCM. In the codec’s claim, lossless means the decoder can reconstruct exactly the sample data presented to the encoder. This is not an aesthetic judgment and it is not a general synonym for “original.” It is an equality relationship between two defined sample sequences.
The object matters. If a workstation resampled a capture before encoding, a perfect FLAC decode reproduces the resampled input. If channels were swapped before encoding, it preserves the swap. If the wrong concert take was selected, the codec can preserve that error without losing a bit. If a tag names another performer, sample reconstruction neither confirms nor corrects the tag.
A serious report therefore names both sides of the comparison. It records the PCM input’s sample rate, bit depth, channel count, channel order, sample count and fingerprint; the encoder and its parameters; and the procedure used to decode and compare. “Lossless verified” without those nouns is a conclusion without a bounded object.
Three checks, three scopes
RFC 9639 places a CRC-8 in each frame header and a CRC-16 at the end of each frame. These checks help detect damage within framed data and structure. STREAMINFO can also carry a 128-bit MD5 signature calculated over the unencoded audio samples in a specified byte order.
The scopes are not interchangeable. A frame can pass its CRC while the complete sequence is missing, reordered or paired with misleading metadata. A whole-audio MD5 can match while a container’s index, timecode or artwork is wrong. An external digest over the file bytes can identify one exact container object while saying nothing about whether its samples came from an authorised source.
STREAMINFO also permits uncertainty. Total samples may be zero. Minimum or maximum frame size may be zero. An all-zero MD5 means that the signature is unknown. A conforming parser must not turn those sentinel values into positive evidence. If the digest was unknown, the receipt should say not supplied, not quietly convert absence into success.
The MD5 boundary is security-sensitive. RFC 6151 says MD5 is not prudent where collision resistance is required, while distinguishing inline checks used solely for error protection. FLAC’s MD5 is an error-detection mechanism, not a digital signature. A match does not authenticate an institution, establish custody or resist every adversarial construction. If origin matters, use a trusted external manifest and signature whose verified object is explicit.
Metadata describes; it does not testify
FLAC metadata can carry titles, artist names, comments, pictures, cue information and application-specific blocks. Those fields make files useful to people and systems. The format cannot make their assertions true.
This is especially visible in channel assignment. FLAC defines default orders for common channel counts. A WAVEFORMATEXTENSIBLE channel mask can describe a non-default speaker layout through a Vorbis comment. But the mask flags speakers; it does not magically reorder samples. The writer and reader must agree on the mapping, and reliance on that comment takes the file outside the streamable subset.
An archive that cares about multichannel meaning needs a separate semantic check. It should compare the declared layout with the source manifest, verify ordering through controlled signals or trusted production records, and record the playback mapping. The same PCM values routed to different speakers are sample-identical and experientially different.
Descriptive tags require similar discipline. Preserve the original metadata bytes, but keep the evidentiary status of each field: supplied by whom, derived from which catalogue, reviewed when, and contradicted by what. A checksum protects bytes from accidental change; it does not turn a claim inside those bytes into a fact.
The container may tell another story
Native FLAC is not the only carriage. RFC 9639 discusses Ogg mapping and the surrounding ecosystem includes Matroska and ISO Base Media File Format uses. Containers can repeat or derive facts that also appear in the embedded codec stream: timing, duration, sample rate, channel configuration, block or checksum-related data.
Duplication creates a choice of authority. If a container duration disagrees with STREAMINFO’s sample count, a player must do something. If an Ogg granule position, Matroska timestamp or MP4 sample table implies a different boundary, silently “fixing” the file destroys evidence of the disagreement.
The receipt should retain both readings, name the parser and rule that selected one for a task, and state the observed effect in named implementations. A codec checksum cannot adjudicate a container timeline. A container index cannot prove the decoded samples. Reconciliation is a recorded decision, not a property that appears merely because both structures are valid.
Streamable is not universally playable
The streamable subset narrows FLAC features to improve practical decoder compatibility. That is a prudent minimum specification, not a certificate issued to every player. RFC 9639 notes that early or low-quality decoders may implement only common features. Real support still belongs to running code.
Interoperability claims need a matrix: decoder and version, operating environment, feature combination, resource limits, parse result, check result, decoded sample fingerprint and error behaviour. Passing one library says nothing universal about another. A file outside the subset may decode correctly in a capable implementation; a subset-conforming file may still encounter an implementation defect or local policy ceiling.
The security envelope is equally separate. RFC 9639 warns that a frame as small as 49 bytes can expand beyond 2 MiB of PCM, and metadata can contain enormous numbers of fields or characters. A correct decoder must still manage allocation, arithmetic, recursion, time and output limits. “The samples reconstruct” is not “this untrusted object is safe to process without containment.”
Build the receipt in layers
Begin with custody: the exact captured or supplied object, who provided it, when, through which channel, and an external digest anchored outside the FLAC metadata. Record the PCM source description and any transformation before encoding. Then preserve the encoder name, version, build and parameters.
Identify the native stream and any container separately. Parse STREAMINFO without hiding zeros or unknowns. Report frame CRCs and whole-audio MD5 as different tests. Decode under named implementations and fingerprint the resulting PCM using a modern external digest as well as an exact comparison when the source samples are available.
Next reconcile channel assignment, sample rate, bit depth, duration and container timing. Keep metadata claims tied to their sources. Record parser and decoder resource use, imposed ceilings and rejected paths. Finally, if the institution claims successful listening, playout or downstream transformation, attach evidence from that stage rather than treating the codec result as its proxy.
The result is not one green badge. It is a chain whose links keep their own authority: custody identifies, the encoder transforms, the bitstream carries, checks detect bounded change, the decoder reconstructs, metadata describes, the container schedules and the playback system acts.
Sources
- Heng Lu — Minimum Initial Specification
- Heng Lu — Running-Code Primacy
- Heng Lu — Reality Layers
- IETF Datatracker — RFC 9639 history
- RFC 9639 information page
- RFC 9639 — Free Lossless Audio Codec
- RFC 9639 canonical text
- RFC 9639 canonical XML
- RFC 9639 errata
- IANA FLAC registry
- IANA media types registry
- RFC 1321 — MD5
- RFC 6151 — Updated MD5 security considerations
- RFC 3533 — Ogg encapsulation
- RFC 9559 — Matroska
- RFC 4732 — denial-of-service considerations
- RFC 2046 — media types
- RFC 8126 — IANA registration procedures
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

