A documented audio equalizer workflow records the exact inputs, settings, processed values, and output file produced by each EQ run, so the same adjustments can be reproduced, audited, or shared without guesswork. The point is to turn a one-off EQ session into a record that another person, or future you, can follow step by step without watching the original screen. A good documentation log names the source file, the three band values that were applied, the disclosed filter centers, the reported peaks, the safety scale, the sample rate, the frame count, and the saved filename. Because every value is numeric and the underlying math follows the W3C Audio EQ Cookbook peaking-biquad formulas, the log stays verifiable instead of being a vague recollection of "I added some bass." Treat the EQ tool itself as a fixed process with disclosed parameters: the same input plus the same band settings will produce the same output every time. Two log entries can be compared side by side, the difference between them identified, and the result decided before the project moves on.
What a Documented Equalizer Session Actually Contains
Documenting an EQ run is more than writing down a list of slider positions. Each session entry should let someone reconstruct what happened without watching you do it. That means recording four groups of facts: the input file properties, the equalizer controls, the numerical results reported by the tool, and the final download details.
Input properties include the source format (MP3, WAV, M4A, AAC, Ogg, WebM, or FLAC when the browser can decode the actual codec), the file size, and the original duration. Equalizer controls include the Bass, Mid, and Treble values in decibels, all of which must be whole numbers between -12 and +12 dB. Numerical results include the raw peak across every processed channel, the output peak after the safety scale, the safety scale itself when it was applied, the sample rate used for processing, and the total frame count. Download details include the output filename and the WAV byte length.
Writing these facts down turns the EQ run into a reproducible recipe. If a colleague asks "what did you do to that podcast clip?", you can hand them the log entry and they can repeat the exact processing without guessing. The same recipe format also makes it easier to compare two sessions and figure out which change actually moved the result.
The Equalizer You'll Be Documenting
The tool that fits this kind of documentation work is the Audio Equalizer, a browser-local three-band peaking equalizer with disclosed centers and a uniform safety scale. Because every parameter is published and integer-based, each run produces a log entry that is short, exact, and unambiguous. The tool does not upload audio, does not auto-tune, and does not hide its filter design behind a "magic" preset.
The Bass band is centered at 100 Hz, the Mid band at 1,000 Hz, and the Treble band at 10,000 Hz when the decoded sample rate is high enough. For lower sample rates, the Treble center is reduced to 45 percent of the sample rate so it stays below the Nyquist limit. Every band uses a Q value of 1 and the peaking-EQ biquad equations published in the W3C Audio EQ Cookbook. The three sections are cascaded in Bass, Mid, then Treble order. Setting all three controls to 0 dB produces a genuine flat path: the decoded channel samples are copied without running a nonzero filter section.
Knowing this matters for documentation because every number you write down has a fixed meaning. There is no adjustable Q, no hidden compressor, no automatic loudness target. What you set is what the math applies, and the reported numbers are the only output of that math. To understand what each band does in plain language before you document the steps, the three-band equalizer walkthrough covers the same 100 Hz, 1,000 Hz, and 10,000 Hz centers used by the tool.
The Three Bands Your Log Will Reference
Every documented EQ step eventually points back to one of the three band parameters below. Recording the centers and the gain range alongside each dB value prevents future confusion when a colleague reads your log months later and needs to know exactly what the slider touched.
| Band | Center Frequency | Gain Range | Q Value |
|---|---|---|---|
| Bass | 100 Hz | -12 to +12 dB (whole integers) | 1 |
| Mid | 1,000 Hz | -12 to +12 dB (whole integers) | 1 |
| Treble | 10,000 Hz, or 45% of the sample rate when low | -12 to +12 dB (whole integers) | 1 |
Because the dB range is integer-only, your log does not need to record fractional values. Because the Q is fixed at 1, you also do not need to record a quality factor or bandwidth. The two facts your log must always carry are the center (or the rule used to derive it) and the integer dB value that was applied.
Recording the Equalizer Workflow in Five Steps
- Choose one browser-decodable audio file within the 50 MiB and five-minute decoded limits, and write the filename, size, and duration into your log before any controls are touched.
- Set the Bass, Mid, and Treble controls to whole integer values between -12 and +12 dB, and record each value next to its band name using the centers from the table above.
- Apply the equalizer locally in your browser tab. Processing stays inside the current tab; no upload step exists, so your log should not record any upload field.
- Read the reported numbers before downloading: raw peak across all processed channels, output peak after scaling, the safety scale factor when it was applied, the decoded sample rate, and the total frame count.
- Preview the processed audio on the speakers or headphones that matter for the final decision, then save the new PCM16 WAV. Record the saved filename and the WAV byte length in the same log entry.
Each step produces one or more written facts, and the full sequence forms one row of a documentation table that can be reused across many sessions. When you can describe what you did in five numbered lines, the workflow is ready to share.
Limits and Output Properties to Note in Each Entry
A documented session is only useful if it also records what the tool refused to do. The equalizer rejects files over 50 MiB, decoded audio longer than five minutes, audio with more than eight channels, sample rates outside the 8,000 to 192,000 Hz range, and decodes that contain more than 30 million channel samples. Recording any rejection in your log is just as important as recording a successful run, because it prevents the same mistake from being repeated on the next attempt.
The output is a fresh uncompressed PCM16 WAV. The decoded audio is represented internally as a Web Audio AudioBuffer, and float samples are converted to signed 16-bit little-endian PCM and interleaved by frame. According to the WAV header structure described in Microsoft's WAVEFORMATEX reference, the file records the actual channel count, sample rate, byte rate, block alignment, bit depth, and complete data length. Original compression, bitrate, artwork, tags, chapters, loop markers, and container-specific metadata are not preserved. If your log needs to track source metadata, capture it before processing, because the WAV itself will not carry it.
Web Audio may also resample during decode, so the documented sample rate is the decoded rate, not necessarily the container rate claimed by the source file. Each channel keeps the same number of sample frames, and every accepted channel is filtered independently with identical settings. Strong boosts can push samples above digital full scale even when the input did not clip, which is why the tool measures the raw peak and, when needed, applies one uniform scale factor so the largest magnitude becomes 0.99 rather than chopping individual samples at the encoder.
When a Documented Three-Band EQ Is Not Enough
A clean three-band log is a strong baseline, but the documentation should also describe when to stop using it. The disclosed tool is not a graphic 10-band equalizer, a linear-phase mastering processor, or an automatic room correction system. It does not measure LUFS, RMS, replay gain, or any streaming-platform loudness target, and the safety scale is not loudness normalization.
Document a move to a full audio editor when the task requires precise center frequencies, adjustable Q, spectrum analysis, automation lanes, linear-phase processing, loudness metering, dithering controls, codec selection, or metadata preservation. The same log template still applies: input, controls, numerical results, output filename. Only the underlying processor changes.
Strong boosts can also emphasize noise, sibilance, rumble, or distortion that already existed in the source. A documented cut is often safer than stacking several boosts, and the log entry can record the safer choice so the same lesson is not relearned on every project. The numbers in your log are checks, not proof of a desirable mix. Listen on the speakers or headphones that matter, compare against the original at a similar perceived level, and avoid judging only from louder output.
Related reading: Compare Audio Speed Changer Approaches and Run It Locally.