To document the steps you use to cut audio, build a small structured record for each cut rather than a free-form note: the source file name and codec container, the decoded sample rate, channel count, duration, and frame count that the page prints, the start and end times in seconds, the output file name and its size in bytes, and a one-line verification note. Audio Cutter is a practical anchor for this record because it follows a fixed three-step workflow, exposes the decoded technical fields before any cut happens, and produces a single, well-defined output: a freshly encoded PCM16 WAV file that does not preserve the source's compressed codec or metadata. Capturing those values turns a vague memory of "I trimmed the podcast intro" into a repeatable recipe that another person can rerun on the same source, and into an auditable log that explains, later, exactly what was kept and exactly what was written to disk.
The reader who searches "how do I document the steps I use to cut audio" is rarely looking for a screen recorder or a project-management template. They want a paper trail that explains, in plain language, exactly which file was loaded, exactly which seconds were kept, and exactly what was written to disk at the end. That paper trail needs three things: a stable sequence of actions, the technical numbers that describe the source as the tool actually saw it, and a clear record of the output format. Because the page prints decoded duration, sample rate, channel count, and frame count before you cut, and because every download is a freshly encoded PCM16 WAV with documented fields, the document can quote those values directly instead of guessing them.
Fields to record in an audio-cutting document
A useful record is short enough to keep inside a ticket or a runbook, but specific enough that another person, or future you, could repeat the cut on the same source and produce the same file. At a minimum, the document should capture:
- The original source file name and the codec container it claims to be (for example, a 12.3 MB MP3 or a 6.1 MB M4A), plus the browser version used.
- The decoded values displayed on the page: duration in moments, sample rate, channel count, and total frame count.
- The start and end times you typed, almost instantly, and a short note about which sound or transcript landmark each boundary sits on.
- The output file name, the reported output duration almost instantly, the reported output size in bytes, and the channel layout of the result.
- A verification step, such as "previewed the WAV at both boundaries and confirmed the transient sits cleanly inside the kept region."
If the cut failed, the document should also note which limit was reported (file too large, decoded too long, too many channels, sample rate above 192 kHz, or decoded samples above 30 million), since the tool's safety messages are explicit rather than silent and tend to point at exactly one constraint.
Documenting the cut with Audio Cutter
Open Audio Cutter and follow this three-step workflow. Because the workflow follows three documented steps, it is easy to write down and reuse across many entries.
- Choose a browser-decodable audio file within the displayed file and decoded-audio limits.
- Enter a non-negative start time and a later end time that does not exceed the decoded duration.
- Select Cut and export WAV, preview the PCM16 result, then download it.
For documentation purposes, capture the exact numbers shown on the page after step 1 finishes decoding. Write them into the record next to the start and end times, so anyone re-reading the document can see the working buffer the tool actually used, not only the timecodes you typed.
Recording the technical fields the tool exposes
The page prints four values that almost never appear in a simple "I trimmed from 0:12 to 0:45" note. Recording them turns a vague runbook into a verifiable one. Use this table as the field list in your document.
| Field on the page | What it means | Why it matters in the document |
|---|---|---|
| Decoded duration | Length of the working buffer in moments | Defines the maximum allowed end time |
| Sample rate | Frames per second of the decoded buffer | Determines how start and end seconds round to frames |
| Channel count | How many audio channels survived decoding, from mono up to eight | Multiplies the data size and decides the channel layout |
| Frame count | Total decoded samples per channel | Multiplies the WAV data size; the 30 million sample cap counts samples across all channels |
The sample rate you see describes the decoded working buffer, not necessarily the source file's encoded rate. Web Audio may resample the source to the AudioContext sample rate while decoding, so two cuts of the same MP3 in two different browsers can display different decoded sample rates. Recording the displayed rate is the only honest way to make the documentation match what was actually exported.
Documenting the WAV output and its file size
Every download is a newly encoded RIFF/WAVE file containing interleaved, little-endian, signed 16-bit PCM samples. Because the result is uncompressed, the file size is a fixed function of the selection, not of the source's bitrate. Audio Cutter reports the output duration and file size before download, and you can verify both numbers from the start and end times and the displayed decoded sample rate.
A worked example keeps the runbook testable. Suppose the page decodes a stereo source at a 44,100 Hz sample rate and you type start = 1.0 s and end = 2.0 s. The kept region contains 1.0 s × 44,100 frames/s = 44,100 frames per channel. With 2 channels and 2 bytes per PCM16 sample, the audio data uses 44,100 × 2 × 2 = 176,400 bytes. Add the 44-byte WAV header and the total file size should be 176,400 + 44 = 176,444 bytes. If the page reports a different size, the document has a mismatch worth flagging rather than silently accepting.
For more general documentation, write the formula in plain text once and apply it to any future entry:
| Quantity | Formula | Notes |
|---|---|---|
| Frames per channel kept | (end − start) × decoded sample rate | Rounded to whole frames by the tool |
| Audio data size in bytes | Frames × channel count × 2 | Two bytes per PCM16 sample |
| Total WAV file size | Audio data size + 44 | The 44-byte RIFF/WAVE header |
This is also where you explain why the cut WAV is often larger than the source. PCM16 WAV stores uncompressed samples; the source MP3, AAC, Ogg, WebM, or FLAC carried compressed frames instead, so the same number of seconds occupies fewer bytes. The document should not promise that the output will be smaller than the input.
Writing down the input limits and failure modes
A documentation set that does not record the boundary conditions will mislead readers the next time they try a similar file. The page enforces explicit limits rather than truncating silently: the encoded input file must be no larger than 25 MB, and after decoding the audio must be no longer than 15 minutes, use no more than eight channels or 192 kHz, and contain no more than 30 million channel-samples. Because the decoded-sample cap counts samples across all channels, a high-rate or multichannel file can hit the processing boundary before the 15-minute limit does.
In practice, when a file is rejected, capture the exact message, the file name, and the value the tool printed before the error. Those three pieces are usually enough to decide whether to lower the input rate, split the file, or move to a dedicated editor. For files that decode cleanly, also note that the source's compressed codec, tags, album art, cue points, chapters, loudness metadata, and encoder settings are not preserved in the exported WAV, so downstream tooling that depends on those fields will not see them even though the audio itself is intact.
Pairing the steps with a verification log
Documentation is only useful when you can tell whether a repeat run succeeded. Add a short verification block to the bottom of the record with two entries: what you listened for at the start boundary, and what you listened for at the end boundary. Spoken words, drum hits, or musical transients make the best landmarks because they are easy to describe in one line and easy to recognize on a second pass. Then record whether the repeat run reproduced the same byte size and the same decoded duration; if it did not, the document needs a fresh entry and the original source file is still the reference of truth.
Keep the original source file alongside the document, in the same folder or the same ticket attachment, so the workflow is fully reproducible. If a downstream task later demands waveform-level fades, lossless compressed-frame cutting, metadata preservation, or production mastering, the runbook should point at a dedicated editor instead of trying to stretch the browser tool beyond what it documents. That single line at the end of the verification block turns a per-file note into a long-lived knowledge base that holds up across projects.
For a deeper look, see How to Fix a Result That Looks Wrong After You Cut Audio.
For a deeper look, see Cut Audio in Your Browser: A First-Time Walkthrough.