You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
8-bit WAV is decoded as signed, but WAV 8-bit PCM is unsigned (silence reads as -128) #12
Digital silence (128) decodes as -128 — full negative.
Why it is only worth filing now
Before #11 the 8-bit path was usually reading from the wrong offset anyway: the old size-subtraction counted the RIFF word-alignment pad byte as header, so a 3-sample 8-bit file returned [2, 3, 0] where the payload was [1, 2, 3]. #11 fixed the alignment, so the 8-bit path now lands on the right bytes for the first time — which makes the sign error the remaining defect and newly reachable.
The signedness is not decided in the WAV code. It comes from mk_pcm_audio_codec / num_find_num_type_for picking the struct character, whose blast radius is everyrecode consumer, not just the WAV path. Non-WAV PCM callers may legitimately want today's signed b.
Suggested shape
For width_bytes == 1on the WAV path specifically, decode with the unsigned struct char B and subtract 128; the encoder adds it back. Leave generic PCM callers on the current signed behaviour, or give them an explicit signed= choice.
Acceptance test — the probe values above round-trip:
Activity