FLACCID
All posts
Library August 3, 2026 · 6 min read

Bit Rot Is Real: How to Verify Your FLAC Files

FLAC files carry their own fingerprint. How to test a whole library for silent corruption with flac -t, what the MD5 means, and what to do when a file fails.

Here is an uncomfortable thought experiment. Your music library has been copied between four drives over ten years, through two failing USB cables, one flaky network share, and a laptop with a RAM stick you never knew was marginal. How many of those files are still exactly what you ripped? You don't know. You can't know, by looking. A file with a few flipped bits has the same name, the same size, the same album art, and plays fine right up until the part that clicks.

This is bit rot: silent corruption that accumulates in stored data without any error, warning, or crash. Every large collection has some. The question is whether you can detect it, and this is where FLAC quietly outclasses every other music format you could have chosen.

FLAC checks itself

When a FLAC encoder runs, it computes an MD5 checksum of the raw, unencoded audio and stores it in the file's header. Every audio frame also carries its own CRC. Together they mean a FLAC file can be tested: decode it, recompute the checksum, compare. If the numbers match, the audio inside is bit-for-bit what was encoded. If they don't, something has changed, and the decoder will tell you exactly which frame went wrong.

No other common music format offers this. WAV has no checksum at all. MP3 has an optional per-frame CRC that almost nothing uses. ALAC, wrapped in MP4, has none. It's one of the strongest reasons to archive in FLAC: the file can prove its own integrity.

A FLAC file that passes verification is not "probably fine". It is, sample for sample, the same audio it was on the day it was made.

The one command you need

The reference FLAC tools are free, cross-platform, and tiny. On Linux they're in every package manager (flac); on a Mac, brew install flac; on Windows, download the official build and put it on your path. Then:

flac -t album/*.flac

The -t flag means test. It decodes every file in full, checks every frame CRC, verifies the MD5, and reports ok or an error per file. It never writes anything and never modifies a file, so there's no way to make things worse by running it.

To do a whole library at once, recurse:

find /path/to/music -name '*.flac' -print0 | xargs -0 flac -t 2>&1 | tee flac-test.log

Then search the log for anything that isn't ok. On a large collection this takes a while (it's decoding every track), so run it overnight. Add -w to have the tool complain about non-fatal oddities in the file structure too.

If you'd rather not use a terminal: foobar2000 has a File Integrity Verifier component, dBpoweramp has a Test Conversion mode, and XLD on the Mac can verify on import. They all do the same decode-and-compare under the hood.

Reading the results

Three outcomes come up:

  • ok. The file is intact. Move on.
  • A CRC or MD5 mismatch. The audio has been altered since encoding. This is genuine corruption. Note the file and keep going; you'll deal with it in a batch.
  • "MD5 signature is unset" or a warning about a zero MD5. Some encoders (a few rippers, some streaming rips, early hardware) skip the checksum entirely and leave it blank. The frame CRCs still work, so flac -t can catch damage, but you lose the full-file guarantee. Re-encoding the file with the reference encoder (flac -8 --verify, which is also lossless) adds a proper MD5 for the future.

A related tool, metaflac --show-md5sum file.flac, prints the stored checksum without decoding, which is handy for comparing a file against its backup copy: if the two MD5s match, both files contain the same audio, even if their tags differ.

What verification does and doesn't catch

Be clear about the boundaries.

It catches: any change to the audio data after encoding. Drive errors, bad copies, truncated transfers, a corrupted sector, a flaky cable. This is the stuff that actually goes wrong over years.

It does not catch: a bad rip. If the CD was scratched and the ripper interpolated over the errors, the FLAC faithfully encodes the wrong audio and verifies perfectly. That's what AccurateRip is for, and it's why ripping carefully matters in the first place. Verification proves the file hasn't changed since it was made; it can't prove it was made correctly.

It also doesn't catch damaged tags or cover art. Metadata lives outside the checksummed region, so a corrupted picture block won't fail the test. That's rarely a disaster (tags are easy to regenerate), but it's worth knowing.

When a file fails

Don't try to repair it. There's no fixing missing bits; the information is gone. Instead:

  1. Check the backup. If you have one, the copy there almost certainly passes. Restore it and re-test.
  2. Compare MD5s. If both copies fail with different checksums, they were corrupted independently, which is rare but tells you the problem is upstream (bad RAM, bad cable) rather than one bad drive.
  3. Re-rip or re-download. If the CD is on the shelf, rip it again. Download stores usually let you re-download purchases.
  4. Suspect the drive. One failed file is bad luck. A cluster of failures in files that were fine last time is a drive going bad. Check its SMART data and plan the replacement now, not later.

Make it a habit

Corruption detected early is a restore. Corruption detected late, after it's been dutifully mirrored into your backups, is a loss. A reasonable rhythm:

  • After any big copy or migration, verify the destination before deleting the source. A drive-to-drive move is exactly when bits get dropped.
  • Every few months, run the full test on the main library.
  • Before refreshing a backup, verify the source, so you don't overwrite good copies with bad ones.

If your storage is on a checksumming filesystem (ZFS, Btrfs) or a NAS that scrubs regularly, the drive layer is already doing something similar for every file. FLAC's check still earns its keep, because it covers the file through every copy to a plain USB drive, a phone, or a laptop that has no such protection.

The larger point

Ownership is only worth something if what you own stays intact. A streaming library can't rot, but it can also vanish on someone else's schedule. A local library can't vanish, but it can rot on yours. FLAC's built-in verification is the tool that turns "I have all my music" from a hope into a fact you can check with one command, on any machine, in ten years.

Want to see what's inside one of your files? Open the player, drop in a FLAC, and the readout shows the codec, sample rate and bit depth the decoder is actually seeing.

try it yourself

Play your own lossless files, free

FLACCID plays your local FLAC, ALAC, WAV and more right in the browser: no upload, no account, no streaming.

Launch the Player