WAV File Inspector

Reads a WAV file's RIFF container in the page — nothing is uploaded — and reports everything the header declares: format code, channels, sample rate, bit depth, byte rate, block align, data size, and the duration and sample count computed from them. Every chunk is listed with its identifier, offset and size, which is how you spot a bext broadcast header, a cue list, stray LIST tags or trailing garbage that some editor left behind. LIST/INFO tags are decoded into a readable table.

"WAV" describes a container, not a codec, and the format code is where that becomes visible. 0x0001 is plain PCM and 0x0003 is IEEE float, but the same wrapper can also hold A-law, µ-law, ADPCM and — genuinely — MPEG Layer 3, so a .wav file is not automatically uncompressed. 0xFFFE marks the Extensible variant, which strict readers expect for anything above two channels or sixteen bits; it carries a channel mask saying which speaker each channel feeds and a GUID naming the real format.

The header fields are redundant on purpose, and that makes them a consistency check. Block align should equal channels × bit depth ÷ 8, and byte rate should equal that times the sample rate: for CD audio, 2 × 2 × 44,100 gives 176,400 bytes per second, which is where one minute of stereo 16-bit audio at 44.1 kHz gets its 10,584,000 bytes. If the declared byte rate disagrees with the arithmetic, the file was written by something careless and the duration a player shows will be wrong.

Two structural details cause most parsing bugs. Chunks are word-aligned: a chunk with an odd size is followed by a pad byte that its size field does not count, and a reader that forgets this desynchronises on the very next chunk. And RIFF stores sizes in 32 bits, so a WAV file cannot exceed four gigabytes — a little over six hours of CD audio — which is why long recordings use RF64 or BW64 instead. One more asymmetry worth knowing: 8-bit PCM samples are unsigned with 128 as silence, while 16-bit and deeper are signed with zero as silence.