MP3 lässt sich nicht abspielen

Ein MP3 ist kein einzelner Block — es ist eine Folge kleiner MPEG-Audio-Frames, jeder etwa 26 ms Klang. Jeder Frame beginnt mit einem 4-Byte-Header: Byte 0 ist 0xFF, und die obersten drei Bits von Byte 1 vervollständigen die 11-bit-Frame-Sync (0xFFE…). Der Rest des Headers verpackt die MPEG-Version (MPEG-1, MPEG-2 oder MPEG-2.5), den Layer (fast immer Layer III), einen Bitraten-Index, einen Abtastraten-Index und ein Padding-Bit. Aus Bitrate und Abtastrate berechnet der Decoder die Byte-Länge des Frames — für Layer III ist das floor(144 × bitrate ÷ sample_rate) + padding — und nutzt sie, um direkt zur nächsten Sync zu springen. Bestimmte Bit-Kombinationen sind laut Norm unzulässig: eine reservierte Version, ein reservierter Layer, ein Bitraten-Index von 0 (free) oder 15 (bad) oder ein Abtastraten-Index von 3. Landet der Decoder auf einem Header, der zu einer davon dekodiert, ist das keine echte Frame-Grenze und der Stream bleibt hängen.

Zwei Dinge bringen diesen Sprung am häufigsten zum Entgleisen. Das erste ist ein kaputter ID3v2-Tag ganz am Anfang. Ein ID3v2-Tag beginnt mit den ASCII-Bytes ID3 (0x49 0x44 0x33), einem 10-Byte-Header und einer syncsafe 28-bit-Größe, die auf vier Bytes verteilt ist (jedes steuert nur seine unteren 7 Bits bei). Ist diese Größe falsch — oft weil ein übergroßes oder abgeschnittenes eingebettetes Albumcover den Tag beschädigt hat — springt der Player entweder über den Anfang des echten Audios hinweg oder versucht, den Tag als Klang zu dekodieren. Das zweite ist führender Müll: ein unvollständiger Download, eine versehentlich unter dem Namen .mp3 gespeicherte HTTP-Fehlerseite oder ein Byte-Order-Fehler, der Bytes vor die erste Sync stellt. Dateien ganz ohne ID3-Tag sind nur eine „nackte MPEG-Audio-Frame-Sync" — ein schwaches Signal, das manche Player gar nicht erst als MP3 erkennen.

Darum sind die Symptome so unterschiedlich. ffmpeg meldet Failed to find two consecutive MPEG audio frames oder Header missing; mpg123 gibt Illegal Audio-MPEG-Header 0x00000000 aus und warnt vor einem Frankenstein stream, wenn sich die Frame-Parameter mitten in der Datei ändern; ein <audio>-Element im Browser wirft DEMUXER_ERROR_COULD_NOT_OPEN. Alle beschreiben dasselbe: Die Frame-Kette ist unterbrochen, nicht die Musik verschwunden.

Die Reparatur ist eine strukturelle Neusynchronisation und läuft als reines TypeScript in deinem Tab. Zuerst misst sie einen etwaigen führenden ID3v2-Tag anhand jener syncsafe-Größe (plus einem 10-Byte-Footer, wenn das Footer-Flag gesetzt ist) und geht darüber hinweg. Dann sucht sie in der Datei vorwärts nach einem Byte-Muster, das sich als echter Header parsen lässt — 0xFF, die 0xE0-Sync-Bits, eine nicht reservierte Version und Layer sowie ein Bitraten- und ein Abtastraten-Index, die beide im gültigen Bereich liegen. Entscheidend ist: Ein einzelnes 0xFF 0xEx kann zufällig innerhalb der Audiodaten vorkommen, deshalb wird ein Kandidat nur akzeptiert, wenn die berechnete Frame-Länge den Leser exakt auf eine weitere gültige Sync setzt (oder auf das Dateiende). Diese Bestätigung über zwei Frames ist es, die Fehltreffer verwirft, statt Rauschen in die Ausgabe zu schreiben.

Von dort aus geht sie Frame für Frame weiter und kopiert jeden bestätigten Frame unverändert in die Ausgabe. Bytes vor dem ersten guten Frame werden als führender Müll gezählt und verworfen; ein Abschnitt in der Mitte, der sich nicht parsen lässt, wird als Region beschädigter Frames behandelt und übersprungen, damit der Leser die Kette an der nächsten sauberen Sync wieder aufnehmen kann. Da jeder behaltene Frame Byte für Byte kopiert wird, gibt es keine Neukodierung und keinen Qualitätsverlust — das überlebende Audio ist genau das, was du aufgenommen hast. Das Werkzeug meldet, was es getan hat: gefundene gegenüber behaltenen Frames, wie viele Bytes führenden Mülls es entfernt hat, und eine Schadensklasse von clean (ein glatter Erfolg) oder resynced (ein Teilergebnis, bei dem Müll oder beschädigte Frames verworfen wurden).

Zwei Details lohnt es sich zu kennen. Viele MP3s tragen einen Xing/Info- (oder VBRI-) Header im ersten Frame; er speichert die Gesamtzahl der Frames und eine Sprungtabelle für Dateien mit variabler Bitrate. Dieser Header ist selbst ein gültiger MPEG-Frame, daher bewahrt die Neusynchronisation ihn, wenn er überlebt — und wenn nicht, greifen Player darauf zurück, die Länge aus der Bitrate zu schätzen (ffmpeg warnt wörtlich Estimating duration from bitrate, this may be inaccurate). Ein abschließender ID3v1-Tag — die festen 128 Bytes, die mit TAG am Dateiende beginnen — ist kein Frame und wird daher einfach vom Ende abgeschnitten, statt den Decoder zu verwirren. Nichts davon berührt das Netzwerk: Du kannst den Netzwerk-Tab öffnen und bestätigen, dass 0 Bytes der Datei gesendet werden.

Die Neusynchronisation hilft nur, wenn irgendwo in der Datei echte MPEG-Frames überleben. Findet der Suchlauf keine dekodierbaren Frames, hält das Werkzeug an und sagt es ehrlich (ein no-frames-Ergebnis), statt dir eine leere Datei zu übergeben, die vorgibt zu funktionieren. Dieser Ausgang bedeutet meist, dass die Bytes überhaupt kein MPEG-Audio sind: eine in .mp3 umbenannte AAC/.m4a-, WMA- oder Opus-Datei oder eine gespeicherte Webseite oder ein Download-Fragment mit Audio-Endung. Es gibt keine 0xFFE-Frame-Header, an denen man einrasten könnte, und keine Neusynchronisation kann sie erfinden.

Sie kann auch kein Audio wiederherstellen, das von einem defekten Laufwerk oder einer beschädigten Karte überschrieben oder als Nullen zurückgegeben wurde — diese Frames liegen nicht auf dem Datenträger, also stelle zuerst die Roh-Bytes auf Speicherebene wieder her und repariere dann die Datei. DRM-geschützte Titel (Apples altes .m4p oder geschütztes AAC) sind kein MP3 und brauchen ihre Schlüssel zum Dekodieren; dieses Werkzeug rührt das nicht an. Und dort, wo eine beschädigte Region verworfen werden musste, kann an dieser Stelle eine kurze Lücke oder ein Knacken bleiben — die Reparatur kopiert die guten Frames verlustfrei, synthetisiert aber die fehlenden Millisekunden nicht. Was du zuverlässig zurückbekommst, ist jeder Frame, der intakt war, in Reihenfolge, in einem Container, den ein Player wirklich öffnet.