MP3 won't play

An MP3 is not one blob — it is a sequence of small MPEG audio frames, each about 26 ms of sound. Every frame opens with a 4-byte header: byte 0 is 0xFF, and the top three bits of byte 1 complete the 11-bit frame sync (0xFFE…). The rest of the header packs the MPEG version (MPEG-1, MPEG-2, or MPEG-2.5), the layer (almost always Layer III), a bitrate index, a sample-rate index, and a padding bit. From the bitrate and sample rate the decoder computes the frame's byte length — for Layer III that is floor(144 × bitrate ÷ sample_rate) + padding — and uses it to hop straight to the next sync. Certain bit combinations are illegal by spec: a reserved version, a reserved layer, a bitrate index of 0 (free) or 15 (bad), or a sample-rate index of 3. If the header the decoder lands on decodes to one of those, it is not a real frame boundary and the stream stalls.

Two things most often derail that hop. The first is a broken ID3v2 tag at the very front. An ID3v2 tag begins with the ASCII bytes ID3 (0x49 0x44 0x33), a 10-byte header, and a syncsafe 28-bit size spread across four bytes (each contributing only its low 7 bits). If that size is wrong — often because oversized or truncated embedded album art corrupted the tag — the player either seeks past the start of the real audio or tries to decode the tag as sound. The second is leading garbage: a partial download, an HTTP error page accidentally saved with an .mp3 name, or a byte-order glitch that prepends bytes before the first sync. Files with no ID3 tag at all are only a "bare MPEG audio frame sync" — a weak signal some players won't recognise as an MP3 to begin with.

That is why the symptoms are so varied. ffmpeg reports Failed to find two consecutive MPEG audio frames or Header missing; mpg123 prints Illegal Audio-MPEG-Header 0x00000000 and warns about a Frankenstein stream when the frame parameters change mid-file; a browser <audio> element throws DEMUXER_ERROR_COULD_NOT_OPEN. All of them are describing the same thing: the frame chain is broken, not that the music is gone.

The repair is a structural resync, and it runs as pure TypeScript in your tab. First it measures any leading ID3v2 tag from that syncsafe size (plus a 10-byte footer when the footer flag is set) and steps past it. Then it scans forward for a byte pattern that parses as a real header — 0xFF, the 0xE0 sync bits, a non-reserved version and layer, and a bitrate and sample-rate index that are both in range. Crucially, a lone 0xFF 0xEx can occur by chance inside audio data, so a candidate is only accepted when the frame length it computes lands the reader exactly on another valid sync (or on the end of the file). This two-frame confirmation is what rejects false positives instead of writing noise into the output.

From there it walks frame to frame, copying each confirmed frame verbatim into the output. Bytes before the first good frame are counted as leading garbage and dropped; a stretch that fails to parse in the middle is treated as a corrupt frame region and skipped so the reader can pick the chain back up at the next clean sync. Because every kept frame is copied byte-for-byte, there is no re-encoding and no quality loss — the surviving audio is exactly what you recorded. The tool reports what it did: frames found versus frames kept, how many leading garbage bytes it removed, and a damage class of clean (a straight success) or resynced (a partial, where junk or corrupt frames were dropped).

Two details are worth knowing. Many MP3s carry a Xing/Info (or VBRI) header inside the first frame; it stores the total frame count and a seek table for variable-bitrate files. That header is itself a valid MPEG frame, so resync preserves it when it survives — and when it doesn't, players fall back to estimating length from the bitrate (ffmpeg literally warns Estimating duration from bitrate, this may be inaccurate). A trailing ID3v1 tag — the fixed 128 bytes starting with TAG at the end of the file — is not a frame, so it is simply dropped off the tail rather than confusing the decoder. None of this touches the network: you can open the Network tab and confirm 0 bytes of the file are sent.

Resync only helps when real MPEG frames survive somewhere in the file. If the scan finds zero decodable frames, the tool stops and says so honestly (a no-frames result) rather than handing you an empty file that pretends to work. That outcome usually means the bytes are not MPEG audio at all: an AAC/.m4a, WMA, or Opus file renamed to .mp3, or a saved web page or download stub with an audio extension. There are no 0xFFE frame headers to lock onto, and no resync can invent them.

It also cannot recover audio that was physically overwritten or returned as zeros by a failing drive or a bad card — those frames are not on the disk, so recover the raw bytes at the storage level first, then repair the file. DRM-protected tracks (Apple's old .m4p or protected AAC) aren't MP3 and need their keys to decode; this tool won't touch that. And where a corrupt region had to be dropped, a short gap or click can remain at that spot — the repair copies the good frames losslessly but does not synthesize the missing milliseconds. What you reliably get back is every frame that was intact, in order, in a container a player will actually open.