Audio
Analysis
Automation
Build 04
A Python pipeline that compares speech recordings using speaker embeddings, voice-activity detection and pitch features, and returns structured evidence so a reviewer can focus on judgement instead of replaying clips.
A Python pipeline that compares speech recordings using ECAPA-TDNN speaker embeddings, voice-activity detection and pitch features, and reports structured similarity evidence for a human reviewer.
The work rewards patience, not insight. That is a sign it should be automated.
Judging whether two recordings come from the same speaker by listening is slow and repetitive: play, rewind, play again, switch clips, repeat.
It is also inconsistent. Judgement drifts as attention fades, and two reviewers can disagree on the same pair.
The pipeline turns audio into measurable evidence. It does not replace the reviewer; it gives them scores, flags and context so their time goes where it matters.
A similarity score is only as trustworthy as the audio and the checks around it, so the pipeline follows four rules:
The goal is a reviewer who trusts the output because it shows its working.
Pre-trained speaker models do the heavy lifting. The engineering is in the preparation and reporting around them.
A preparation-then-comparison pipeline, with a branch for results that are not clear-cut.
Speaker models are powerful but not magic. These are the limits I designed around.
It is a Python pipeline that turns each recording into a speaker embedding with an ECAPA-TDNN model (SpeechBrain on PyTorch), filters out non-speech with voice-activity detection, and scores pairs of clips with cosine similarity, with pitch features as a secondary signal.
No. It produces evidence: scores, supporting features and flags. Unclear results are flagged for a careful human listen, and a person makes the final call.
Silence and noise can skew speaker embeddings, so only speech is compared. Pitch adds a second, independent acoustic signal as a cross-check.
Noisy or very short clips reduce reliability, and the thresholds need calibrating against known examples before the scores can be trusted.
Playwright handles the repetitive browser steps around the analysis, such as detecting new items and gathering the audio. The analysis itself does not depend on it.