Repair a corrupt voice-recorder recording

A WAV file is a RIFF container: it opens with the ASCII bytes RIFF at offset 0, a 32-bit little-endian size at offset 4, and the form type WAVE at offset 8. After that come chunks, each a 4-byte tag plus a 32-bit size. The two that matter are fmt  (note the trailing space — it is a four-character tag) and data. The fmt  chunk is where the recorder records how to interpret the samples: a 16-bit audio format code (1 = linear PCM), the channel count, the sample rate in Hz, the byte rate, the block align, and the bits per sample. Read those and you know exactly how to decode the bytes; lose them and the raw PCM is just anonymous numbers. The data chunk is the audio itself: its 4-byte tag, a 32-bit length, then the interleaved samples.

The catch is that both the top-level RIFF size and the data chunk length are written last. While recording, the device does not yet know how long the take will be, so it streams samples to the card and back-patches those two size fields when you stop. Recorders that save MP3 instead write a stream of self-contained MPEG audio frames, each announced by an 11-bit frame sync — the byte 0xFF followed by a byte whose top three bits are set (0xFFE…) — often preceded by an ID3v2 tag. Either way, the payload lands on the card frame by frame or sample by sample; only the framing that ties it together is finished at the very end.

Because the size fields are patched at Stop, the interruptions that corrupt a recording all cluster at the moment the file should be closed:

The battery died mid-recording. The samples up to that instant are on the card, but the RIFF size at offset 4 and the data length are left at their placeholder — frequently 0, or a stale value from when the file was pre-allocated. A player trusts the length field, reads zero (or a wildly wrong number) bytes of audio, and reports 0:00 or "corrupt".

The card was removed or the recorder reset during write. This truncates the file: the data chunk still declares the full length the recorder intended, but the file on disk is shorter, so the declared size is larger than the bytes actually present. Media players either refuse the file or play to the end of real data and then error.

An MP3 take was never finalized. The frame chain is intact but a truncated or corrupt ID3 tag, or junk at the head, makes the decoder lose the first 0xFF 0xEx sync — so the recording is there but the player can't find where it starts. For variable-bitrate files, the Xing/Info header that stores the total frame count may be missing, so the seek bar and duration read wrong even once it plays.

In every one of these cases the audio samples themselves were already committed to storage. What did not survive is a handful of size fields and framing bytes — which is precisely the repairable case. What can never come back is audio from after the interruption: those samples were never written.

For a WAV, the repair is a header rebuild that runs as pure TypeScript in your tab. It first scans for the fmt  tag and reads the format straight from it: the audio-format code, channel count, sample rate and bits per sample. If those core parameters are all sane (none is zero) it recomputes the two derived fields the header needs — blockAlign = channels × (bitsPerSample ÷ 8) and byteRate = sampleRate × blockAlign — so it never has to trust the possibly-garbage values on disk. Then it locates the data tag and compares the length it declares against how many bytes are actually present. When the declared size is larger than what remains, it flags the file truncated and keeps every byte that survived; when there is no data header at all, it treats everything after fmt  as PCM. Finally it trims the sample data down to a whole number of frames (dropping any pcm.length % blockAlign tail bytes) and writes a clean, canonical 44-byte WAV header — RIFF, correct size, WAVE, a 16-byte fmt  chunk, then data with the true length — in front of the recovered samples. Because the PCM is copied verbatim, there is no decode and no re-encode: the audio is bit-for-bit what you recorded.

The tool tells you what it did through a short report: a damageClass of header (just the sizes were wrong — a clean success), truncated-data or no-data-header (a partial, where the tail was missing), and the recovered sample rate, channel count, bits per sample and PCM byte count so you can sanity-check the result. An MP3 recording is handled by the sibling MP3 path instead: it strips a broken leading ID3 tag and any junk, resynchronises on the first genuine frame — accepting a candidate only when the frame length it computes lands exactly on another valid sync, which rejects false hits inside the audio — and copies the surviving frames back out losslessly. None of this touches the network: you can open the browser's Network tab and confirm 0 bytes of the recording are sent.

A header rebuild can only reach audio that reached the card. If the fmt  chunk itself is gone, the tool fails honestly rather than guessing — without the format code, channel count, sample rate and bit depth there is no way to know whether the bytes are 16-bit stereo at 48 kHz or 24-bit mono at 96 kHz, and inventing those numbers would produce noise. A file under 44 bytes (smaller than a single valid header) or one that trims to zero whole sample frames is reported as unrecoverable for the same reason: there is nothing decodable inside.

It also cannot recover what a failing card physically overwrote or returned as zeros — if the interruption left the audio region blank, those samples are not on the disk and no header fixes them; recover the raw bytes at the storage level first, then repair the file. Encrypted or DRM-wrapped recordings (some enterprise dictation and meeting devices wrap files with a key) aren't plain PCM or MPEG audio, so there is no header to rebuild without the key. And where an MP3 region had to be dropped, a short gap or click can remain at that spot — the repair keeps the good frames but does not synthesize the missing milliseconds. What you reliably get back is every sample and every frame that was written, in a container a player will open.