How to Fix a Corrupted Audio File

Before touching anything, duplicate the corrupted file and work only on the copy. Recovery attempts, repair tools, and even some players can overwrite or further damage a fragile file, and if a drive is failing, every read risks losing more — so the original must be preserved untouched as your fallback. If the file lives on a USB stick, memory card, or drive showing signs of trouble (slow access, clicking, read errors), copy it off to healthy internal storage immediately, before doing any repair work, because a dying drive can render the file completely unreadable at any moment. Make several copies if the recording is irreplaceable. This single habit — never experiment on the only copy — is what separates a recoverable situation from a permanent loss, and it costs nothing but a few seconds. Everything that follows assumes you are operating on a duplicate, with the original safely set aside.

Different symptoms point to different damage, and the fix depends on which you have. File opens but sounds wrong (glitches, dropouts, sections of noise): partial data corruption — some audio is intact and recoverable. File shows the wrong duration or 0:00, or will not seek: header/metadata corruption — the descriptive information is damaged but the audio data underneath may be perfectly fine, which is the most recoverable case. File will not open at all: severe corruption, a truncated download, or a mismatched extension. File plays in one app but not another: often not corruption at all but a format/codec compatibility issue (try the format-not-supported fixes instead). The fastest diagnostic is to open the file in VLC, which tolerates damage better than any mainstream player: if VLC plays some or all of it, the audio data is at least partly intact and worth recovering; if even VLC produces nothing, the damage is severe and you will be salvaging fragments at best.

VLC is the first tool to reach for because it is the most forgiving player in existence — it skips past damaged sections and plays whatever valid audio it can find, where iTunes, Windows Media Player, or a phone's default player would simply refuse the file. Beyond playing damaged files, VLC can also re-save the recoverable audio into a clean file: use its Convert/Save feature (Media > Convert/Save) to transcode the damaged file to a fresh MP3 or WAV, which writes out the good data with a correct, intact header and drops the corrupted parts. This 'play it, then re-save it' approach fixes a large share of everyday corruption, especially header damage, because VLC reconstructs the output container from scratch. If VLC plays the file but the target app rejects it, converting through VLC to MP3 or WAV is frequently the entire fix. If VLC cannot play it at all, move on to FFmpeg and the format-specific repair tools.

FFmpeg is the most powerful recovery tool for anyone comfortable with a command line, because it reads audio streams that players give up on and can extract just the valid data. The basic move is to transcode the damaged file to a clean one: 'ffmpeg -i damaged.mp3 recovered.wav' — if FFmpeg can decode any of the audio stream, it writes the good portion into a fresh, correctly-structured WAV, discarding the broken parts. To salvage a truncated or partially-downloaded file without re-encoding, copy the intact stream directly: 'ffmpeg -i partial.mp3 -c copy recovered.mp3', which keeps the audio bit-for-bit up to the point of damage. Adding error-tolerance flags (such as -err_detect ignore_err) can push FFmpeg through glitches that would otherwise stop it. Because FFmpeg rebuilds headers and containers in the output, this process fixes most header corruption automatically as a side effect. It is the same engine AudioUtils runs in the browser, so simply converting a damaged file with an online converter often performs this exact recovery without any command line.

Audacity is the recovery tool of last resort for files that VLC and FFmpeg cannot open, thanks to its 'Import Raw Data' feature. Normal import may recover audio when other tools fail — try File > Import > Audio first, and if it works, immediately export to a brand-new file. When even that fails and you are convinced audio data exists in the file, Import Raw Data reads the file as headerless PCM: you manually specify an encoding (try 16-bit signed PCM), byte order, and channel count, and Audacity plays whatever it interprets. The result often includes noise and needs experimentation with the settings, but it can extract recognizable audio from a file whose header is completely destroyed — the digital equivalent of reading a book whose cover and index are gone but whose pages survive. Once you get intelligible sound, select the good portion and export it cleanly. Raw import will not fix a file that contains no valid audio data, but for header-obliterated recordings with intact samples, it is frequently the only thing that works.

Some formats have dedicated repairers that outperform general tools. MP3: because MP3 frames each carry their own header, the format is unusually resilient, and tools like MP3val and MP3 Diags scan a file, fix broken frame headers, remove garbage data, and rebuild the stream — often restoring an MP3 that would not play. WAV: a damaged RIFF header can be reconstructed if you know (or can guess) the sample rate, bit depth, and channel count, since the raw PCM samples themselves rarely corrupt; dedicated WAV-repair utilities and Audacity's raw import both handle this. FLAC: the reference 'flac' command-line tool verifies integrity with 'flac -t file.flac' (it will report exactly where corruption lies thanks to FLAC's built-in checksums) and can decode the recoverable audio with 'flac -d'. M4A/AAC: these MP4-based files are less forgiving of header damage, but FFmpeg and specialized MP4-repair tools that rebuild the container index (the 'moov' atom) can sometimes restore playback. Match the tool to the format and your odds improve considerably.

Interrupted downloads, aborted transfers, full drives, and crashed recording apps commonly leave truncated files — complete from the start up to the moment they were cut off. The good news is that the audio before the cutoff is usually perfect; the problem is that the header (which may claim a longer duration, or live at the end of the file for some formats) no longer matches. FFmpeg's stream-copy ('ffmpeg -i partial.mp3 -c copy out.mp3') often extracts the valid portion directly, and transcoding ('ffmpeg -i partial.file recovered.wav') rebuilds a correct header around whatever decodes. For WAV specifically, the RIFF header's size field can be edited to match the actual file size, after which the existing samples play correctly (just shorter than intended). A special case: MP4/M4A recordings interrupted mid-write can lose the index atom entirely and appear totally broken — 'untrunc' and similar tools rebuild that index using a healthy reference file recorded on the same device. The recovered audio will be shorter than planned, but a shorter intact recording beats a broken one.

Honesty matters here: not every corrupted file is recoverable, and knowing when to stop saves hours. If VLC, FFmpeg, and Audacity all produce nothing but silence or noise, the file likely contains no valid audio data — the bytes that held the sound are gone or overwritten, and no tool can reconstruct information that no longer exists. Heavily corrupted files may yield only fragments: a few seconds of recognizable audio amid garbage. Encryption or DRM can masquerade as corruption — a file that will not play anywhere and shows odd structure may be protected rather than damaged, which is a different (and usually unsolvable) problem. When repair fails, your best options are non-technical: re-download from the original source, restore from a backup, check whether the recording app kept an autosave or temp file, or ask whoever sent it for a fresh copy. For truly irreplaceable recordings with commercial value, professional data-recovery services can sometimes go further than consumer tools — but manage expectations, because 'gone' is sometimes genuinely gone.

For most people facing a corrupted audio file, a short sequence resolves it without any command line. First, copy the file so you are working safely. Second, try opening it in VLC — if it plays, use Convert/Save to write a clean MP3 or WAV, and you are likely done. Third, if VLC fails, run the file through an audio converter (browser-based AudioUtils or desktop FFmpeg): the act of decoding and re-encoding rebuilds the header and container and salvages the readable audio into a fresh file — this alone fixes a large share of everyday corruption, and AudioUtils does it locally in your browser with no upload. Fourth, for MP3s specifically, run MP3val; for FLACs, run flac -t. Fifth, if it is a truncated recording, try FFmpeg stream-copy or the format's index-repair tool. Only after all of that comes backup restoration or professional recovery. Working top to bottom, the majority of corrupted files are fixed at step two or three, in under a minute.

The best fix is never needing one, and audio corruption is largely preventable. Verify transfers by comparing file sizes (and ideally checksums) between source and destination before deleting the source — a mismatch means an incomplete copy. Prefer FLAC for anything important, because its built-in MD5 checksum lets you detect corruption years later with a single 'flac -t', catching silent bit rot while you still have a backup. Eject external drives properly through your operating system rather than yanking them, since removing a drive mid-write is a leading cause of corruption. Back up important recordings to multiple locations — a second drive and a cloud copy — so no single failure loses them. Watch for failing hardware: a drive that reads slowly, clicks, or throws errors is dying, and you should copy everything off it immediately. And do not fill drives to the last byte, since a full disk can truncate files being written. A few minutes of these habits prevents nearly all of the corruption that sends people looking for repair tools.