Bit-Exactness compares every sample, but a WAV file is more than its samples — and the most common source of a surprising Bit-Exactness FAIL isn’t the audio data at all, it’s the container around it.
Metadata chunks
A WAV file can carry optional chunks beyond the raw data — LIST, bext (broadcast extension), cue, timecode information, application-specific tags. Two files can have byte-identical audio samples and still differ if one has metadata the other doesn’t: a DAW that stamps a bext chunk with the export timestamp, a mastering tool that writes its own LIST INFO block, a re-save that drops chunks the original had.
Bit-Exactness · sample 0 — a mismatch at sample 0 with everything downstream matching perfectly is the signature of a container/chunk difference, not an audio difference.
If the mismatch shows up right at the very first sample and stays consistent afterward — rather than drifting or appearing mid-file — that’s usually not the audio, it’s a chunk-alignment offset.
Padding and alignment
RIFF chunks are word-aligned, which occasionally means a byte of padding gets inserted or dropped depending on how a tool wrote the file. It’s invisible to playback — every player and DAW handles the alignment transparently — but it’s a literal byte-level difference if the comparison isn’t chunk-aware, which is exactly the kind of gap a byte-for-byte check will report as a failure even though nothing about the actual sound changed.
Dither
Any tool that requantizes — even a no-op resave through certain audio applications — may apply dither by default: a tiny, intentional, inaudible noise floor added specifically to avoid quantization artifacts during a bit-depth conversion. That dither is a real, measurable signal-level difference, not a bug, and it will fail Bit-Exactness every time even though the file is, for all practical purposes, the same recording. Unlike the container issues above, this one shows up as differences scattered throughout the file rather than concentrated at the start — a useful way to tell the two apart when you’re triaging a failure.
$ wavelens analyze --ref original.wav --dut resaved_in_daw.wav --out report.html
wrote report.html (bit_exact: FAIL, level_fidelity: PASS, spectral_fidelity: PASS, distortion: PASS)
Telling a real problem from a container artifact
None of this makes Bit-Exactness a bad check — it’s doing exactly what it’s supposed to do: telling you the files aren’t byte-identical. The mistake is treating that FAIL as evidence of an audible problem on its own. If Spectral Fidelity, Level Fidelity, Distortion, and Loudness all pass alongside a Bit-Exactness FAIL — as in the report above — the most likely explanation is one of the three causes here, not a real regression. See Bit-Exact vs. “close enough” for when the strict check is actually the one you want, and reach for --bitaccuracy (see Bit-Exactness vs. Bit Accuracy) when you want a measured “how close,” not just a strict yes/no.
See it for yourself.
WaveLens compares a reference file against a processed copy and shows you exactly where they diverge — down to the sample — not just whether they still sound the same. One command, one report you can point at.