A Lossless Decoder Needs More Than Successful Playback

Suppose you find an old concert rip on a drive you have not opened in years. The first track plays, the audience sounds familiar, and the ending seems right. That is reassuring. It does not demonstrate that every sample in the file has survived, or that a new decoder reconstructed it correctly.

Lossless audio raises a precise expectation: decoding should recover the original sample values. A listening check is useful for discovering obvious trouble, but it cannot substitute for comparing those values or checking the whole stream.

Private Press has experimental FLAC decoder and encoder work aimed at that engineering problem. It remains fenced off from production. The current app's FLAC artwork and metadata editing does not run this decoder or re-encode the audio, and cross-format conversion is disabled. What follows describes the experimental checks, not a shipped conversion feature.

Several different questions hide inside “decoded”

A FLAC decoder reads encoded frames and reconstructs PCM, the sequence of digital sample values. It has to interpret headers, rebuild samples from predictors and residuals, restore channel relationships, and reject values that violate the declared audio format.

Each step can fail in a way that still produces something audible. In a hypothetical bug, a decoder might return every frame except the last. A short excerpt could sound normal. A different bug could affect only extreme sample values or a stereo coding mode absent from a simple test track.

The experimental decoder therefore has checks at several levels. Header and frame CRCs check their respective encoded bytes. At completion, it compares the number of decoded samples per channel with the declared count and the computed sample MD5 with the declared digest. Those fields and checks are defined in the FLAC specification, RFC 9639.

The checks answer different questions. Correct checksums on the frames that arrived cannot establish that a whole frame was not omitted. A matching sample count alone cannot establish that the values are correct. The implementation checks both count and digest and requires the stream to be drained before reporting completion.

Missing evidence needs its own result

FLAC permits a stream to leave its total sample count unknown and its MD5 unset. The experimental decoder distinguishes these cases from verified values. Under its strict default, an unset count or digest produces an integrity-unverifiable error. An explicit permissive path can return decoded audio while identifying the checks it could not complete.

That distinction matters when assessing an old file. A missing digest is different from a digest mismatch. One means the expected value is unavailable; the other means the decoded output disagrees with a supplied value. Collapsing both into a success flag would erase information a preservation workflow needs.

MD5 here is the format's sample-integrity check. It is not proof of who created the recording, which edition it represents, or whether somebody intentionally substituted another valid file. Exact samples and trustworthy provenance are separate questions.

Compare with an independent decoder

An encoder and decoder written together can agree because they share a mistake. If both serialize a value incorrectly in the same way, an internal round trip may look successful.

The experimental checks use named FLAC files produced by independent tools, including Xiph’s FLAC tools and FFmpeg, as comparison points. They compare the decoded audio samples with the expected samples and confirm that deliberately damaged files produce the expected errors. Some damaged files have recalculated checksums so the tests reach a different format rule instead of stopping at the checksum.

That gives evidence for these tested files and failure cases. It does not establish that every FLAC file or feature has been tested.

Verify the source you actually opened

File-backed decoding introduces another question: did the file change while it was being read?

The streaming decoder remembers which open file it read and checks that file again when it finishes. It uses the open file handle rather than inspecting only a pathname, which could point to a different file after a replacement or a changed symbolic link.

Tests cover files that are truncated, extended, or rewritten during a read. Source checks and stream checks work together: a changed file can explain a failed digest, while a byte change that escapes the file-state comparison may still fail a frame checksum. These checks catch specific changes; they cannot rule out every concurrent change.

What to do with a file you doubt

For a FLAC file you want to check today, Xiph's documented flac -t test mode decodes without writing an output file and checks stream errors and the stored sample MD5. Its command-line documentation explains the behavior. A passing test adds useful integrity evidence; it cannot identify the release or supply a missing original comparison.

Keep the original when investigating a failure. Record which tool reported which problem before deciding on a repair. Private Press can improve the artwork and metadata of supported FLAC files through its current metadata editor. Experimental codec evidence concerns the further responsibility of reconstructing audio, where “it played” is only the beginning of the question.