FLAC Integrity Verifier

How FLAC MD5 Verification Works

Every FLAC file stores an MD5 checksum of the raw PCM audio in its STREAMINFO metadata block. When you rip a CD with EAC, XLD, or whipper, the encoder computes that checksum as it writes the file. This tool decodes the FLAC with libflac (the reference decoder) while MD5 checking is enabled, then compares the recomputed hash against the stored value. If they match, the audio data is intact — no silent truncation, no bit rot, no post-rip edits to the PCM.

That is the same check the official flac -t test mode performs, but entirely in your browser. Your file never leaves your device.

ID3 Pollution on FLAC Files

FLAC has its own metadata format (Vorbis comments). Some rips or taggers incorrectly bolt an ID3 tag onto the start or end of a FLAC file. Strict decoders like libflac may report a sync error at EOF even though the audio frames are fine. This tool flags ID3 pollution as a warning — not an automatic "corrupt" verdict — and runs a secondary decode through the browser's audio engine. If that succeeds, you'll see "browser decode OK" and know the audio is likely recoverable even though strict MD5 verification was skipped.

Unicode Filenames (NFC vs NFD)

macOS often stores accented characters in decomposed form (NFD: e + combining accent) while Linux torrent clients expect composed form (NFC: single é character). A torrent built on macOS can fail recheck on Linux even when the audio is perfect, because the byte-exact path in the .torrent does not match the on-disk filename. Batch mode reports each file's normalization form and warns when NFC and NFD differ — handy before you seed or after a failed recheck.

When There Is No Stored MD5

Older rips sometimes leave the STREAMINFO MD5 as all zeros. That means no checksum was recorded at encode time — the tool reports no-md5 as informational, not a failure. The file may still decode fine; you just cannot prove PCM integrity via MD5.

Frequently Asked Questions

More Audio Tools