remotion-dev/remotion · error · Error

Bitrate mismatch at offset ${initialOffset}: ${bitrateInKbit

Error message

Bitrate mismatch at offset ${initialOffset}: ${bitrateInKbit} !== ${cbrMp3Info.bitrateInKbit}

What it means

Thrown by `parseMpegHeader` when parsing a constant-bitrate (CBR) MP3 and a subsequent frame's bitrate (`bitrateInKbit`) differs from the bitrate recorded for the first frame (`cbrMp3Info.bitrateInKbit`). The library assumes CBR files are truly constant; encountering a different bitrate mid-stream signals inconsistency.

Source

Thrown at packages/media-parser/src/containers/mp3/parse-mpeg-header.ts:39

	if (iterator.bytesRemaining() < 32) {
		return;
	}

	// parse header
	const {
		frameLength,
		bitrateInKbit,
		layer,
		mpegVersion,
		numberOfChannels,
		sampleRate,
		samplesPerFrame,
	} = parseMp3PacketHeader(iterator);

	const cbrMp3Info = state.mp3.getMp3BitrateInfo();
	if (cbrMp3Info && cbrMp3Info.type === 'constant') {
		if (bitrateInKbit !== cbrMp3Info.bitrateInKbit) {
			throw new Error(
				`Bitrate mismatch at offset ${initialOffset}: ${bitrateInKbit} !== ${cbrMp3Info.bitrateInKbit}`,
			);
		}
	}

	const offsetNow = iterator.counter.getOffset();
	iterator.counter.decrement(offsetNow - initialOffset);
	const data = iterator.getSlice(frameLength);

	if (state.callbacks.tracks.getTracks().length === 0) {
		const info: Mp3Info = {
			layer,
			mpegVersion,
			sampleRate,
		};
		const asText = new TextDecoder().decode(data);
		if (asText.includes('VBRI')) {
			throw new Error(

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Re-encode the MP3 with a consistent bitrate or with a proper Xing/VBR header so the parser recognizes it as VBR.
Use `ffmpeg` to normalize: `ffmpeg -i input.mp3 -codec:a libmp3lame -b:a 192k output.mp3` for CBR or `-qscale:a` for VBR with header.
If the file is user-supplied, validate it with `ffprobe` to check for inconsistent bitrates.
Report the file at remotion.dev/report if it appears to be a standard MP3 that should parse.

Example fix

# re-encode as proper CBR
ffmpeg -i input.mp3 -codec:a libmp3lame -b:a 192k -map_metadata 0 output.mp3

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check bitrate consistency with ffprobe
// ffprobe -show_frames -select_streams a input.mp3 | grep pkt_size
// If frame sizes vary significantly without a Xing header, re-encode.

Try / catch

try {
  await parseMedia({src, fields: {durationInSeconds: true}});
} catch (e) {
  if (e instanceof Error && e.message.startsWith('Bitrate mismatch')) {
    console.error('The MP3 has inconsistent bitrates. Re-encode as CBR or add a Xing header.');
  }
  throw e;
}

Prevention

Re-encode MP3 files with consistent bitrate: ffmpeg -i input -b:a 192k output.mp3.
For VBR files, ensure a Xing header is present so the parser detects VBR mode.
Avoid concatenating MP3 files with different bitrates.
Validate with ffprobe that the bitrate is consistent or the file has a VBR header.

When it happens

Trigger: After the first MP3 frame establishes a CBR bitrate in `state.mp3`, a later frame at `initialOffset` is parsed and `bitrateInKbit !== cbrMp3Info.bitrateInKbit`. This happens in `parse-mpeg-header.ts:37-43`.

Common situations: An MP3 file that was encoded as VBR but lacks a Xing/VBRI header, so the parser initially assumed CBR. Files that were concatenated from multiple MP3s with different bitrates. Corrupt frame headers with an incorrect bitrate index. Files where the bit reservoir or encoder switched bitrates without a VBR tag.

Related errors

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