Audio Repair and Restoration

Corrupted WAV file? How to recover the audio before you give up

By StudioRescue Editorial

Published September 25, 2026

This is one of the few audio problems where the honest answer is genuinely encouraging. A recorder that lost power mid-take, a laptop that died during a session, a card pulled out too early: all of these tend to leave a file whose contents are fine and whose description of itself is broken. Media players are strict about that description, so they refuse a file they could actually play.

What follows is the order to try things in, what each symptom usually means, and a straight account of the cases where the audio really is gone. Nothing here costs money.

Why a WAV file breaks this way

A WAV file is a RIFF file, and RIFF is built out of blocks called chunks. Microsoft’s own RIFF documentation describes each chunk as an identifier, a size, and then the data, and says the size field “gives the size of the valid data in the chunk.” The broadcast WAV standard published by the EBU describes the same building block as an identification field and a size field wrapped around the contents. The actual audio lives in a chunk called data.

Here is the part that matters. A recorder cannot know how long the recording will be until you stop it, so it writes a placeholder size at the start and goes back to correct it when you press stop. If the power fails, the card is yanked, or the software crashes before that moment, the recording never gets its real size written down. The file on the card may be 400 MB of perfectly good audio behind a header that claims it is zero seconds long.

Before you try anything: do no harm

Try the recorder first, it may fix its own file

If a standalone field recorder or handheld recorder made the file, put the card back in that device and play the file there before touching a computer. Several recorders write their audio in safe intervals and can repair an interrupted file themselves on playback. The operation manual for Zoom’s H4essential, for example, states that “files are automatically saved at regular intervals during recording” and that a file affected by an interruption can be restored to normal by playing it back on the recorder.

This takes thirty seconds, needs no software, and when it works you get a properly finished file with nothing to repair. Check your own recorder’s manual for the equivalent wording rather than assuming, because this behaviour is not universal.

Match the symptom to the cause

Fix 1: tell FFmpeg to ignore the broken length

FFmpeg is free, available for Windows, macOS and Linux from ffmpeg.org, and its WAV reader has an option written for exactly this situation. The official documentation describes ignore_length as ignoring the size of the data chunk and continuing to “keep reading until the end of the file,” and notes it may be useful for broken or partial files whose header was not updated properly. That is a precise description of a recording that died before it was stopped.

In a terminal, in the folder holding your copy:

ffmpeg -ignore_length 1 -i broken.wav -c copy recovered.wav

The -ignore_length 1 sits before -i on purpose. FFmpeg applies options to the next file named, so an option placed before the input applies to reading that input. Put it after and it does nothing useful.

-c copy asks FFmpeg to pass the audio through untouched, which keeps the recovery lossless. If it refuses to copy, remove -c copy and let it re-encode, then check the result. A successful run usually reports the full duration you expected rather than the second or two the broken header claimed.

Fix 2: import the samples directly with Audacity

If you would rather not use a command line, or FFmpeg produced nothing usable, Audacity has a documented route for this. Its manual describes File > Import > Raw Data as an attempt to import uncompressed audio that may have no header at all, or that “might have incorrect headers or be otherwise partially corrupted.” It reads the bytes and lets you tell it what they are, which is precisely what a broken header stops other software doing.

You have to supply four things, and you will probably guess at least one of them wrong on the first attempt. That is normal, and the wrong guesses are recognisable:

• Encoding and bit depth. Most recorders write 16-bit or 24-bit signed PCM. A wrong choice here is the usual cause of loud, continuous static.
• Byte order. WAV files are little-endian. Choosing big-endian by mistake also produces harsh static rather than a subtle problem, so it is easy to rule out.
• Channels. Importing a mono file as stereo, or the reverse, gives a fast, stuttering, half-speed-sounding result with the audio split oddly between sides.
• Sample rate. Getting this wrong leaves the audio perfectly intelligible but at the wrong speed and pitch, which is the easiest error to hear and the easiest to correct afterwards.

Work through them in that order. Static first, then stutter, then speed. Once the audio plays cleanly, export it as a normal WAV and you have a working file again.

Then finish the file normally

A recovered file is an ordinary file. Bring it into REAPER and treat the session like any other, and if the recovered take needs cleanup, deal with that separately: digital glitches and ticks at a join are covered in how to fix crackle and clicks in a recording, and the delivery settings for a finished file are in how to export audio from REAPER. If what you actually lost was the REAPER session rather than the audio, that is a separate job covered in how to recover a crashed or lost REAPER project.

What this will not fix

Header repair is powerful precisely because it is narrow. It cannot do any of the following, and no tool can.

• It will not create audio that was never written to the card. A genuinely 0 KB file contains nothing. The recording may still be recoverable from the card by undelete or forensic recovery software, because the data can survive without a directory entry, but that is disk recovery rather than audio repair, and it is a different discipline with a real chance of failure.
• It will not rebuild the middle of a file that was physically lost. If a card failed partway, you get the part that was written. Recover it, trim the damage, and work with what survived.
• It will not decode a proprietary or encrypted recorder format. Some devices write working files in their own container. Those need the manufacturer’s own software or firmware routine, not a generic WAV repair.
• It will not help if the card has been recorded over. Once new audio occupies those blocks, the old recording is gone. This is why the first instruction in this article is to stop using the card.
• It will not improve the recording itself. A recovered file has exactly the noise, clipping, room and mic problems it had when it was captured. Recovery gives you the take back, not a better take.
• It cannot promise success. Some files really are unrecoverable. If the size is realistic, your odds are good. If it is empty, they are poor, and it is better to hear that now than after paying for three tools.

Make the next one survive

1. Stop the recording before you power down. Pressing stop is the moment the true length is written. Powering off mid-take is the single most common cause of this whole problem.
2. Feed the recorder properly. Fresh batteries, or external power for anything long. Interview-length recordings are where power failures actually happen.
3. Record a second copy. A phone voice memo running alongside the good recorder has rescued an enormous number of interviews. It sounds worse than the file you lost and infinitely better than nothing.
4. Prefer several shorter files. If your recorder can split by time or you can stop and restart between segments, a failure then costs one segment instead of the whole session.
5. Copy the card before you edit. Get the files onto a computer and back them up before the first edit, and keep the card untouched until that copy is verified.