To troubleshoot a problem when you use reverse audio, start by identifying where the workflow breaks: the file picker, the Web Audio decoder, the local reversal, or the WAV encoder. Most issues fall into four buckets — a file that the browser cannot decode, an input that exceeds one of the published limits, a result that sounds different from what you expected, and a download that will not open elsewhere. The Reverse Audio tool on Lizely reports a specific message for limit violations and decode failures, so the fastest path is to read that message, match it to the limit it describes, and adjust the source file before retrying. Because decoding, reversal, and encoding happen in the current browser tab, no server is going to recover a rejected file for you; the fix has to come from your side. This guide walks through each common failure, explains the exact message you will see, and shows the small set of changes that resolve it without installing extra software.
Why Reverse Audio Might Not Behave as Expected
Reverse Audio runs entirely in the current browser tab using the Web Audio API. The file is read into an ArrayBuffer, decoded into raw channel samples, reversed channel by channel, and then re-encoded as a fresh PCM16 WAV. There is no upload step, no remote conversion, and no FFmpeg-style helper in the background. That local-only design has real benefits — your source bytes never leave the page — but it also means the tool is constrained by what the browser can decode, the memory available to the tab, and the limits the tool enforces before processing starts.
When something goes wrong, the cause is almost always one of the following: a container that holds a codec your browser cannot decode, a file that decodes successfully but exceeds a numerical limit, a reversal that worked but produced a file that sounds strange because the original had silence at the start or odd markers in the middle, or a download that opens in the browser preview but not in another program. Treating the symptom as a clue rather than a generic error is the first step in any successful round of reverse audio troubleshooting.
Common Decode and Format Problems
The file picker accepts common audio MIME types — MP3, WAV, M4A, AAC, Ogg, and WebM — but actual playback depends on the codec the browser can read. A familiar extension is not a guarantee, because a container can hold a codec the current browser does not support. When Web Audio cannot decode the bytes, the tool reports a decode error rather than silently producing a wrong file. According to the MDN reference for BaseAudioContext.decodeAudioData, decoding may fail for compressed data the host browser cannot parse, even if the file extension is on an accepted list.
Two specific situations come up often. The first is a file recorded on a phone that saved an unusual AAC profile or an M4A wrapper with a non-standard atom. The second is an Ogg or WebM file encoded with a variant the operating system codec pack does not provide. In both cases, the picker accepts the file because the MIME type matches, but the decoder rejects the bytes. The fix is to re-export the source from a known-good tool — a desktop editor, the recorder's own export menu, or a converter — and retry with a freshly written file. If the second file decodes, the original was the problem, not the reversal.
File Limits That Trigger Specific Error Messages
Reverse Audio enforces a short, explicit set of limits, and each one produces a message that points at the rule that was broken. Knowing the exact numbers helps you decide whether to trim, resample, or convert before retrying. The channel-sample budget — the number of decoded frames multiplied by the number of channels — is the limit people most often miss, because a compressed file can look small while decoding into a very large array.
| Limit | Accepted value |
|---|---|
| Compressed input file size | Up to 50 MB |
| Decoded duration | 5 minutes or shorter |
| Channel count | 1 to 8 channels |
| Sample rate | 8,000 to 192,000 Hz |
| Channel samples (frames × channels) | No more than 30,000,000 |
When a file is rejected, the tool shows a specific message and does not partially process the input. Selecting another file or retrying also clears the previous download first, so a stale success cannot be mistaken for a new result after an error. If your source is near a boundary — a 49 MB MP3 that decodes to a six-minute file, for example — the right move is to trim the source in an audio cutter first, then run the reversal on the shorter clip.
How to Troubleshoot a Problem When You Use Reverse Audio
Work through these steps in order. The first match is usually the cause, and the suggested change resolves it without disturbing the rest of your workflow.
- Read the exact error message. The tool reports a specific phrase for each limit and for decode failure. Match the message to the limit table above before changing anything else.
- Open the original preview. If the built-in preview plays the source file correctly, the browser can decode the bytes and the problem is downstream. If the preview does not play, the file itself is the issue.
- Confirm the file is a supported format and is under 50 MB. Re-export from a desktop editor or recorder if the extension is on the accepted list but decoding still fails.
- Check the decoded duration, channel count, and sample rate. Reverse Audio preserves the original sample rate and channel count when those values fit the limits, so a quick read of the on-screen numbers tells you whether the source is too long, too wide, or too dense.
- Try a short test clip. Cut a five-second slice from the source, run the reversal on the slice, and confirm the result plays backward as expected. If the slice works, scale the workflow back up gradually.
- Listen to the start and end of the result. A successful reversal moves every event to its mirror position measured backward from the end. If the start and end of the download sound like the end and start of the original, the tool is working correctly and your expectation needs an adjustment.
- Open the downloaded WAV in the editor or player where it will be used. A clean preview in the browser does not guarantee every older device supports the same channel layout or high sample rate, so test the file in its real destination before assuming success.
For a deeper look at the verification half of the workflow, the guide on how to check the result after you use reverse audio pairs well with the steps above.
Checking the Output After a Reverse Operation
Confirmation matters as much as the reversal itself, because reversed audio can sound correct in one player and wrong in another. The on-screen duration, channel count, and sample rate come straight from the decoded buffer, so they are the most reliable values to compare against the source. File size is also informative: a freshly encoded PCM16 WAV is larger than a compressed source, and a noticeably smaller-than-expected result is a clue that the reversal did not finish or that the browser used a different code path than usual.
Listen to the very first and very last frames of the download. The reversal preserves decoded duration, sample rate, and channel count, so the file should be the same length as the original. What changes is the position of every event — the last sample of the source becomes the first sample of the output, and silence at the end of the source becomes silence at the start of the output. If the result is the right length but sounds empty, the source likely had a long silent tail, and trimming that tail before reversing is the cleaner fix.
One more thing worth checking: the channel layout. Stereo inputs stay stereo, with the left and right channels reversed independently and then written back in correct interleaved frame order. The reversal does not swap left and right, so if you hear the right channel playing the left channel's content, the problem is downstream of the tool — usually a player that has a stereo swap mode turned on. Turn that off, reopen the file, and the channels should sit where you expect.
When to Move to an Audio Editor Instead
Reverse Audio is built for one transformation — reversing decoded samples in every channel and writing a fresh PCM16 WAV — and it deliberately does not install helpers, normalize loudness, change pitch, stretch time, repair clipping, or preserve source metadata. Album art, tags, chapters, loop markers, encoder settings, and container-specific fields are not copied into the download, because the output is a new file, not a re-wrap of the original. These limits are by design, and they keep the tool fast, local, and predictable.
If your task also calls for fades, trimming, codec selection, metadata preservation, or mastering controls, the right next step is a full audio editor. Use Reverse Audio to generate the reversed WAV, then open that file in the editor and apply the additional processing on top. Treating the local tool as a single-purpose stage in a larger pipeline — rather than a replacement for an editor — is the workflow that holds up across the most projects.
If you're weighing options, How Do I Troubleshoot a Problem When I Use an Audio Equalizer covers this in detail.