Jetzt reparieren
- Datei ablegen
- Reparatur läuft lokal
- Ergebnis herunterladen
Ein WAV ist einer der einfachsten Audio-Container überhaupt, und genau deshalb kann ein Fehler von zwei oder vier Bytes in seinem Header eine ganze Aufnahme tot aussehen lassen. Die Datei ist eine RIFF-Hülle: die ASCII-Kennung RIFF, eine 4-Byte-Größe in Little-Endian, die Kennung WAVE und danach eine Reihe von Chunks — jeder mit einem 4-Byte-Namen, einer 4-Byte-Größe und einem Körper. Die beiden entscheidenden sind fmt (beachte das Leerzeichen am Ende), das die Abtastrate, die Kanalzahl und die Bittiefe angibt, und data, das die rohen PCM-Samples enthält. Ist die RIFF-Größe an Offset 4 oder die Größe des data-Chunks falsch — ein Rekorder, der abstürzte, bevor er sie anpasste, eine Übertragung, die das Ende abschnitt, eine Datei, die das 32-Bit-Größenlimit überschritt —, vertrauen die Player der kaputten Zahl und melden die Datei als beschädigt, während jedes Sample noch da liegt. Zieh das .wav oben herein, und das Werkzeug sucht in deinem Browser nach den echten Markierungen fmt und data, berechnet die Größen aus dem, was tatsächlich vorhanden ist, und schreibt einen sauberen, kanonischen Header um dein unangetastetes PCM herum zurück — ohne dass jemals etwas dein Gerät verlässt.
Warum ein WAV als beschädigt gilt, obwohl das PCM intakt ist
Ein kanonisches WAV beginnt mit einem 12-Byte-Prolog — der ASCII-Kennung RIFF, einer 32-Bit-Zahl in Little-Endian, die der gesamten Dateigröße minus 8 entsprechen soll, und der ASCII-Kennung WAVE — gefolgt von den Chunks. Jeder Chunk besteht aus einem 4-Byte-Namen, einer 4-Byte-Größe in Little-Endian und dann genau so vielen Bytes Körper. Der fmt -Chunk trägt einen 16-Byte-Körper: eine Format-Kennung an Offset 0 (1 = PCM, 3 = IEEE-Float, 0xFFFE = WAVE_FORMAT_EXTENSIBLE, 0x11 = IMA ADPCM), dann die Kanäle (Offset 2), die Abtastrate (Offset 4), die Byte-Rate (Offset 8), das Block-Align (Offset 12) und die Bits pro Sample (Offset 14). Der data-Chunk ist nur sein 8-Byte-Header, gefolgt von den verschachtelten Samples. Die gesamte „Karte" zu stundenlangem Audio sind diese paar Dutzend Bytes.
Diese Fragilität ist das ganze Problem. Ein Rekorder, der auf die Platte schreibt, kennt die endgültige Länge nicht, bis du auf Stopp drückst, also schreibt er einen Platzhalter in die RIFF-Größe (Offset 4) und die data-Größe — oft 0 oder 0xFFFFFFFF — und ersetzt die echten Werte als letzten Schritt, wenn er die Datei schließt. Beende die App hart, zieh den Strom, wirf die Karte aus oder bring das Betriebssystem vor diesem letzten Schritt zum Absturz, und das PCM ist vollständig geschrieben, aber die Größen behaupten weiterhin, die Datei sei leer. Die Player glauben dem Header: Windows Media Player wirft 0xC00D36C4, Audacitys libsndfile meldet File contains data in an unknown format oder lehnt sie als „keine WAV- oder AIFF-Datei" ab, und ffmpeg gibt Invalid data found when processing input aus, manchmal nach der Warnung RIFF size ... bigger than resulting file size.
Andere alltägliche Ursachen enden am selben Punkt. Eine Kopie oder Synchronisierung, die zu früh stoppte, schneidet den data-Körper ab, sodass seine deklarierte Größe die vorhandenen Bytes übersteigt. Eine Aufnahme, die über rund 4 GiB lief, lässt die 32-Bit-RIFF/data-Größenfelder überlaufen, sodass die Zähler umschlagen und das Ende unlesbar erscheint. Ein verirrter Metadaten-Chunk, der vor fmt geschrieben wurde, oder ein Byte-Order-Fehler kann einen naiven Parser von den echten Chunks abbringen. In jedem dieser Fälle sind die Samples intakt — was lügt, ist die Buchführung.
Wie der Browser RIFF/fmt/data neu aufbaut, ohne die Samples anzurühren
Die Reparatur ist ein struktureller Neuaufbau des Headers und läuft als reines TypeScript in deinem Tab. Sie liest die gesamte Datei (ein gültiges WAV braucht mindestens den 44-Byte-Minimal-Header) und sucht dann statt der RIFF-Größe an Offset 4 nach den literalen ASCII-Bytes fmt an einer beliebigen Stelle in der Datei. Das ist der entscheidende Schritt: Eine auf null gesetzte, mit Platzhalter versehene oder übergelaufene Master-Größe kann sie nicht aufhalten, weil sie dieses Feld nie liest, um sich zu orientieren. Aus dem fmt -Körper übernimmt sie nur die vier Werte, die sie wirklich braucht — die Format-Kennung, die Kanalzahl (Offset 2), die Abtastrate (Offset 4) und die Bits pro Sample (Offset 14). Sind die Kanäle, die Abtastrate oder die Bittiefe null, hält sie ehrlich mit einem bad-fmt-params-Ergebnis an, statt Rauschen auszugeben.
Anschließend berechnet sie die beiden abgeleiteten Felder selbst neu — das Block-Align als Kanäle × (Bits pro Sample ÷ 8) und die Byte-Rate als Abtastrate × Block-Align — sodass eine falsche Byte-Rate oder ein falsches Block-Align im ursprünglichen Header einfach verworfen und durch korrekte Arithmetik ersetzt wird. Als Nächstes sucht sie vorwärts nach der data-Kennung. Ist die deklarierte data-Größe größer als die tatsächlich vorhandenen Bytes (der Abschneide-Fall), behält sie alles, was übrig ist, und markiert das Ergebnis als truncated-data; gibt es überhaupt keinen data-Header, behandelt sie die Bytes direkt nach dem 16-Byte-fmt -Körper als PCM und markiert es als no-data-header. Das PCM wird dann auf eine ganze Anzahl von Sample-Frames zugeschnitten, damit ein halb geschriebener letzter Frame kein Knacken verursachen kann.
Zum Schluss schreibt sie einen frischen, kanonischen 44-Byte-Header: RIFF mit einer korrigierten Größe von 36 + PCM-Länge, WAVE, einen sauberen 16-Byte-fmt -Chunk mit dem wiederhergestellten Format/den Kanälen/der Rate/den Bits sowie der neu berechneten Byte-Rate und dem Block-Align, dann data mit der echten PCM-Länge, und deine Samples werden unverändert ab Byte 44 kopiert. Es gibt kein Resampling und keine Neukodierung — die Audio-Bytes sind exakt die, die du aufgenommen hast, also ist die Reparatur verlustfrei. Das Werkzeug meldet die Abtastrate, die Kanalzahl, die Bittiefe und die Anzahl der wiederhergestellten PCM-Bytes sowie eine Schadensklasse von header (ein glatter Erfolg) oder truncated-data/no-data-header (ein Teilergebnis). Nichts davon berührt das Netzwerk — du kannst den Netzwerk-Tab öffnen und bestätigen, dass 0 Bytes der Datei gesendet werden.
Wann sie nicht neu aufbauen kann — und was sie verwirft
Diese Reparatur erreicht, was überlebt; sie kann kein Format erfinden, das sie nicht mehr lesen kann. Sie hängt davon ab, dass der fmt -Chunk vorhanden ist: Fehlt fmt oder ist er überschrieben, hält das Werkzeug mit einem no-fmt-Ergebnis an, statt zu raten, denn Abtastrate, Kanalzahl und Bittiefe lassen sich nicht aus rohem PCM ableiten — eine falsche Vermutung würde das Audio mit der falschen Geschwindigkeit oder als verschachtelten Müll abspielen. Anders als bei einem Video ohne moov-Atom wird hier keine gesunde Referenzdatei verwendet, also ist das Format weg, wenn der Format-Header weg ist. Eine Datei unter 44 Bytes liefert too-small zurück, und bleibt beim Zuschneiden auf ganze Frames nichts übrig, liefert sie no-pcm.
Da sie einen kanonischen 44-Byte-Header ausgibt, werden Zusatz-Chunks verworfen: Broadcast-Metadaten (bext/BWF-Timecode und Ursprungsinformationen), Cue-Punkte (cue ), Playlist- und Label-Chunks, LIST/INFO-Tags (Interpret, Kommentar), der fact-Chunk und die WAVE_FORMAT_EXTENSIBLE-Erweiterung (das cbSize, die gültigen Bits, die Kanalmaske und die Subformat-GUID). Das Audio kommt zurück; diese Metadaten nicht. Der Neuaufbau setzt außerdem Sample-Frames konstanter Größe voraus, sodass komprimiertes WAV, dessen Block-Align nicht einfach Kanäle × Bytes pro Sample ist — IMA/MS ADPCM, GSM 6.10 —, durch das neu berechnete Block-Align falsch beschrieben wird und sich womöglich nicht dekodieren lässt; das Werkzeug zielt auf PCM und IEEE-Float, wo diese Arithmetik exakt ist.
Zwei weitere ehrliche Grenzen. Die Ausgabe ist ein standardmäßiges 32-Bit-RIFF, sodass PCM jenseits von etwa 4 GiB nicht im Größenfeld ausgedrückt werden kann — diese Größenordnung braucht RF64/BW64 oder Sonys Wave64 (.w64), einen anderen Container. Und Samples, die ein defektes Laufwerk oder eine defekte Karte physisch mit Nullen oder Stille überschrieben hat, liegen nicht auf dem Datenträger, um wiederhergestellt zu werden; hole zuerst die Roh-Bytes auf Speicherebene zurück und baue dann den Header neu auf. Was du zuverlässig zurückbekommst, ist das intakte PCM, korrekt beschrieben, in einer Datei, die ein Player auch wirklich öffnet.
Was sich reparieren lässt und was nicht
Kann repariert werden
- WAVs, bei denen ein Rekorder abstürzte, bevor er die endgültige RIFF/data-Größe anpasste (Platzhalter 0 oder 0xFFFFFFFF), sodass die Datei mit null Länge oder als beschädigt angezeigt wird
- Ein data-Chunk, dessen deklarierte Größe die vorhandenen Bytes übersteigt (abgeschnittene Kopie/Synchronisierung) — behält jedes Sample, das es auf die Platte geschafft hat
- Eine falsche oder unsinnige Byte-Rate / ein falsches Block-Align im fmt-Chunk — beide werden aus Kanälen, Abtastrate und Bittiefe neu berechnet
- Ein fehlender 'data'-Chunk-Header — die Bytes nach dem fmt-Körper werden als PCM behandelt und neu verpackt
- Eine Müll-RIFF-Master-Größe an Offset 4 — vollständig ignoriert, weil das Werkzeug stattdessen nach den Markierungen 'fmt ' und 'data' sucht
- Standard-Integer-PCM- und IEEE-Float-WAVs (mono oder mehrkanalig), verlustfrei neu aufgebaut mit Byte für Byte kopierten Samples
Kann nicht repariert werden
- Dateien ohne 'fmt '-Chunk — Abtastrate, Kanäle und Bittiefe lassen sich nicht aus rohem PCM erraten, also hält es an (gemeldet als 'no-fmt')
- Komprimiertes WAV (IMA/MS ADPCM, GSM), dessen Block-Align nicht Kanäle × Bytes pro Sample ist — der neu berechnete Header würde es falsch beschreiben
- Broadcast/BWF (bext), Cue-Punkte, LIST/INFO-Tags und die EXTENSIBLE-fmt-Erweiterung — verworfen, wenn der kanonische 44-Byte-Header geschrieben wird
- PCM größer als ~4 GiB — eine 32-Bit-RIFF-Größe kann es nicht fassen; das braucht RF64/BW64 oder Wave64 (.w64)
- Samples, die ein defektes Laufwerk oder eine defekte Karte mit Nullen/Stille überschrieben hat — stelle zuerst die Roh-Bytes auf Speicherebene wieder her, dann baue neu auf
- Eine Datei unter 44 Bytes oder eine, in der kein ganzer Sample-Frame überlebt (gemeldet als 'too-small' oder 'no-pcm')
Wenn eine Reparatur fehlschlägt, sagen wir dir warum (fehlende Daten gegenüber beschädigter Struktur), und für eine fehlgeschlagene Reparatur wird dir nie etwas berechnet.