Preview before you export: why audio tools need a play button

Typing 12.40 into a start box and hoping is not editing. The difference between a usable audio tool and a frustrating one is whether you can hear the edit before you commit to it.

Two handles, one selection

A trim range needs both an in point and an out point, and both should be draggable. A single handle forces you to think in absolute seconds; two handles let you think in shapes — "start just after the cough, end before the door slams". The numeric fields stay useful for fine tuning to the hundredth of a second, but the handles are what you reach for first.

Playing only the selection

Preview playback is simple to implement on top of a plain `<audio>` element: seek to the in point, play, and pause again once `currentTime` passes the out point.

el.currentTime = start;
el.play();
el.addEventListener("timeupdate", () => {
  if (el.currentTime >= end) { el.pause(); el.currentTime = start; }
});

That loop costs nothing and removes the render-listen-undo cycle entirely. You hear the exact clip you are about to export.

Auditioning tracks before you merge

When you queue five files for joining, the filenames rarely tell you which take is which. A per-track play button — one shared audio element, swapped source, single playing state — lets you check each one and reorder confidently before rendering.

Keep preview separate from render

Preview should use the original compressed file through the media element, not the decoded buffer. It starts instantly, streams, and uses almost no memory. The heavy `OfflineAudioContext` render only runs when you press the export button, once, with settings you have already heard.

Both the Audio Trimmer & Cutter and the Audio Merger & Joiner now work this way: listen first, export once.