Validate WAV RIFF Chunk Bounds Before Decoder Handoff

Direct answer

A WAV file is a RIFF container, not a fixed 44-byte header followed unconditionally by PCM samples. A normal PCM fixture may have that familiar size, but valid files can contain optional metadata chunks, extra format fields or padding. A reader that jumps to byte 44 can mistake metadata for samples or skip part of a different layout. Keep container parsing separate from media decoding and from any later inference task; first establish which bounded data range a supported profile exposes. For a declared classic RIFF/WAVE profile, parse the top-level RIFF identifier, its little-endian unsigned 32-bit size, the WAVE form type and then a sequence of chunks. The parent size covers the form type and child chunk bytes, including required pad bytes. A child chunk consists of a four-byte ID, a four-byte size and its data; that size excludes the eight-byte child header and any pad byte. When a chunk data size is odd, the next chunk begins after the one-byte word-alignment pad. These are container lengths, not a fixed header length. Use a bounds-checked cursor and wider arithmetic before every addition. Establish the declared RIFF end and compare it with the actual source length; reject sizes that overflow, escape the parent, exceed an application-defined byte cap, or cannot be fully read. For each child, validate header availability, chunk end and padded next offset before seeking or skipping. Unknown chunk IDs can be skipped only within the same validated bound; do not allocate an array from an untrusted size. Limit the number of chunks as well as bytes so a file with many tiny chunks cannot cause unbounded work. Define a supported WAVE profile rather than promising every file labeled WAV. The profile should state how it finds `fmt ` and `data`, whether duplicate or misplaced required chunks are rejected, and which format-chunk lengths or compression codes it forwards to a decoder. The format chunk is not always one fixed 16-byte PCM structure; extensible and compressed forms need their own documented handling. This guide does not parse sample-rate values or decide whether audio is suitable for a model. Preserve the chunk range and pass only a format the selected decoder explicitly supports. RIFF/WAVE’s 32-bit size fields cannot represent arbitrarily large files. RF64/BW64 use a different container identifier and a `ds64` chunk to provide extended sizes. A classic RIFF parser must not treat the `0xFFFFFFFF` sentinel as an ordinary multi-gigabyte length, cast it to a negative signed size, or allocate from it. Either reject RF64/BW64 as unsupported before reading chunks, or route it to a separately verified implementation that handles its 64-bit size table. The format’s large-file limit is not an Android RAM estimate. Prefer a maintained media/container library for production when its supported profiles and bounds behavior fit the feature. If application code owns a small inspection parser, treat it as an untrusted-input boundary and test it independently from the decoder. A parser finding a `fmt ` and `data` chunk proves only that the selected structural checks passed; it does not prove codec decoding, successful playback, model compatibility or a complete offline AI task. COVE-ASR-01 says the current shared inference path wraps PCM as WAV for output; it does not prove Cove reads arbitrary imported WAV containers. Build synthetic byte fixtures rather than using live user recordings. Include a minimal supported file, optional unknown and metadata chunks before and between known chunks, an odd-sized chunk with a pad byte, noncanonical but profile-allowed format-chunk size, duplicate `fmt ` or `data`, wrong ordering, incorrect parent size, chunk-size overflow, missing pad, truncated chunk body and a declared payload that ends before its final byte. Assert exact offsets and reject reasons. Keep malformed files local, cap reads and parsing steps, and do not publish a compatibility list from synthetic fixtures alone.

An imported WAV has metadata before its audio data

A user selects a WAV containing a valid WAVE header, an optional metadata chunk and an audio data chunk that does not begin at byte 44. A fixed-offset reader instead passes metadata bytes to a downstream decoder and the task fails in a way that looks like an inference problem.

Decision

Walk the RIFF chunk sequence using declared bounded lengths and alignment, then hand off only a validated range supported by the selected decoder.

Expected outcome

The import path either identifies the supported data range or rejects the file with a container-level reason; it does not silently send guessed bytes into inference.

Evidence to collect

The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:

• Unsigned parent/child boundary arithmetic
• Unknown-chunk, pad and early-EOF fixtures
• Supported format profile and decoder-stage separation

A release claim is valid only for the recorded configuration and acceptance set. Generalization requires additional records.

Implementation workflow

1. Declare the accepted container profile. State whether the reader accepts classic RIFF/WAVE only, which required chunks it recognizes, how it treats duplicate or out-of-order `fmt ` and `data`, and which format-chunk variants it delegates. Route RF64/BW64 elsewhere or reject it explicitly.
2. Parse the top-level bound safely. Read RIFF identifiers and unsigned little-endian size fields without casting them to signed lengths. Compute the parent end using checked wide arithmetic, account for the WAVE form type and ensure the declared parent fits the actual source before iterating.
3. Walk each chunk without fixed offsets. Require the complete eight-byte child header, validate the data end against the parent and real source, then account for the one-byte pad after odd data sizes. Skip unknown chunks by validated bounded seek or drain; never allocate from the declared chunk length.
4. Validate the selected format and data ranges. Apply the declared policy for required, repeated or misplaced `fmt ` and `data` chunks. Preserve the exact `data` offset and length for a supported decoder; do not infer PCM16 or parse a format variant the implementation has not declared.
5. Reject extended or malformed containers explicitly. Treat RF64/BW64 identifiers and the 0xFFFFFFFF size sentinel as a separate format requiring `ds64` support. Reject truncated data, overflow, parent-boundary violations, missing alignment padding and excessive chunk counts with a structural error, not a guessed decoder fallback.
6. Test limits independently from decoding. Use synthetic fixtures to assert chunk offsets, skip behavior, bounds and reject categories, then test decoder handoff as a separate stage. A structurally accepted file is not proof of codec, playback, sample-format or model compatibility.

Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.

Acceptance criteria

• The reader never assumes a 44-byte header; it finds supported chunks from validated RIFF boundaries and accounts for each chunk header and odd-byte pad.
• All size arithmetic is checked against both the declared parent and actual source length, with byte and chunk-count caps, no allocation from untrusted lengths, and explicit early-EOF failure.
• The supported profile specifies required/repeated chunk and format policy; unsupported compressed/extensible profiles and RF64/BW64 are rejected or sent to a separately verified parser.
• Tests distinguish container structure from decoding/inference and make no claim that a structural pass proves supported audio or Cove import behavior.

Decision table

Failure patterns to prevent

• Assuming a universal 44-byte WAV header
• Allocating from untrusted chunk sizes
• Treating RF64 sentinel sizes as ordinary RIFF lengths

Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.

Minimum reproducibility record

Release checklist

• ☐ The primary query is answered without an unsupported number.
• ☐ Every artifact and runtime is pinned.
• ☐ The representative task and failure policy are explicit.
• ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
• ☐ User-content and network boundaries are documented.
• ☐ Result wording applies only to the recorded configuration.
• ☐ The page links to raw method or evidence when results are added.

Sources and related evidence

• Cove Travel voice translation
• Microsoft Learn — Resource Interchange File Format (RIFF)
• Microsoft Learn — RIFF services and chunk traversal
• EBU — RF64: An Extended File Format for Audio
• EBU — Tech 3306 RF64 structure, version 1.1
• ITU-R — Recommendation BS.2088-2 BW64 format

Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.

Frequently asked questions