Light audio editing in the browser: trim, join, denoise

Trim (cut heads, tails, and target ranges) then join (merge segments into one track), then crossfade (smooth the seams), then denoise (remove hiss and background noise), then compress (shrink for the use case). The five cover nearly every light-editing scenario: a ringtone is trim plus compress, BGM is trim plus fade, a podcast cut is denoise plus trim, a compilation is trim plus join plus fade.

The chain is a menu, not a checklist — take what the job needs. But the order has discipline: denoise before compress, fade after join. Reversed, the results lose half their effect.

Denoise before compression: lossy encoding bakes noise into the data, and a compressor-after-denoiser pass cannot separate what is now entangled with the signal. Denoise first, then encode — a clean signal gets encoded and the noise never revives. Compression is the final step of the chain — the generation-loss principle holds for audio exactly as for video: once compressed, stop touching.

Fade after joining: butting two clips together makes the volume jump at the seam — an audible click. A 0.5-to-1-second crossfade overlaps the outgoing tail with the incoming head and the seam disappears. Before joining, match the parameters: differing sample rates, channel counts, or codecs force a re-encode — normalize first, then join.

Ringtones: m4a or high-bitrate mp3 (phones do not care about ringtone size — favor quality). Podcasts: mp3 at 128–192 kbps (speech content; 128 is a fine floor). Archive masters: keep the original format or move to FLAC. For platform publishing, compress to the platform’s recommended bitrate — uploading maximum-bitrate files is wasted effort when the platform transcodes anyway.

Listen to the finished file end to end before delivering: seams, denoise residue, and half-words at trim edges are all things one listen catches. Audio is a timeline art — eyes cannot check what ears hear.