Eine beschädigte Voice-Recorder-Aufnahme reparieren

Eine WAV-Datei ist ein RIFF-Container: Sie beginnt mit den ASCII-Bytes RIFF am Offset 0, einer 32-Bit-Größe im Little-Endian-Format am Offset 4 und dem Formtyp WAVE am Offset 8. Danach folgen Chunks, jeder aus einem 4-Byte-Tag plus einer 32-Bit-Größe. Die beiden entscheidenden sind fmt  (mit dem angehängten Leerzeichen — es ist ein Vier-Zeichen-Tag) und data. Im fmt -Chunk hält der Recorder fest, wie die Samples zu interpretieren sind: einen 16-Bit-Code für das Audioformat (1 = lineares PCM), die Anzahl der Kanäle, die Abtastrate in Hz, die Byte-Rate, die Block-Ausrichtung (block align) und die Bits pro Sample. Liest man diese, weiß man genau, wie die Bytes zu dekodieren sind; verliert man sie, ist das rohe PCM nur eine Folge anonymer Zahlen. Der data-Chunk ist das Audio selbst: sein 4-Byte-Tag, eine 32-Bit-Länge und dann die verschachtelten (interleaved) Samples.

Der Haken ist, dass sowohl die übergeordnete RIFF-Größe als auch die Länge des data-Chunks zuletzt geschrieben werden. Während der Aufnahme weiß das Gerät noch nicht, wie lang die Aufnahme wird, also streamt es die Samples auf die Karte und trägt diese beiden Größenfelder erst beim Stoppen nachträglich ein. Recorder, die stattdessen MP3 speichern, schreiben einen Strom eigenständiger MPEG-Audio-Frames, jeder angekündigt durch eine 11-Bit-Frame-Sync — das Byte 0xFF, gefolgt von einem Byte, dessen oberste drei Bits gesetzt sind (0xFFE…) — oft eingeleitet von einem ID3v2-Tag. In beiden Fällen landet die Nutzlast Frame für Frame oder Sample für Sample auf der Karte; nur die Rahmenstruktur, die alles zusammenhält, wird ganz am Ende fertiggestellt.

Weil die Größenfelder erst beim Stoppen eingetragen werden, häufen sich alle Unterbrechungen, die eine Aufnahme beschädigen, genau in dem Moment, in dem die Datei geschlossen werden sollte:

Der Akku ging mitten in der Aufnahme leer. Die Samples bis zu diesem Augenblick liegen auf der Karte, aber die RIFF-Größe am Offset 4 und die data-Länge bleiben auf ihrem Platzhalter stehen — häufig 0 oder ein veralteter Wert aus der Zeit, als die Datei vorab reserviert wurde. Ein Player vertraut dem Längenfeld, liest null (oder eine völlig falsche Zahl) Audio-Bytes und meldet 0:00 oder "beschädigt".

Die Karte wurde entfernt oder der Recorder während des Schreibens zurückgesetzt. Das kürzt die Datei ab: Der data-Chunk deklariert weiterhin die volle Länge, die der Recorder vorsah, aber die Datei auf dem Datenträger ist kürzer, sodass die deklarierte Größe größer ist als die tatsächlich vorhandenen Bytes. Media-Player verweigern entweder die Datei oder spielen bis zum Ende der echten Daten und brechen dann mit einem Fehler ab.

Eine MP3-Aufnahme wurde nie finalisiert. Die Frame-Kette ist intakt, aber ein abgeschnittener oder beschädigter ID3-Tag oder Müll am Anfang lässt den Decoder die erste 0xFF 0xEx-Sync verlieren — die Aufnahme ist also da, aber der Player findet nicht, wo sie beginnt. Bei Dateien mit variabler Bitrate kann der Xing/Info-Header fehlen, der die Gesamtzahl der Frames speichert, sodass Fortschrittsleiste und Dauer falsch angezeigt werden, selbst wenn die Wiedergabe läuft.

In jedem dieser Fälle waren die Audio-Samples selbst bereits auf den Speicher geschrieben. Was nicht überlebt hat, ist eine Handvoll Größenfelder und Rahmen-Bytes — und genau das ist der reparierbare Fall. Was nie zurückkommen kann, ist Audio von nach der Unterbrechung: Diese Samples wurden nie geschrieben.

Bei einem WAV ist die Reparatur ein Neuaufbau des Headers, der als reines TypeScript in deinem Tab läuft. Zuerst sucht das Werkzeug nach dem fmt -Tag und liest das Format direkt daraus: den Audioformat-Code, die Kanalzahl, die Abtastrate und die Bits pro Sample. Sind diese Kernparameter allesamt plausibel (keiner ist null), berechnet es die beiden abgeleiteten Felder, die der Header braucht, neu — blockAlign = Kanäle × (bitsPerSample ÷ 8) und byteRate = Abtastrate × blockAlign — sodass es sich nie auf die womöglich verfälschten Werte auf dem Datenträger verlassen muss. Dann lokalisiert es das data-Tag und vergleicht die Länge, die es deklariert, mit der Anzahl der tatsächlich vorhandenen Bytes. Ist die deklarierte Größe größer als das, was übrig ist, markiert es die Datei als truncated (abgeschnitten) und behält jedes Byte, das überlebt hat; gibt es überhaupt keinen data-Header, behandelt es alles nach fmt  als PCM. Zum Schluss kürzt es die Sample-Daten auf eine ganze Zahl von Frames (verwirft dabei die pcm.length % blockAlign überzähligen Rest-Bytes) und schreibt einen sauberen, kanonischen 44-Byte-WAV-Header — RIFF, korrekte Größe, WAVE, einen 16-Byte-fmt -Chunk und dann data mit der wahren Länge — vor die wiederhergestellten Samples. Weil das PCM unverändert kopiert wird, gibt es keine Dekodierung und keine Neukodierung: Das Audio ist Bit für Bit genau das, was du aufgenommen hast.

Das Werkzeug teilt dir über einen kurzen Bericht mit, was es getan hat: eine damageClass von header (nur die Größen waren falsch — ein sauberer Erfolg), truncated-data oder no-data-header (ein Teilergebnis, bei dem das Ende fehlte) sowie die wiederhergestellte Abtastrate, Kanalzahl, Bits pro Sample und die Anzahl der PCM-Bytes, damit du das Ergebnis auf Plausibilität prüfen kannst. Eine MP3-Aufnahme übernimmt stattdessen der verwandte MP3-Pfad: Er entfernt einen kaputten führenden ID3-Tag und jeglichen Müll, synchronisiert sich neu auf den ersten echten Frame — und akzeptiert einen Kandidaten nur dann, wenn die berechnete Frame-Länge exakt auf einer weiteren gültigen Sync landet, was falsche Treffer innerhalb des Audios ausschließt — und kopiert die überlebenden Frames verlustfrei wieder heraus. Nichts davon berührt das Netzwerk: Du kannst den Netzwerk-Tab (Network) des Browsers öffnen und bestätigen, dass 0 Bytes der Aufnahme gesendet werden.

Ein Header-Neuaufbau erreicht nur Audio, das auf die Karte gelangt ist. Ist der fmt -Chunk selbst verschwunden, scheitert das Werkzeug ehrlich, statt zu raten — ohne den Formatcode, die Kanalzahl, die Abtastrate und die Bittiefe lässt sich nicht wissen, ob die Bytes 16-Bit-Stereo bei 48 kHz oder 24-Bit-Mono bei 96 kHz sind, und diese Zahlen zu erfinden würde Rauschen erzeugen. Eine Datei unter 44 Bytes (kleiner als ein einziger gültiger Header) oder eine, die nach dem Kürzen null ganze Sample-Frames übrig lässt, wird aus demselben Grund als nicht wiederherstellbar gemeldet: Es steckt nichts Dekodierbares darin.

Es kann auch nicht wiederherstellen, was eine defekte Karte physisch überschrieben oder als Nullen zurückgegeben hat — hat die Unterbrechung den Audiobereich leer gelassen, liegen diese Samples nicht auf dem Datenträger, und kein Header repariert sie; hol zuerst die rohen Bytes auf Speicherebene zurück und repariere dann die Datei. Verschlüsselte oder mit DRM umhüllte Aufnahmen (manche Diktier- und Meeting-Geräte im Unternehmensumfeld verpacken Dateien mit einem Schlüssel) sind kein reines PCM oder MPEG-Audio, also gibt es ohne den Schlüssel keinen Header, der sich neu aufbauen ließe. Und dort, wo ein MP3-Bereich verworfen werden musste, kann an dieser Stelle eine kurze Lücke oder ein Knacken bleiben — die Reparatur behält die guten Frames, synthetisiert aber nicht die fehlenden Millisekunden. Was du zuverlässig zurückbekommst, ist jedes Sample und jeder Frame, der geschrieben wurde, in einem Container, den ein Player öffnet.