MP3 Shows the Wrong Duration or Seeks Badly: VBR Headers and Repair

Diagnosing the Wrong Duration or Broken Seeking

A file that plays correctly from start to finish but displays a false duration and jumps to random positions when you scrub the timeline almost always has a missing or damaged variable bitrate (VBR) navigation header. The audio frames themselves are intact; the table of contents is gone.

Why VBR Files Need a Separate Header

Constant bitrate (CBR) MP3s encode every frame at the same size, so a player can calculate total time from file length and locate any frame by simple arithmetic. VBR encodes allocate fewer bits to simple passages and more to complex ones. Frame sizes vary unpredictably, making that calculation impossible without an index.

That index is stored in a metadata block placed immediately after the first MPEG audio frame. Two formats exist:

• Xing header: Introduced by the Xing encoder, now the de facto standard. Identified by the ASCII bytes 58 69 6E 67 ("Xing") or 49 6E 66 6F ("Info") at a fixed offset after the first frame sync word. Contains total frame count, file size in bytes, and an optional seek table (TOC) with 100 byte-offset markers for approximate seeking.
• VBRI header: Introduced by Fraunhofer for its proprietary encoder. Identified by 56 42 52 49 ("VBRI"). Structurally similar but incompatible with Xing parsers.

The Library of Congress FDD000012 specification notes that both headers are optional extensions to the MPEG audio frame, not part of the core ISO standard. When a tool strips or corrupts this block—through a bad tag edit, a truncated download, or a misconfigured transcoder—the player falls back to CBR assumptions. It divides total file size by a guessed average bitrate and builds a timeline that does not correspond to the actual audio.

Reference: LOC FDD000012, "Block structure – Xing / Info header"

Observable Symptoms

• Duration mismatch across software: Windows File Explorer, macOS Finder, and mobile media scanners all read the header. If the reported length differs from what you hear during linear playback, the header value is wrong or absent.
• Seek targets land in silence or a different track: Clicking the 50% mark in VLC, iTunes, or a car stereo causes the player to estimate the byte offset for that position. Without a valid TOC, it guesses and jumps to an arbitrary frame boundary. The audio at that point may be mid-note, silent, or inside a different song if the file is a concatenation.
• Linear playback finishes at the real end: The decoder processes frames sequentially. It stops when it runs out of valid sync words, not when the header says it should. The actual duration is the sum of decoded frames.
• Hex inspection shows missing signature: Skip any ID3v2 tag (starts with 49 44 33). The first audio frame begins with an MPEG sync word: FF followed by a byte where bits 5–7 are 111 (typically FB, F3, FA, or F2). In a valid VBR file, the next 4 bytes after the side information will be 58 69 6E 67, 49 6E 66 6F, or 56 42 52 49. If you see another sync word without one of those signatures, the header is absent.

Confirming the Header State

1. Query reported duration with ffprobe:

   ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1:nokey=1 file.mp3
   

   Compare the output to the actual playback time. A discrepancy larger than a few seconds indicates a header problem.

2. Check for Xing/VBRI signature directly: Use a hex editor (HxD on Windows, xxd on Linux/macOS) or a command-line tool:

   xxd -l 2048 file.mp3 | grep -E "58 69 6E 67|56 42 52 49"
   

   No output means no header was found in the first 2 KB after any tags.

3. Use mp3check (Linux/macOS):

   mp3check --vbr file.mp3
   

   Reports "Xing header found" or "No VBR header." The mp3info -x command prints the header contents if present.

Rebuilding the Header Without Re-encoding

You can inject a correct Xing header while copying all audio frames unchanged. This preserves the original bitrate, quality, and encoder decisions.

Command:

ffmpeg -i broken.mp3 -c copy -write_xing 1 repaired.mp3

-c copy passes every audio frame through without decoding. -write_xing 1 forces FFmpeg to scan the entire file, count the frames, compute byte offsets, and write a new Xing header with a full TOC. The output file is typically a few hundred bytes larger than the input.

Verification: Run the ffprobe duration check on repaired.mp3. The reported value should now match the real playback length. Seek through the file in a media player to confirm the timeline behaves correctly.

Explicit limitations:

• FFmpeg writes only Xing headers. It cannot produce a VBRI header. This is irrelevant for all modern software and hardware players, which parse Xing as the universal VBR header. Only extremely old or specialized embedded systems that exclusively recognize VBRI will ignore the repair.
• The command fails if the file has structural corruption beyond a missing header—truncated frames, broken sync words mid-stream, or a damaged ID3v2 tag that prevents FFmpeg from locating the first audio frame. In those cases, FFmpeg will emit errors about invalid data or incomplete frames.
• If the file is a concatenation of two different MP3 streams, the generated header will describe only the frames FFmpeg can parse as a continuous sequence. Seeking into the second segment may still produce artifacts or silence because the underlying bitstream properties (sample rate, layer, stereo mode) can change at the join point. No header repair can fix a bad splice.

When Re-encoding Is the Only Path

If the file is structurally damaged—truncated after an incomplete download, contains non-recoverable frame errors, or is a bad concatenation—header repair alone is insufficient.

Re-encode to CBR as a compatibility fallback:

ffmpeg -i broken.mp3 -b:a 192k -f mp3 cbr_output.mp3

This decodes the entire file and re-encodes it at a constant 192 kbps. The resulting file seeks correctly in every player because CBR duration derives from file size and bitrate. This is a lossy process. The encoder re-compresses already lossy data, introducing generation loss. Use it only when the original is unplayable or must work on a device that rejects VBR entirely.

Hard limit: Re-encoding does not recover audio that was already missing. If the source file is truncated, the output will be truncated. If the source contains a burst of static from a damaged frame, that static will be encoded into the new file. Header repair fixes navigation; it does not restore lost audio data.

What No Tool Can Recover

• Truncated files: If a 30-second file claims to be 3 minutes, the missing frames are gone. A rebuilt header will correctly report 30 seconds.
• Bad concatenations: If two MP3s were joined by raw byte copy, the first segment's Xing header describes only its own frames. Seeking past that boundary lands on a frame that may have a different sample rate or channel mode, causing decoder errors or silence. The only reliable fix is to decode both segments to lossless PCM, concatenate, and re-encode as a single VBR file—a full generation loss.
• Encrypted or DRM-wrapped files: Some legacy files use proprietary wrappers that embed the seek table outside the MP3 bitstream. Standard repair tools cannot access or rebuild these tables.

Using a Web-Based Repair Tool

If you cannot install FFmpeg and the file plays correctly from start to end but shows the wrong duration, a server-side tool that performs frame scanning and Xing header injection is a direct alternative. The process is identical to the -c copy -write_xing 1 command: the tool reads the audio frames, counts them, generates a correct header, and returns the repaired file. This is appropriate for a single broken file when a command line is unavailable.

Do not use a general-purpose converter for this task. Converting to MP3 again triggers a re-encode and degrades quality. Use the repair or "fix duration" function specifically.