EByte Case Study Reading Every Chunk of a WAV File

The first WAV case study used a schema that knew exactly three chunks in a fixed order. Real WAV files aren’t that tidy. Recorders and editors add a LIST chunk with a title and the software name, and some put it before the audio, some after. EByte 0.2.0 adds a repeat field for this, and this case study tries it on a WAV file with metadata, using the released ebyte 0.2.0 Linux binary downloaded from GitHub. Its checksum matched SHA256SUMS before anything ran.

The file is the same tenth of a second of a 440 Hz tone, with a 52-byte LIST/INFO chunk added at the end: the title “EByte tone” and the encoder “Python wave”. It’s 1,696 bytes. ffprobe shows both tags, and Python’s wave module reads 800 frames.

The Old Schema Stops Where the Metadata Starts

The 44-byte header schema from the earlier case study decodes the tone and then finds more bytes:

{"diagnostic_version":1,"stage":"decode","code":"trailing_data","path":"","offset":1644,"field_start":null,"expected":"end of input","observed":"additional byte"}

Offset 1644 is exactly where the LIST chunk begins. EByte doesn’t skip what it can’t describe, so the exit code was 2.

A Schema That Reads Chunks

The new riff-wave schema describes the 12-byte RIFF header and then one repeating block, read until the input ends:

{"name": "chunks", "type": "repeat", "until": "end_of_input", "fields": [
  {"name": "id", "type": "string", "encoding": "ascii", "length": 4},
  {"name": "size", "type": "u32"},
  {"name": "body", "type": "bytes", "length": {"field": "size"}}
]}

inspect lists three elements: fmt at offset 12 with 16 bytes of body, data at 36 with 1,600, and LIST at 1644 with 44. Decoding gave a document whose chunks array has those three entries, and encoding it unchanged gave back all 1,696 bytes, compared with cmp.

Three Edits

Each edit was made in the JSON, encoded with the 0.2.0 binary and checked with ffprobe and Python’s wave, neither of which knows anything about EByte.

Retitle. In the LIST body, the hex for “tone” became the hex for “demo”. The file stayed 1,696 bytes, ffprobe reported the title “EByte demo”, and wave still read 800 frames.

Remove the metadata. Deleting the third element of chunks gave a 1,644-byte file. ffprobe showed no tags, and the audio was untouched. There was no count of chunks to update, because a repeat has none. The RIFF size field is another matter: it still said 1,688 until it was changed by hand to 1,636. Both ffprobe and wave happened to accept the stale value, so nothing complained, but the hand edit is what makes the file correct. Updating sizes like this automatically is the next planned release.

Move the metadata. Swapping the last two elements put LIST at offset 36 and the audio at 88. Same 1,696 bytes, the same tags in ffprobe, the same 800 frames in wave. The old fixed-order schema rejects the moved file at offset 36 with constraint_mismatch on /data_id, because it expects the data chunk there. The chunk schema doesn’t care about order.

Where It Stops

RIFF pads a chunk with an odd size to an even length, and the pad byte isn’t counted in the chunk’s size. A schema without arithmetic can’t express that. To see what happens, a 3-byte note chunk plus its pad byte was added to the end:

{"diagnostic_version":1,"stage":"decode","code":"truncated_input","path":"/chunks/4/id","offset":1708,"field_start":1707,"expected":"4 bytes","observed":"1 bytes"}

EByte read the pad byte at 1707 as the start of a fifth chunk and ran out of input one byte later. ffprobe read the file fine. So this schema covers WAV files whose chunks all have even sizes, which is common but not guaranteed, and the schema library says so.

What Else 0.2.0 Can Read

The same release adds a tag-based repeat: keep reading elements while the next bytes match a fixed signature. The new zip schema uses it twice, for local entries (PK 03 04) and for central directory entries (PK 01 02), so it reads archives with any number of files. Its test sample holds three files, two stored and one deflated, and decodes to the same three names that Python’s zipfile lists. The schema reference covers both kinds of repeat, and the download page has the 0.2.0 archives.