The WAV header is not 44 bytes

Prabhash — Fri, 23 Oct 2026 20:25:20 +0000

Most WAV bugs I have seen come from this line:

samples = data[44:]

44 is the length of the smallest legal WAV: 12 bytes of RIFF header, a 24-byte fmt chunk, then the 8-byte header of the data chunk. So it is right for that one file. It is not the format.

WAV is RIFF, and RIFF is a list of chunks. Each chunk is a 4-byte id, a 4-byte little-endian size, then that many bytes, padded to an even length. The data chunk can sit anywhere in the list, and anything the writer added goes in front of it.

Five files, four offsets

These are from loremfile.dev, a CC0 fixture set I maintain. I parsed each one by walking its chunks.

File	`fmt` body	Before `data`	Samples start
16-bit stereo	16 bytes	nothing	44
8-bit stereo	16 bytes	nothing	44
32-bit float	18 bytes	`fact`, 12 bytes	58
24-bit, 48 kHz	40 bytes	nothing	68
16-bit with tags	16 bytes	`LIST`, 50 bytes	94

Same format, same 440 Hz sine wave, four different answers. Three of the five break data[44:]. None of them is unusual: a float export, a 24-bit export, and a file with a title and artist in it.

The header length is not fixed

fmt is 16 bytes for plain PCM, 18 when the writer adds the cbSize field, and 40 for WAVE_FORMAT_EXTENSIBLE. That moves the samples on its own.

Other chunks move them further. Non-PCM files should carry a fact chunk with the sample count, which puts the float file at 58. Metadata goes in LIST/INFO, which puts the tagged file at 94. Read the sizes and skip what you do not recognise.

Bit depth does not tell you the sample type

The format tag does:

1 is integer PCM
3 is IEEE float
0xFFFE is extensible, and the real format is a subformat 24 bytes into the chunk body

The float file reports 32 bits with tag 3. Read those bytes as 32-bit integers and every sample comes out huge, because you are reading an exponent as a magnitude.

The 24-bit file is the other half of this. Its tag is 0xFFFE, so code that switches on the top-level tag gives up on it, even though the subformat says plain PCM.

8-bit is unsigned

Everything above 8-bit is signed. Same sine wave, same instant, three of the files above:

8-bit:   128, 128, 128, 128, 129, 129, 130, 130
16-bit:  0, 0, 181, 181, 361, 361, 541, 541
float:   0.0, 0.0, 0.0055, 0.0055, 0.011, 0.011

Silence is 128 in the first and 0 in the other two. Read the 8-bit file as signed and silence becomes a full-scale offset.

Walking the chunks

import struct

def wav_chunks(data):
    """Yield (chunk_id, body_offset, body_size) for every top-level RIFF chunk."""
    if data[0:4] != b"RIFF" or data[8:12] != b"WAVE":
        raise ValueError("not a RIFF/WAVE file")
    pos = 12
    while pos + 8 <= len(data):
        chunk_id = data[pos:pos + 4]
        size = struct.unpack_from("<I", data, pos + 4)[0]
        yield chunk_id, pos + 8, size
        pos += 8 + size + (size % 2)   # chunks are padded to an even length

def wav_samples(data):
    """The format tag, bit depth and sample bytes, wherever they turned out to be."""
    tag = bits = None
    for chunk_id, offset, size in wav_chunks(data):
        if chunk_id == b"fmt ":
            tag, _, _, _, _, bits = struct.unpack_from("<HHIIHH", data, offset)
            if tag == 0xFFFE and size >= 40:      # the real tag is the subformat
                tag = struct.unpack_from("<H", data, offset + 24)[0]
        elif chunk_id == b"data":
            return tag, bits, data[offset:offset + size]
    raise ValueError("no data chunk")

Two things to keep. The size % 2 padding is required by RIFF and easy to miss, because it only matters on odd-sized chunks. Resolving 0xFFFE to its subformat means extensible files stop being a special case.

What the naive slice actually does

A reader ran the files and worked out something I left out: the two bugs fail very differently, and that is why the first one survives.

On the 24-bit file, data[44:] starts 24 bytes early. That is 8 samples, or 4 frames, so the audio is just delayed. On the LIST file it starts 50 bytes early, which is 25 samples. Every sample is still there, offset by 12.5 frames, and because 25 is odd in an interleaved stream the left and right channels swap too. Both still sound like audio.

The float file is the one that fails loudly. 14 bytes is 3.5 samples, so every value is spliced from halves of two neighbours. The first two come out as 4.8e-36 and 2.6e+20, and more than half of the first 20,000 land outside [-1, 1].

So the offset bug is silent and the format bug is the one that crashes. Test only with integer PCM and you keep the silent one.

The files

The links in the table are direct, with no sign-up and no redirect, so curl and CI can fetch them. The full WAV set is on one page with a SHA-256 for each file. Everything is CC0, so you can copy them into your own fixtures instead of depending on my domain.

If you have a WAV reader, point it at the 58-byte and 94-byte files and see what comes out.

Sample files you can hotlink: 228 CC0 test fixtures with stable URLs

Prabhash — Thu, 24 Sep 2026 10:11:29 +0000

Every test suite that touches uploads eventually needs a real PDF, a video that seeks, a CSV with a broken row somewhere in it. Usually someone hotlinks a file from a random site, and a few months later it moves or changes and the test breaks for no reason.
loremfile.dev is 228 synthetic files across 78 formats, all CC0, served with CORS and byte ranges, with a SHA-256 for every file.

Use it:

curl -O https://loremfile.dev/pdf/a4-3pages.pdf

Verify it (bytes at a published URL don't change):

import hashlib, json, urllib.request
manifest = json.load(urllib.request.urlopen("https://loremfile.dev/manifest.json"))
entry = next(e for e in manifest["fixtures"] if e["path"] == "pdf/a4-3pages.pdf")
data = urllib.request.urlopen("https://loremfile.dev/" + entry["path"]).read()
assert hashlib.sha256(data).hexdigest() == entry["sha256"]

Or all at once: sha256sum -c sha256sums.txt --ignore-missing (macOS: shasum -a 256 -c sha256sums.txt --ignore-missing).

Edge cases, on purpose
edge/pdf-truncated-60pct.pdf, edge/jpg-truncated-50pct.jpg, edge/mp4-truncated-50pct.mp4, edge/zero-byte.csv, edge/json-bom.json, edge/json-trailing-comma.json, edge/csv-ragged-rows.csv - 19 in total, for when you want to test that a parser fails.

One Limitation:
Around 30 requests/second per IP, 429 above that. A normal test suite should be fine.

Use it in GitHub Actions
Also supports direct integration with Github Actions. Every file gets checked against its hash, and the step fails if a byte's off:

- uses: kumarprabhashanand/loremfile/action@action-v1
  with:
    paths: pdf/minimal.pdf mp4/720p-5s.mp4
    formats: svg

How it's built
Everything's generated from synthetic data by open-source code (MIT) in a pinned container, pushed to Cloudflare R2, and archived as a GitHub release so anyone can mirror it. No accounts, cookies, or analytics. Claude agents did most of the design and implementation here.

https://loremfile.dev

DEV Community: Prabhash