How do I record what each effect actually did to my file?

Save the page's reported metrics — channel count, sample rate, input frame count, output frame count, output peak, and WAV byte size — alongside the effect name and the integer amount you chose. Those numbers are how you prove the operation ran as documented.

Can one run apply multiple effects at the same time?

No. The tool applies exactly one transformation per run. To combine effects, download the result, inspect it, and use that WAV as the input of a new run, repeating until your chain is complete.

What should I write down about my source file before running an effect?

Record the filename, file size on disk, the codec or container you suspect, and the channel count and sample rate the browser actually decoded. The decoded values are what the page prints, not what the filename implies.

How do I prove that normalization only adjusts peak rather than loudness?

Note that normalization finds the largest absolute decoded sample and scales the whole file toward a 0.95 peak. It does not measure LUFS, perceived loudness, dynamics, or true peak between samples, so two recordings normalized by the tool will not necessarily sound equally loud.

What happens if my chained run exceeds the output budget?

Echo or reverb tails may push the processed result past 30 million channel samples. In that case nothing is truncated, no WAV is created, and you have to shorten the input or reduce the effect before the tool will produce a download.

Does the downloaded WAV preserve the rest of my original file?

It preserves the processed channel samples and sample rate as a new PCM16 RIFF/WAVE file. Original compression, tags, artwork, chapters, cue points, loop markers, and other container metadata are not carried over.

Audio Effects Online: Document a Repeatable Workflow

Documenting the steps to use Audio Effects Online means writing down a four-part recipe — source file specification, single-effect choice, whole-number amount from 0 to 100, and the channel, sample-rate, frame, peak, and byte values reported after processing — because the tool applies exactly one deterministic transformation per run and produces a new PCM16 WAV in the browser. Because every effect is fixed in code, the same effect name and amount always produce the same numerical output, which makes a written record genuinely useful rather than approximate. The audio file itself stays on your computer throughout: decoding, sample manipulation, and WAV encoding all happen in the current browser tab, so your documentation does not need to describe any upload, sign-in, or account step. What you are really documenting is which of six bounded operations you selected, what integer you set on the amount slider, and which verifiable numbers the page reported when the run completed.

how do i document the steps i use to use audio effects online — Audio Effects Online: Document a Repeatable Workflow

What "Documenting Steps" Means for Audio Effects Online

For most online audio tools, "documenting steps" is shorthand for a screenshot tutorial. For Audio Effects Online, the steps are tight enough that prose is enough. Three inputs go in: one file, one effect, one integer amount. One output comes back: a PCM16 WAV plus a small block of metrics. A written record therefore has four slots:

Source file: filename, byte size on disk, and the codec or container the browser recognized.
Decoded shape: channel count and sample rate that the browser produced.
Operation: which of the six effects you chose and the exact whole-number amount.
Result metrics: input frame count, output frame count, output peak, and exact WAV byte size.

Because all processing is deterministic and the effect parameters are fixed in code, recording those four slots is enough to reconstruct any run on the same source file. There is no hidden state, no server-side render, and no AI transformation in between; the chosen operation is applied to every decoded frame in sequence and the result is encoded straight to a download. Saving those four slots turns the tool from a one-off experiment into a reproducible recipe you can revisit, hand to a collaborator, or paste into a tutorial.

If you are writing training notes, treat the page itself as the schema: any detail the tool exposes is fair game to document, and any detail it does not expose (such as LUFS, perceived loudness, or true peak) is not produced by this tool and should not be claimed in your notes.

The Six Effects and Their Fixed Parameters

Audio Effects Online exposes six effects, each with a single integer amount from 0 to 100. The amount blends or scales the chosen operation; at 0 the output equals the dry input, at 100 the operation runs at full disclosed strength. Documenting the effect means recording both the name and the number, because the same amount produces a different magnitude for each effect.

Effect	What the amount controls	Full-strength behavior
Echo	Scales a single delayed copy linearly	Each input sample is retained; a half-strength copy is added 200 ms after the original. The complete delayed tail is allocated before processing so the last echo is not cut off.
Lightweight reverb	Scales three early-reflection copies	Copies are added at 29.7 ms, 37.1 ms, and 41.1 ms with weights 0.50, 0.35, and 0.25 multiplied by the amount. Not a room, impulse response, or hardware emulation.
Reverse	Blends reversed frames into the dry signal	Frames are read in the opposite order and blended with the original according to amount.
Fade in	Linear envelope from start to end	Scales from the selected dry proportion at the beginning to full level at the end of the file.
Fade out	Linear envelope from start to end	Performs the inverse of fade in: full level at the start, scaled dry proportion at the end.
Normalization	Scale factor toward a target peak	Finds the largest absolute decoded sample and rescales the whole file so that peak equals 0.95. Silent input stays silent.

The reverb numbers above are product-defined and disclosed in the page itself; they are the values you should write down verbatim. If you want to document them more carefully, the Reverb Delay Times Explained: 29.7, 37.1, and 41.1 ms guide covers what those milliseconds represent and how they differ from a true room simulator.

File, Channel, and Sample-Rate Budgets to Record

Before you record any run, capture the limits that decide whether the tool will succeed at all. The encoded file must be browser-decodable and no larger than 50 MiB. The decoded shape must satisfy several disclosed budgets. The page reports channel count and sample rate after decoding, so your documentation should include whatever the page prints, not what you assume based on the filename.

The decoded shape must contain 1 to 8 equal-length channels, a sample rate between 8,000 Hz and 192,000 Hz, and no more than 30,000,000 channel samples total. Those values form the input budget. There is also an output budget of 30,000,000 channel samples that the processed result must respect; echo and reverb can pass the input budget yet fail the output budget because their tails add frames, in which case nothing is truncated and no file is created. The amount selector accepts only whole numbers from 0 through 100.

If any of those limits is violated, the tool produces no result. Documenting them up front lets future runs avoid the same rejection and turns your notes into a self-checking checklist. The W3C Web Audio specification defines how a decoded AudioBuffer reports its length in sample frames, which is the unit the page uses for its frame counters.

Record the Audio Effects Online Procedure

The procedure to document is short and unchanging. Once you have it written, every run follows the same skeleton and your notes only need to record the four slots from earlier.

Choose one browser-decodable audio file no larger than 50 MiB. Note the filename, byte size on disk, and the codec or container you suspect (MP3, WAV, M4A, AAC, Ogg, WebM, or FLAC). Remember that a recognized filename does not guarantee that a particular encoded file will decode; actual codec and profile support depends on the browser and operating system.
Select one of the six effects and set a whole-number amount from 0 to 100. Record the effect name exactly as shown on the page and the integer amount. If you choose reverb, note whether you are documenting the dry-and-wet blend or the dry-only level, because the amount scales the wet taps.
Run the effect locally and inspect the reported metrics. Audio Effects Online shows channel count, sample rate, input frame count, output frame count, output peak, and exact WAV byte size after processing. Copy these numbers into your notes; they are the proof the run actually completed.
Download the PCM16 WAV and keep the untouched original. The download is a new interleaved little-endian PCM16 RIFF/WAVE file. Original compression, tags, artwork, chapters, cue points, loop markers, and other container metadata are not preserved. The original file should be kept aside because repeated decode and lossy encode cycles can reveal source artifacts.

Metrics to Capture After Each Run

Open Audio Effects Online, run the tool, and write down everything the page prints. The page surfaces six values that together describe the exact shape of the output, so capturing them is the heart of the documentation.

Metric	Meaning	Why it is worth recording
Channel count	Number of equal-length channels in the decoded input	Confirms the file decoded with the layout you expected.
Sample rate	Frames per second in Hz	Shows the rate the browser actually used.
Input frames	Length of the decoded buffer in sample frames	Baseline for comparing against the output frame count.
Output frames	Length of the processed buffer in sample frames	Echo and reverb add frames; reverse, fades, and normalization preserve length.
Output peak	Largest absolute sample in the result, in the −1 to +1 range	Confirms clipping protection engaged; for normalization, the peak lands at 0.95 if the input had any non-silent sample.
WAV byte size	Exact size of the downloaded file	Provides a sanity check against the page's frame counts.

Microsoft documents PCM block alignment as channels multiplied by bits per sample divided by eight; at sixteen bits this produces two bytes per mono frame and four bytes per stereo frame. That formula is the basis for the WAV byte size the page reports, and dividing the reported byte count by the per-frame byte size should yield the output frame count on the same screen.

Documenting Effect Chains Across Multiple Runs

The tool applies only one effect per run. To build a chain such as "normalize, then add light echo, then fade out," you must download the result of the first run, inspect it, and use that WAV as the input to the second run, then repeat for the third. Each link in the chain is its own documented step. Treat every downloaded WAV as a new source file and record, for every link:

The input WAV you fed in, including its filename and the metrics reported on the previous run.
The effect name and amount you applied on this run.
The metrics reported by the page after this run.
Confirmation that the original untouched file is still preserved somewhere off to the side.

Two cautions belong in any chain documentation. First, because echo and reverb add frames, the output frame count grows at every run; if a chain link pushes past the 30,000,000 output budget, nothing is truncated and no file is created. Second, normalization rescales toward a 0.95 peak rather than measuring LUFS, perceived loudness, dynamics, or true peak. Repeated normalization across a chain can repeatedly scale low-level material toward 0.95 and change the dynamics of the file, so document the peaks at each stage if that matters for your notes.

Limits and Pitfalls Worth Writing in Your Notes

The narrowest possible documentation includes the boundaries the tool enforces, because every one of them changes whether the run completes. Record these explicitly so you do not have to rediscover them later.

Decoding can fail silently. If the browser cannot decode the encoded file, the tool creates no result and no metrics appear; a recognized filename does not guarantee that a particular encoded file will decode.
The output budget is a hard ceiling, not a soft one. Echo and reverb tails are allocated in full, but if the complete tail plus input exceeds 30 million channel samples, no file is produced and nothing is truncated.
Clipping protection is one-sided. Output samples are constrained to the −1 through +1 floating range before WAV quantization. Strong settings can still clip during processing; the constraint just prevents invalid PCM16 values from being written to the file.
State is invalidated by any new selection. Changing the file, effect, or amount invalidates older work. Decode contexts are closed, stale jobs cannot replace newer state, and temporary object URLs are revoked on replacement and unmount.
Lossy chains can reveal artifacts. Repeated decode and PCM processing may surface artifacts from the original encoder, especially across several echo or reverb passes.

With those notes attached to each run, your documentation becomes a self-checking record: the file spec explains the input, the effect and amount explain the operation, the metrics explain the result, and the limits explain why a particular combination of file, effect, and amount either succeeded or did not.