When FFmpeg Reports a Corrupt WAV Tail, Inspect the Length Headers

A minimal audio smoke test produced a WAV file that played normally, yet FFmpeg printed two alarming messages near the end of the file:

Packet corrupt
corrupt input packet in stream 0

Treating any occurrence of corrupt as a failed generation would have discarded usable audio. Ignoring the warning would also have been unsafe because later uploaders, editors, or waveform tools may enforce the container more strictly. The useful question was narrower: did the file contain damaged samples, or did its container describe the wrong length?

Start with the measurable mismatch

A RIFF/WAVE file stores length fields in its container. The RIFF header describes the overall payload, while the data chunk describes the audio payload. Microsoft’s RIFF overview documents the four-byte size field used by the outer chunk.

Binary inspection of the generated file found:

Measurement	Value
Actual file size	15,790,352 bytes
Total size implied by the RIFF header	2,147,483,591 bytes
Declared data payload	2,147,483,315 bytes
Decodable audio	about 82.24 seconds
Audio format	48 kHz, stereo, 16-bit PCM (uncompressed pulse-code-modulated audio)

The declared lengths were close to two gigabytes, while the file ended after about 15.8 megabytes. FFmpeg followed the container’s declaration, expected many more bytes, and reached the physical end of the file first. That mismatch directly explained the tail warning.

The inspected file still decoded through its available PCM payload, and the decode process returned exit code zero. This evidence supported a bounded conclusion: the observed warning came from inconsistent container lengths, while the available sample payload remained decodable. It did not prove how the upstream service wrote the file.

Keep the writer explanation as an inference

A plausible implementation is a streaming writer that starts the WAV before the final duration is known. Such a writer may place a large sentinel in the RIFF and data size fields, append samples, and then fail to replace the sentinel with final sizes.

That mechanism fits the observed numbers, but the client-side file cannot prove the service’s internal implementation. The public conclusion should therefore stop at the verified boundary: the length fields and physical file size disagree. Root-cause language becomes misleading when it turns a compatible implementation hypothesis into a confirmed server fact.

Rewrite the container before downstream use

For this PCM file, the safest operational repair was to let FFmpeg decode the available audio and write a new WAV with lengths derived from the completed output:

ffmpeg -i input.wav `
  -map 0:a:0 `
  -c:a pcm_s16le `
  repaired.wav

The repaired file then passed a strict decode check:

ffmpeg -v error `
  -i repaired.wav `
  -f null -

The second command produced no error output and completed successfully. Rewriting also made the new file’s declared lengths agree with its physical size.

This operation creates a different file, so its SHA-256 changes even when the audible result is preserved. Any workflow that binds approval, provenance, or cost records to a content hash must update that state deliberately. The original file should remain available until the replacement has passed the same duration, channel, sample-rate, and decode checks.

Do not reduce media QA to one log keyword

This incident exposed a fragile automation rule: searching stderr for corrupt and failing immediately. FFmpeg diagnostics carry useful evidence, but a reliable gate needs several signals:

1. inspect the process exit code;
2. compare the physical file size with declared container sizes;
3. confirm that decoding reaches the expected duration;
4. rewrite malformed containers into a controlled format;
5. run a strict decode check on the rewritten artifact;
6. record the new hash before later approval or publication.

A zero exit code alone is also insufficient. It showed that this decoder recovered the available samples, not that every downstream consumer would accept the malformed header. The rewrite removed that compatibility risk instead of asking each later tool to tolerate it.

Verification boundary

The completed smoke test established five facts: the file existed at the expected local boundary, the RIFF and data sizes exceeded the real file, the available PCM decoded for about 82 seconds, FFmpeg returned success despite the tail diagnostic, and a rewritten WAV passed error-level decoding without output.

It did not establish bit-for-bit equivalence between files, compatibility with every possible audio application, or the upstream writer’s source-code path. Those remain outside the evidence.

The reusable lesson is to debug media warnings at the format boundary. Measure what the container promises, measure what the file contains, verify what a decoder can consume, and normalize the artifact before it enters a stricter pipeline.