This appendix describes the browser-side editor in an anonymised language education workflow. The public case study says that reviewers could inspect regions, adjust boundaries, and export clips with metadata; the code shape below is illustrative, with no customer screenshot, source audio, or new browser performance test included.

Make a region editable

An automated boundary is still a proposal. A reviewer needs to hear the edge, see which speaker and transcript belong to it, and move the boundary without losing the surrounding context. Sending every small correction back through the server would add a round-trip to each check and complicate recovery when a review session is interrupted.

The editor therefore treated a region as a first-class object. A region had an identifier and start and end times; the surrounding review state kept the speaker label and transcript context alongside it. The waveform was a view of those times. It was not the source of truth for speaker identity or script alignment.

Keep local edits local

The old solution notes describe wavesurfer.js for waveform rendering and regions, with the Web Audio API handling local playback and clipping. React owned the surrounding review state. The instance was created after the container mounted and destroyed when the component was removed; that lifecycle matters because a waveform engine created during render can be duplicated during rerenders.

An illustrative update path is:

onRegionUpdate(region):
    segments[region.id].start = region.start
    segments[region.id].end = region.end
    preview = clipDecodedAudio(region.start, region.end)
    keep transcript and speaker fields unchanged

The waveform can show several regions at once, while the list beside it gives the reviewer another way to select one. Local clipping keeps an adjusted preview close to the edit. Batch export can then pair each clip with its metadata, provided the final state has been reviewed.

What the browser cannot prove

The browser is a useful place for small corrections because the reviewer can compare sound, timing, and text in one view. Decoding and drawing still consume memory and CPU, especially as files grow longer. Mobile browsers and different audio formats can behave differently, so a visual editor needs a fallback path and should avoid presenting a frame-rate or latency target that has not been measured for the actual file and device.

The main safety boundary is state ownership. Dragging a marker changes a time range. It does not silently rewrite the transcript, relabel a speaker, or approve a script match. Those changes remain explicit review actions, which makes an exported result easier to inspect later.

Evidence boundary

The public material does not provide a reproducible device, browser, audio file, or measurement run, so no cross-browser performance claim can be derived here. The evidence supports a smaller conclusion: a waveform plus local audio controls gave the reviewer a place to correct proposed boundaries before export. It does not prove identical performance across browsers or long recordings.