To check the result after you use audio effects online, open Audio Effects Online, apply a single effect with an amount between 0% and 100%, and read the channel count, sample rate, input and output frame counts, output peak, and exact WAV byte size that the page displays on completion. The tool decodes one browser-supported file inside your current tab through the Web Audio API, runs exactly one disclosed operation on every decoded frame, and surfaces a small inspection panel so you can confirm the arithmetic before downloading a new PCM16 WAV file. Nothing is uploaded, nothing is stored against your name, and the file you originally selected stays untouched on your device. Because every step runs locally, you can re-run, slide the amount, or swap effects and immediately see how the reported numbers move. The reliable contract is narrow: decode one supported file, apply the exact disclosed operation to every frame, preserve the complete calculated tail within budget, encode a standards-based PCM16 WAV, and state clearly what the lightweight effect does not claim to emulate.
What the page tells you after a run
Once processing finishes, the page renders a short set of inspection values rather than a waveform preview or a hidden score. You will see the channel count reported as an integer between 1 and 8, the sample rate reported in hertz inside the 8,000 to 192,000 Hz window, the input frame count and the output frame count reported as separate integers, the output peak reported as a signed decimal between -1.0 and +1.0, and the exact WAV byte size of the new file. These are not estimates or marketing numbers — they are the same values the encoder used to write the file, surfaced so you can compare input versus output and decide whether the operation did what you expected.
The input frame count reflects how many AudioBuffer frames the browser decoded. The output frame count reflects how many frames the selected effect produced. For reverse, fade in, fade out, and normalization, those two numbers match. For echo and reverb, the output frame count is larger, because the tool allocates the complete calculated tail before processing so the last delayed reflection is never cut off. If the file and effect would have produced more than 30 million channel samples in total, no file is created and the page simply reports that the budget was exceeded.
This matches the broader local approach described in using audio effects online without uploading a file, where the inspection values come from your own browser rather than from a remote server.
Inspect the output in your browser
The fastest way to confirm a result is to follow the same local workflow the tool already documents, then read the inspection panel before clicking download.
- Choose one browser-decodable audio file no larger than 50 MiB. Common filenames such as MP3, WAV, M4A, AAC, Ogg, WebM, and FLAC are accepted, but actual codec support varies by browser and operating system.
- Pick exactly one effect from echo, lightweight reverb, reverse, fade in, fade out, or normalization. The tool applies only one transformation per run.
- Set a whole-number amount from 0% through 100%. Lower amounts scale the effect linearly; 0% leaves the file effectively unchanged for blend-style operations.
- Apply the effect locally. The page decodes your file with the Web Audio implementation in your current tab, runs the deterministic operation on every frame, and clips finite samples to the legal -1 through +1 range before quantization.
- Read the inspection panel: channel count, sample rate, input frame count, output frame count, output peak, and exact WAV byte size. Use these numbers to compare against your expectation.
- Play the result inline if your browser offers playback, or download the new PCM16 WAV immediately and audition it in your usual player.
- Keep the untouched original on disk so you can compare, re-run with a different amount, or revert at any time.
The full file flow that ends in a downloadable WAV is documented in applying audio effects online locally and downloading a WAV; the inspection panel is the verification step that sits between "apply" and "download".
How to read the numbers you see
A few of the values on the inspection panel come from formal definitions and are worth pinning down once. The table below lists the values the tool guarantees so you know what you are reading.
| Reported value | Definition |
|---|---|
| Channel count | 1 to 8 equal-length channels, validated before processing |
| Sample rate | 8,000 Hz to 192,000 Hz, preserved from the decoded input |
| Effect amount | Integer 0 to 100, scales the chosen operation linearly |
| Echo delay | 200 ms; at 100% each input sample is retained and a half-strength copy is added two tenths of a second later |
| Reverb taps | Copies added at 29.7, 37.1, and 41.1 ms with disclosed weights of 0.50, 0.35, and 0.25 multiplied by the selected amount |
| Normalization target | Sample peak scaled toward 0.95; not LUFS, perceived loudness, or true peak |
| Output byte size | Interleaved little-endian PCM16 RIFF/WAVE, two bytes per mono frame and four bytes per stereo frame |
| Frame budgets | Input and output each capped at 30,000,000 channel samples |
The WAV block alignment used to compute the byte size follows Microsoft's PCM definition of channels multiplied by bits per sample divided by eight, which yields the two-bytes-per-mono-frame and four-bytes-per-stereo-frame values shown above (see the Microsoft WAVEFORMATEX structure). The AudioBuffer length itself is defined in sample frames by the W3C Web Audio specification, which is the same contract the browser uses when decoding your file.
Limits that can prevent a result from appearing
Verification only matters if a result exists, and the page is explicit about when it will not create one. If the chosen file does not decode in your browser, the tool produces no result — a recognized filename such as .flac or .m4a does not guarantee that the encoded profile inside the file will decode, because real codec support depends on the browser and operating system you are using. If the decoded input exceeds the channel, sample-rate, duration, or channel-sample budget, the run is rejected before any effect runs.
A second, less obvious limit applies to the output. Echo and reverb add frames to the calculated tail. That means an input which fits inside the 30 million channel-sample budget can still produce an output that does not. In that case nothing is truncated and no file is created — the page simply does not give you a download link, so "checking the result" amounts to seeing the absence of one and choosing a shorter file or a lighter effect. The 50 MiB encoded-file cap and the 30 million channel-sample budgets are the only hard ceilings; everything else is determined by your browser's Web Audio implementation.
Changing the file, the effect, or the amount slider invalidates any older work on the page. Stale jobs cannot replace newer state, decode contexts are closed after use, and temporary object URLs are revoked on replacement and unmount. If you switch effects partway through, treat the previous download as the only artifact you have.
Check between runs when chaining effects
Because the tool applies only one effect per run, "checking the result" naturally becomes a loop rather than a single step. The cleanest pattern is to download the new PCM16 WAV, audition it in your usual player, compare the output peak and frame counts against what you expected, and only then feed that WAV back into the same page as the next input. This is exactly the workflow the tool is designed for: each run produces a complete, deterministic, standards-based file that the browser can decode again on the next pass.
This loop is also the safest way to compensate for what the page does not measure. Normalization, for instance, scales toward a 0.95 sample peak rather than toward LUFS, perceived loudness, broadcast compliance, or true peak between samples, so if you need a louder master you must chain multiple runs and listen between them. Likewise, repeated lossy decode followed by PCM processing can reveal source artifacts, and repeated clipping or normalization can change the dynamics of a recording — both of which are reasons to keep an untouched original on disk and to verify the inspection panel after every run rather than only at the end.
For the same reason, treat strong echo and reverb settings as a sound-design draft, not as a finished product. The reverb is a lightweight three-tap reflection design and does not model room dimensions, frequency-dependent decay, stereo diffusion, damping, pre-delay, or convolution with a real impulse response. Strong settings can clip when dry and delayed samples overlap, which is why the encoder constrains floating samples to the -1 through +1 range before quantizing to signed sixteen-bit PCM — a step you can confirm in the inspection panel by watching the reported output peak move toward (but never exceed) those limits.