Bit-Exactness vs. Bit Accuracy — which do I want?

Bit-Exactness and bit accuracy sound like the same idea stated two ways. On a WaveLens report they’re two different measurements, answering two different questions, and mixing them up leads to the wrong conclusion about a failure.

Bit-Exactness: a yes/no question

Bit-Exactness is binary. Every sample in the DUT either matches the reference exactly, or it doesn’t — there’s no partial credit, no tolerance, no “close.” One flipped bit anywhere in the file is a fail. It’s the strictest check WaveLens runs, and by default it’s non-gating: a Bit-Exactness fail alone doesn’t fail the Overall Verdict, because plenty of correct, expected processing (a codec round-trip, a valid resampling implementation, intentional dither) breaks it without changing anything anyone can hear.

$ wavelens analyze --ref ref.wav --dut dut.wav --out report.html --bitexact

Add --bitexact when you specifically need to require byte-for-byte equality for a PASS — confirming a “lossless” claim actually holds is the usual reason.

Bit Accuracy: a “how close” question

--bitaccuracy adds a second, separate reading alongside Bit-Exactness — a tolerant, measured comparison expressed in dB, rather than a strict pass/fail. Where Bit-Exactness can only tell you “identical” or “not identical,” bit accuracy tells you how far off, which is the more useful number when you already expect some non-zero difference and want to know whether it’s within an acceptable range.

$ wavelens analyze --ref ref.wav --dut dut.wav --out report.html --bitaccuracy

The two flags are independent of each other — --bitaccuracy doesn’t change whether Bit-Exactness itself gates the verdict, it just adds the additional measurement to the report.

Picking the right one for the job

• Confirming a claimed lossless step actually is lossless? Use --bitexact. You want a hard yes/no, and any non-zero difference is a real finding.
• Comparing something you already know won’t be byte-identical, but need to know how close it got? Use --bitaccuracy. A codec round-trip or a valid alternate resampling implementation will always show some numeric difference — the question is whether it’s small enough to not matter, and Bit-Exactness alone can’t answer that.
• Not sure yet? Run both. --bitexact and --no-bitexact can’t be combined (they’re opposites), but --bitaccuracy can be added alongside either — you get the strict verdict and the measured distance in the same report.

The report itself calls out explicitly when Bit-Exactness didn’t gate the verdict, so a PASS next to a Bit-Exactness FAIL never silently reads as “everything matched.”