Lossless vs lossy audio trimming: what happens to your MP3 when you cut it

MP3, AAC (M4A), OGG Vorbis and Opus do not store sound. They store a compressed description of it: energy in frequency bands, quantized to whatever precision the bitrate allows, plus the encoder’s decisions about which details you would not have noticed anyway. Nothing in that structure corresponds to “the sample at one minute twelve point four seconds”, so there is nothing an editor could cut at that point.

So software decodes first. The browser’s own decoder — the same one that plays the file in an audio element — turns the stream back into amplitude values, one per channel per sample, 44,100 of them per second in the usual case, handed over as 32-bit floats between −1 and +1. Every operation in AudioCutlet, from a trim to a fade to a gain change, is arithmetic on those numbers.

The decode itself does not lose anything: what the original encoder discarded was gone before the file reached you, and no decoder can bring it back. What you get is the encoder’s approximation, faithfully reconstructed. Arithmetic on those samples is exact — a fade or a cut adds no distortion of its own.

The loss appears at export. Encoding to MP3 runs a psychoacoustic model over the signal to decide what to keep — but this time the signal already carries the first encoder’s quantization noise. Details the first pass decided were masked can become audible artefacts in the second, and the second encoder spends bits describing the first one’s approximations.

In practice one extra generation at 192 kbps or above is very hard to hear on music. Where it shows up is at 128 kbps and below, and on material with a lot of high-frequency transients: cymbals smear, sibilants develop a swishy quality, and a faint pre-echo can appear just before a sharp drum hit. Repeat the round trip five times at 128 kbps and the damage is obvious on any pair of headphones.

Exporting at a higher bitrate than the source restores nothing. A 320 kbps file made from a 128 kbps original is a large file containing exactly the detail the 128 kbps original had. It is still worth choosing, though: the higher bitrate simply means the second pass throws less away on top.

An MP3 is a sequence of frames. In the common Layer III case at 44.1 kHz each frame carries 1,152 samples, about 26 milliseconds of audio. Tools that advertise lossless MP3 cutting — mp3splt, mp3DirectCut and friends — copy whole frames from the input to the output without decoding anything, so there is genuinely no second generation of loss.

The price is precision. The cut lands on a frame boundary, which can be up to 26 ms away from the point you chose, and no fade, gain change or normalization is possible, because that would require decoding. There is also the encoder delay: encoders add roughly 576 samples of lookahead and pad the final frame, and LAME records both in an Info/Xing header so gapless-aware players can trim them. Cut a file without honouring that header and you can inherit a few milliseconds of silence or a click at the join.

AudioCutlet takes the other trade: it decodes, so cuts land exactly on the sample you picked, fades and levelling are available, and the cost is one encode at export. If you only need to chop a podcast into chapters and nothing else, a frame-level splitter is the better tool. If you need a clean edit at a musical point, decoding is the only way there.

Exporting WAV writes the samples themselves as 16- or 24-bit PCM: no model, no bitrate, no decisions. What you download is what you heard, and you can re-open it, edit again and export again as many times as you like without anything accumulating. That is the whole reason the format still exists.

It costs disk space and nothing else. Stereo at 44.1 kHz and 16 bits is 176,400 bytes per second, about 10.6 MB per minute; 24-bit is about 15.9 MB per minute. A four-minute song comes to roughly 42 MB at 16 bits — cheap next to redoing an edit because the only copy went through three MP3 generations.

The workflow that follows from this is simple: do all of the editing in one session, export a WAV and keep it, then make an MP3 from that WAV for each place the audio needs to go. Every MP3 is then a first generation from the master rather than a copy of a copy.

For music that someone will actually listen to, 192 kbps is transparent enough for most people on most equipment, and 320 kbps is the sensible choice when the file is an archive or will be edited again. For speech — an interview, a voice memo, a lecture — 128 kbps is plenty, and converting to mono first halves the data the encoder has to spend.

AudioCutlet encodes with LAME compiled to JavaScript, at a constant bitrate. A good variable-bitrate file of the same perceived quality would be slightly smaller, but constant bitrate has a predictable size: divide the bitrate by eight for kilobytes per second, so 192 kbps is 24 KB/s, about 1.44 MB per minute.

The sample rate of the source is kept as it is. Downsampling to shrink a file is a false economy: it removes the top octave of the spectrum, which is audible on cymbals and consonants, and saves less than simply choosing a lower bitrate would.

A ringtone, an alarm, a fifteen-second clip for a group chat, a voice memo trimmed at both ends — all of these will be played through a speaker a few millimetres across, and no listener will ever detect a second MP3 generation. Export at 192 kbps, get on with your day.

The same goes for anything destined for a platform that re-encodes uploads, which is all of them. YouTube, Instagram, Telegram and every podcast host transcode what you send to their own formats and bitrates, so your export is one link in a chain that already has several. Sending them a 320 kbps MP3 rather than a WAV costs a little quality that their own encoder would have taken anyway.

The cases worth caring about are narrow: the file is the only copy of something you cannot record again, or you know you will come back and edit it further. For those, the answer is always the same — keep a WAV.