[patrickballard]

Closes #3432.

processTrim now creates the preview's MediaElementAudioSourceNode and its MediaStreamDestination once, keeps them in a ref, and adds that destination's audio track to each recording. Before, every trim called createMediaElementSource on the same always-mounted preview <video>, which browsers allow only once per element, so from the second trim on it threw InvalidStateError, the catch logged it, and the trim was recorded silent.

6 s H.264 + AAC MP4, full-length trims	before (cap.so)	after
first trim	video + audio, 6.0 s	video + audio, 5.9 s
after Trim Again	video only, 5.0 s	video + audio, 5.96 s
after Choose Different Video	video only, 5.0 s	video + audio, 5.96 s

Tests

• New trimming-tool-audio.test.ts, added to CI's web test list. It trims, then trims again after Trim Again and after choosing a different video, with an AudioContext stand-in that, like browsers, allows one MediaElementAudioSourceNode per element, and checks that each recording gets an audio track. Both cases fail without the change (the second recording has none).
• Checked in Chromium 152 by building the component into a Next 16 page (Turbopack) and trimming with real clicks: all three trims above have an Opus audio track with the test tone intact.
• bun run typecheck: no errors. Biome: the test is clean, and the component's existing lint errors are unchanged.

Confidence Score: 5/5

The PR appears safe to merge.

Summary

The PR reuses the preview’s audio destination so repeated trims retain audio.

• Repeat trims keep the preview video's audio in each recording.

_{Reviews (1) · Last reviewed commit: "fix(web): keep the audio in every trim, ..." · Reviewed by Greptile}

[vercel]

@patrickballard is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.