Drop mic-track echoes of system audio at transcript merge

[jpsrobertson]

Problem

Recording a meeting played through the speakers with the default raw mic (mic_voice_processing off), the mic hears the speakers. In my test session the leaked far-end audio reached the mic louder than my own voice (-33.9 vs -37.6 dBFS), so Parakeet transcribes it cleanly and every far-end sentence lands twice — once as "them" from the system tap, again as "me" from the mic:

**[0:21] them:** reports, right?
**[0:21] me:** reports, right?

In a real 42-minute meeting, 477 of 641 "me" segments were echo copies of "them" speech.

Fix

Filter the mic-side copies out at transcript-merge time. A me segment whose words are ≥70% contained, in order (word-level LCS on normalized words), in the them speech it overlaps (±400ms pad for the room-path lag and loose VAD boundaries) is the speakers heard twice, not the user talking over them. One/two-word segments ("um", "yeah") only drop on an exact hit so genuine backchannels survive.

• New config key transcript_echo_filter, default on — costs nothing when there's no echo; false restores raw merge output.
• Drops are counted in the session's transcribe.log, so nothing disappears silently.
• mic_voice_processing still prevents the echo at capture when enabled — this pass is the guard for sessions recorded raw (the default) or where the voice unit fell back.

Also corrects the MicRecorder header comment claiming voice processing is on by default (Config defaults it off) and documents the new key in the README.

Validation

• Thresholds tuned on the echoed session above: all 477 drops spot-checked as echo (including pairs the two tracks transcribed slightly differently — "data map" vs "data mode"); genuine cross-talk over far-end speech ("No, I I I do get you") all kept.
• End-to-end: re-transcribing that session through the patched daemon produced 1160 → 683 segments with echo filter dropped 477 mic segment(s) duplicating system audio in transcribe.log.

🤖 Generated with Claude Code