When an audio effect result looks wrong, the cause is almost always one of six measurable conditions — a too-high amount, an unexpected clip on the -1 to +1 sample range, a peak that did not move, a tail that exceeds the 30 million channel-sample output budget, a file that failed to decode, or an effect choice that does not match what the listener was expecting — and Audio Effects Online prints enough numbers on the page to tell you which one happened. The fix follows from the diagnosis: change the amount, change the effect, shorten the source, or build a chain of smaller passes instead of one heavy run. The tool is local, deterministic, and reports every input and output figure, so the wrong-looking result is rarely a mystery once the numbers are read. Information about the operation, including its limits and the absence of any upload step, helps the user verify each of those six conditions: the amount was a whole number between zero and one hundred, the clipping fell inside the legal floating range so no samples escaped quantization, the peak moved by the predicted amount after normalization, the tail fit inside the thirty million channel-sample output budget for echo and reverb, the source file decoded through the browser Web Audio implementation before any effect was attempted, and the effect chosen matched what the audio actually needed rather than what the user assumed a generic audio effects tool might do. With those checks in place, recovery becomes mechanical.
Most readers who land on this page have already pressed Apply once and felt that the result was louder, quieter, thinner, or simply unlike the sound they had in their head. The recovery path is the same in every case: re-open the original, inspect the numbers, pick a smaller amount or a different effect, and re-run. None of that requires uploading the file, and none of it modifies the source.
What "Looks Wrong" Usually Means After an Audio Effect
When a result "looks wrong," the user usually means one of six concrete situations: the output sounds distorted, the output is suddenly quieter than the original, a tail is missing or cut off, the effect was applied to the wrong file, the wrong effect was chosen, or no file was produced at all. Each of these has a different cause and a different first fix. Knowing which one applies matters because the recovery steps differ — lowering the amount is the right response to clipping, but it is the wrong response to a missing tail.
The narrower the gap between what you expected and what you heard, the more likely the fix is a small amount change rather than a tool switch. The wider the gap — for example, asking for a "studio room" reverb and getting a small early-reflection wash — the more likely the fix is to lower expectations about what a single lightweight effect can do and to use a chain of lighter passes instead of one heavy run. The tool does not hide what it actually does; it just does not pretend to be a convolution reverb, an impulse-response loader, or a hardware plate either.
Read the Numbers the Page Reports After You Apply
Audio Effects Online prints six numbers after it processes a file: channel count, sample rate, input frame count, output frame count, output peak, and the exact WAV byte size of the download. Those values are the fastest way to confirm what actually happened, and they line up with the W3C Web Audio specification's definition of decoded AudioBuffer length in sample frames (W3C Web Audio API). If the input frame count is lower than the output frame count, the tool added a tail (echo or reverb). If they are equal, the effect was sample-aligned (reverse blend, fade in or out, or normalization). If the output peak sits at or just below 0.95, normalization ran and capped the loudest sample. If the output peak is pinned at 1.000 but the result sounds clean, the audio hit the legal floating ceiling and was clipped to the -1 to +1 range before being written as sixteen-bit PCM, which is why the waveform stops cleanly at the edges.
A quick worked example for normalization: if the loudest absolute sample in the decoded buffer is 0.4 and the user picks the normalization effect, the scale factor is 0.95 divided by 0.4, which equals 2.375. Every decoded sample is then multiplied by 2.375, so a sample that was 0.3 becomes 0.7125, and a sample that was -0.2 becomes -0.475. After the multiplier, any sample above 1.0 or below -1.0 is clipped to the legal range, and the result is quantized to signed sixteen-bit PCM. If the user is auditing a run, comparing the pre-effect and post-effect peak tells them immediately whether the normalization did anything at all. Checking the result after each run is the step that turns a recovery cycle into a reliable habit.
Recover From a Result That Looks Wrong
- Re-open the original, untouched file. Do not re-run on the previous output, because echo, reverb, and normalization all change the dynamics and a second pass compounds that change.
- Note the channel count, sample rate, and input frame count from the page. Confirm the file actually decoded — if no numbers appeared, the file failed to decode and no result was created.
- Look at the output peak. If it is roughly the same as the input peak after a reverb or echo pass, the amount was too small to be audible; raise it. If it sits at 1.0 exactly, the result clipped; drop the amount and re-run.
- Compare input and output frame counts. For echo at 100 percent, the output should be roughly the input plus the echo delay in samples. If the output is shorter than that, the tail exceeded the 30 million channel-sample output budget and no file was created — shorten the source.
- For "wrong effect" cases, switch from reverb to echo, from reverse to fade, or from normalization to fade out, depending on the goal. The tool applies only one effect per run.
- Re-apply with a smaller amount, download the new PCM16 WAV, and inspect the same six numbers again. Repeat the cycle until the output matches the intent.
Match the Symptom to the Right Effect and Amount
| Symptom | Likely cause | First fix |
|---|---|---|
| Output is distorted or harsh | Dry and delayed samples overlap above 1.0 and clip to the ceiling | Lower the amount by 20 to 30 percent |
| Output is much quieter than the input | The amount was low, so added delayed copies were small while the dry signal was always retained | Raise the amount, or follow with normalization |
| Output is silent after normalization | The decoded source itself had no audible samples to scale | Verify the original with another player |
| Tail is missing or shorter than expected | The 30 million channel-sample output budget was exceeded; no file is created | Trim the source length before re-running |
| No file appeared at all | File over 50 MiB, unrecognised codec, or output budget exceeded | Smaller file, lighter effect, or shorter input |
| Reverb sounds metallic or thin | The reverb is a fixed three-tap reflection design, not a room or convolution reverb | Use a chain of smaller reverbs and a fade |
| Reverse sounds garbled or muddy | Reverse blend at high amount overlaps the original samples out of order | Drop the amount or use reverse alone at 100 percent |
The table covers the cases that appear most often. A clipped reverb is the single most common symptom, because dry and delayed samples overlap at the same moment and the legal sample ceiling is hit immediately; reducing the amount is the only safe fix, since the tool already clips finite samples to -1 through +1 before quantization. A "silent output" after normalization means the source itself was silent, because normalization scales to the loudest sample that actually exists and multiplies everything by the same factor. A tail shorter than expected for echo means the budget was hit, not that the effect was miscalculated, and the tool deliberately does not truncate to give you a partial file.
Limits That Make a Result Fail to Appear at All
Three explicit limits can stop the tool from producing any file, and each one shows up as "nothing happened" rather than as "wrong sound." A file larger than 50 MiB is rejected before decoding. A file whose name is recognised (MP3, WAV, M4A, AAC, Ogg, WebM, FLAC) but whose codec or profile the browser cannot decode produces no numbers on the page; a recognised filename is not a guarantee that a particular encoded file will decode, and if decoding fails the tool creates no result. A combination of input length plus echo or reverb tail that exceeds 30 million channel samples is also rejected without truncation — the tool will not silently cut the tail, because a truncated echo or reverb is harder to interpret than no file at all.
For every limit, the recovery is the same shape: shorten the source, pick a lighter effect, or lower the amount so the calculated output stays inside the budget. The page reports the budget only when it succeeds, so an empty result after pressing Apply is the signal that one of these three limits fired. Re-loading the file with the original codec often clarifies whether the failure was size or decode, because an unrecognised profile gives a different error path than a too-large file.
Build a Safe Chain Instead of Piling Effects On
Because Audio Effects Online applies exactly one transformation per run, the natural recovery workflow is a chain: download the result, inspect the reported numbers, then use that WAV as the next input. This is also the only safe way to combine normalization with reverb, or reverse with a fade, without losing headroom. Repeated lossy decode followed by PCM16 quantization can expose source artifacts from MP3 or AAC compression, and repeated clipping or normalization shifts the dynamics on each pass, so it pays to document a repeatable workflow that records the amount and effect used at every step (Audio Effects Online: document a repeatable workflow). When the chain is the point of the exercise, checking the result after each run is what keeps the chain from drifting.
Keep an untouched original at all times. The contract is explicit: only the new interleaved little-endian PCM16 RIFF/WAVE is exported, and the source codec, bitrate, tags, artwork, chapters, cue points, and loop markers are not preserved. Floating samples are quantized to signed sixteen-bit PCM, which is why a result that looks "pinned" at 1.000 is still a valid download — the clip happens before quantization. Audio Effects Online reports the same six numbers on every run, so a sequence of values gives a complete audit trail without uploading anything and without an account. If a recovery chain goes wrong, the original is the reset button.