Private interrupted-recording recovery

WAV Header Inspector & Crash Repair

Inspect RIFF/WAV, BWF, RF64, or BW64 files left with zero, stale, or impossible size fields after a recorder or application stopped unexpectedly. Review every proposed byte change and download a new header-repaired copy without modifying the original audio or metadata.

Local file input

Open one damaged recording

No file selected.

One file up to 256 MiB is copied into this browser tab. Audio samples are not decoded, played, uploaded, normalized, or transcoded.

The sample is a valid 48 kHz, stereo, 24-bit BWF whose RIFF and data lengths were deliberately zeroed.

Choose one audio file or load the teaching sample.

Keep the original and audition the copy end to end. Correct size fields cannot restore overwritten, missing, clipped, encrypted, interleaved incorrectly, or otherwise damaged sample data. A structurally readable file is not proof that the recording is complete or sounds correct.

The recording, metadata, recovery plan, and repaired copy stay in this browser tab. Nothing is uploaded by ToolQuill.

What can be repaired safely

The repairer follows the physical pre-data chunk chain, requires a complete uncompressed PCM or IEEE-float fmt chunk, locates the first data header, and checks sample-frame alignment. For RIFF it can rewrite the root size and 32-bit data size. For RF64 and BW64 it can restore the root/data sentinels plus the 64-bit ds64 RIFF size, data size, and sample count. A fresh structural inspection is run against the generated copy before its download is enabled.

Why data-to-EOF needs confirmation

If the declared data size leads to a complete chain of trailing chunks, those chunks are preserved and excluded from audio. If the length is zero, too large, or ends inside bytes that are not a complete chunk chain, the physical file alone cannot prove where intended audio stops. The tool therefore requires you to confirm that data is final, and it still refuses ambiguous padding or a remainder that is not divisible into complete sample frames.

Metadata preservation

The output is a byte-for-byte copy except for the exact integer offsets in the patch table. BEXT, iXML, LIST/INFO, cue points, vendor chunks, audio payload, and recognized trailing chunks are not rewritten. Formula-safe CSV and JSON reports preserve the original findings, assumptions, and before/after values for review.

Repair boundary

This is not a general audio reconstruction or raw-import tool. It does not invent a missing RIFF/WAVE, fmt , data, or ds64 structure; accept a broken pre-data chunk chain; repair compressed codecs; guess sample rate, channels, bit depth, byte order, or data offset; concatenate fragments; add missing pad bytes; or recover deleted sectors. For those cases, work from a copy with the recorder vendor or a data-recovery specialist.

Frequently asked questions

Why is the download disabled?

The page either found no size change, encountered a structural blocker, or needs the explicit data-to-EOF confirmation. Read the evidence and blocker table rather than treating the checkbox as a generic override.

Does the repaired file replace my upload?

No. Browser code cannot overwrite the selected file. Download creates a separately named -repaired.wav copy and leaves the original untouched.

Why are mono 8-bit files sometimes ambiguous?

A final zero byte can be either an audio sample or the pad after an odd-sized chunk. When both interpretations satisfy alignment, the tool refuses to choose.

Authoritative references

Microsoft’s RIFF overview defines the root size, chunk size, and word-padding rules used here. EBU Tech 3306 defines RF64 and its 64-bit ds64 sizes, while ITU-R BS.2088 specifies BW64. EBU Tech 3285 defines Broadcast Wave metadata that the repair copies without rewriting.

Batch-audit BWF/RF64 files · Audit a CUE sheet and audio assets · Browse audio tools