content_cut Audio Trimmer star

How Browser-Based Audio Trimming Works

This tool never sends your file anywhere — it uses the Web Audio API's decodeAudioData() to unpack the compressed audio (MP3, AAC, OGG, whatever the browser's codec supports) into a raw AudioBuffer: an array of floating-point sample values between -1 and 1, one per channel. That decoding step is the same one a media player performs internally before it can actually play a sound — the difference here is that the decoded samples stay accessible in JavaScript instead of going straight to the speakers, which is what makes editing possible. One detail worth knowing: decodeAudioData() decodes into the AudioContext's own sample rate — typically 44.1kHz or 48kHz depending on your device's audio hardware — rather than the source file's original rate, resampling automatically if they differ. This is standard, transparent behavior built into every browser's audio pipeline, not something this tool does differently, and it applies equally whether a file is 8kHz voice audio or 96kHz studio audio.

Trimming, once the audio is decoded, is nothing more than array slicing: multiply the selected start and end times in seconds by the sample rate to get sample indices, then copy only the samples between those two indices into a new, shorter buffer. There is no re-encoding of the audio content, no quality loss, no re-compression artifacts — the waveform inside the selected range is copied byte-for-byte in its decoded form.

The waveform preview is drawn by walking the decoded sample array once, dividing it into as many buckets as there are horizontal pixels, and plotting the minimum and maximum sample value found in each bucket as a vertical bar — the same peak-envelope technique every audio editor uses, because plotting every individual sample (often 44,100 per second) would be both wasteful and visually indistinguishable from the min/max envelope at typical screen resolutions.

Why the Output Is WAV, Not MP3

The trimmed result is exported as WAV — an uncompressed PCM container that simply writes the raw sample data back out with a standard 44-byte RIFF header describing the sample rate, bit depth, and channel count. This is a deliberate, honest trade-off: encoding to a compressed format like MP3 requires a full psychoacoustic encoder (the same kind of complex algorithm used to create the file in the first place), which browsers do not expose natively and which would require loading a large additional library. WAV, in exchange, guarantees zero generation loss — trimming ten times in a row never degrades the audio, unlike repeatedly re-saving a lossy MP3. If a smaller file is needed afterward, the resulting WAV can be re-compressed with any standard audio tool.

• The exported WAV uses the AudioContext's sample rate (usually 44.1kHz or 48kHz) and 16-bit depth, regardless of the source file's original rate or bit depth — this comes from how decodeAudioData() works, not from a limitation of the trim itself.
• Very long files (over roughly 30-60 minutes) can use significant browser memory, since the entire decoded buffer is held in RAM as floating-point samples before trimming.
• The waveform is drawn from the first audio channel only; stereo content is trimmed on all channels equally, only the preview simplifies to one line.