What causes "Expected data box" in remotion-dev/remotion?

Verify the file reports a data chunk and a duration: ffprobe .

remotion-dev/remotion · error · Error

Expected data box

Error message

Expected data box

What it means

Thrown while computing a WAV file's duration: getDurationFromWav walks the already-parsed box list and finds a 'wav-fmt' box but no 'wav-data' box. The duration formula (dataSize / (sampleRate * blockAlign)) needs the data chunk's size, so without it the parser aborts rather than guess. It surfaces when a caller requests a duration-derived field from parseMedia() on a WAV that never yielded a 'data' chunk.

Source

Thrown at packages/media-parser/src/containers/wav/get-duration-from-wav.ts:16

import type {ParserState} from '../../state/parser-state';
import type {WavData, WavFmt} from './types';

export const getDurationFromWav = (state: ParserState) => {
	const structure = state.structure.getWavStructure();

	const fmt = structure.boxes.find((b) => b.type === 'wav-fmt') as
		| WavFmt
		| undefined;
	if (!fmt) {
		throw new Error('Expected fmt box');
	}

	const dataBox = structure.boxes.find((b) => b.type === 'wav-data') as WavData;
	if (!dataBox) {
		throw new Error('Expected data box');
	}

	const durationInSeconds =
		dataBox.dataSize / (fmt.sampleRate * fmt.blockAlign);
	return durationInSeconds;
};

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Verify the file reports a data chunk and a duration: ffprobe <file>.
Re-download or re-export the WAV so the 'data' chunk is complete.
Switch to Mediabunny (@mediabunny), the documented successor to @remotion/media-parser, which has broader WAV support.
Wrap parseMedia() in try/catch and skip or fall back for files that fail.

Example fix

// before
const info = await parseMedia({ src: './clip.wav', fields: { durationInSeconds: true } });

// after
try {
  const info = await parseMedia({ src: './clip.wav', fields: { durationInSeconds: true } });
} catch (err) {
  // fall back to ffprobe for malformed/truncated WAVs
  const dur = await getDurationViaFfprobe('./clip.wav');
}

Defensive patterns

Strategy: try-catch

Validate before calling

import { parseFile } from 'music-metadata'; // or ffprobe
// Validate the WAV has a data chunk before parsing:
// run `ffprobe -v error -show_entries format=duration -of default=nw=1 file.wav`
// a non-empty duration means a data chunk was found.

Try / catch

try {
  const info = await parseMedia({ src, fields: { durationInSeconds: true } });
} catch (err) {
  if (err instanceof Error && /Expected data box/.test(err.message)) {
    // WAV missing its data chunk — fall back to ffprobe or skip
  } else throw err;
}

Prevention

Validate WAVs with ffprobe before passing them to parseMedia().
Prefer Mediabunny (@mediabunny) over the deprecated @remotion/media-parser parseMedia().
Don't request duration-derived fields on streams you know are incomplete.

When it happens

Trigger: parseMedia({ src, fields: { durationInSeconds: true } }) (or any field that pulls duration) on a .wav whose 'data' chunk was never parsed: a file truncated after 'fmt ', a RIFF file whose samples live in a non-'data' chunk, or a stream parsed before the data chunk arrived.

Common situations: Partially-downloaded WAV; an encoder that wrote 'fmt ' then crashed before 'data'; reading a live/progressive stream too early; a file that is RIFF but not a real WAV (e.g. AVI renamed .wav).

Related errors

AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12). Data as JSON: /api/errors/f9e0ab190762a41a. Report an issue: GitHub.