Speaker diarization is the task of working out who spoke when in an audio recording. A diarization system takes a conversation and splits it into speaker turns, assigning each stretch of speech to a speaker label: Speaker 1 said this from 0:02 to 0:14, Speaker 2 replied until 0:21, and so on. Without it, a transcript of any multi-speaker recording is a wall of undifferentiated text.
This guide covers what diarization is and is not, how it differs from speaker identification, how systems do it, how speaker labels should appear in transcripts, whether Whisper handles diarization, why diarization remains genuinely hard, and what the training data behind a good system looks like.
What speaker diarization is (and is not)
Diarization answers who spoke when by assigning anonymous labels to time intervals. It does not require enrolled identities, and diarization alone does not name a person. The related but separate task of matching a voice to a known identity is speaker identification, covered in its own section below and in our speaker recognition dataset guide.
The tasks can be combined. A meeting product may diarize first, then map some anonymous clusters to enrolled speakers and leave other speakers unnamed. The buyer should therefore specify whether the required output is anonymous speaker attribution, role labels such as agent and caller, or identity fields supported by a separate rights and verification process.
Diarization versus speaker identification
Diarization and speaker identification solve different problems, and buyers who conflate them end up scoping the wrong project. Diarization needs no enrolled identities: it clusters a recording's speech into anonymous speaker labels, Speaker 1 and Speaker 2, based on how the voices in that recording differ from each other. Nobody has to have provided a reference sample in advance, and the output never claims to know who Speaker 1 actually is.
Speaker identification instead matches an incoming voice against a set of known, enrolled voiceprints to answer a different question: is this a specific named person. That requires an enrolment step, a stored voiceprint or embedding for each person the system should recognize, and a matching threshold that trades false accepts against false rejects. Because it stores and matches a biometric identifier tied to a real person, identification carries consent, retention, and regulatory obligations that plain diarization does not: the buyer needs a lawful basis for enrolling voiceprints, a defined retention and deletion policy, and, depending on jurisdiction, consent language separate from a general recording notice. Speaker verification is a narrower relative of identification: it checks a single claimed identity against one enrolled voiceprint rather than searching a whole roster.
A project brief should state plainly which of the three tasks it needs. Asking a vendor for identification when diarization would do adds enrolment infrastructure and compliance surface for no benefit; asking for diarization when the product actually needs to know who is speaking will fail to deliver the one thing the buyer wanted.
How do you correct speaker labels in a transcript?
To correct a speaker label, first fix the segment boundaries, then the identity assignment, in that order. Most label errors are boundary errors in disguise: a segment that starts too early or ends too late picks up the neighboring speaker, and relabeling it without moving the boundary just relocates the error. Work through four checks: verify the segment boundaries against the audio, merge or split segments so each contains one speaker, reassign the corrected segments to the right anonymous speaker ID, and only then review overlap regions, which most tools handle worst.
Correct labels systematically, not ad hoc: sample a fixed share of the transcript, log every correction by error type (boundary, identity swap, missed overlap, ghost speaker), and measure the correction rate per hour of audio. If the rate is stable and low, spot-checking is enough; if it clusters in noisy segments or specific speakers, the upstream diarization settings or the audio itself need attention before more manual correction. A managed pass through audio and speech annotation can apply an agreed correction guideline with reviewer qualifications and acceptance sampling, and the same rules belong in the evaluation template below so corrected reference labels stay consistent with how the system is scored.
How diarization systems work
Many diarization pipelines detect speech, segment likely speaker changes, turn each segment into a speaker representation, and cluster similar segments. Other systems jointly model some of those stages or represent overlapping speakers directly. Architecture labels are not a substitute for evidence: evaluate the complete pipeline on audio that represents the target channels, speaker counts, languages, noise, and conversational behavior. Diarization error rate, covered in detail in the evaluation section below, is the metric most commonly used to compare results.
Speaker labels in transcripts
Diarization output usually appears as a speaker label and start and end time on each turn. The annotation brief should define:
- Stable identifiers. The same person keeps the same anonymous label within the agreed scope. Cross-recording identity is a separate requirement.
- Boundary and timestamp rules. State the units, precision, minimum turn duration, silence rule, and treatment of clipped or uncertain boundaries.
- Overlap. Decide whether simultaneous speakers receive parallel spans, an overlap flag, a dominant-speaker label, or another documented representation.
- Backchannels and short turns. State whether brief acknowledgements are their own turns and how they are reviewed.
- Unknowns. Preserve an unknown or uncertain state rather than forcing a guess.
- Role or identity fields. Include them only when the project, source records, and applicable rights support them.
These conventions affect transcript usability, training labels, and the reference used to score a system. Our guide to audio annotation covers the wider labeling workflow.
What to put in a diarization annotation brief
| Decision | What to specify |
|---|---|
| Input population | Languages, speaker-count range, mixed or separate channels, codecs, devices, environments, and expected overlap. |
| Label schema | Anonymous IDs, turns, overlap, backchannels, unknown speakers, timestamps, roles, and any cross-session rule. |
| Reference process | Annotator and reviewer qualifications, independent review, adjudication, guideline version, and disagreement record. |
| Output | JSON, JSONL, RTTM, CSV, TextGrid, or another schema, plus manifests, checksums, metadata, and version history. |
| Acceptance | Representative held-out audio, scoring implementation, slices, threshold, evidence, failure review, and rework trigger. |
| Rights and controls | Source, permission, permitted use, privacy, security, access, retention, transfer, and deletion requirements. |
The managed audio annotation service can assess these requirements for buyer-provided or newly collected audio. Supported labels, reviewers, QA, security, formats, schedule, and price are confirmed in the written scope.
Does OpenAI Whisper perform speaker diarization?
No, not on its own. OpenAI's Whisper is a transcription model: given audio, it outputs text, and in some configurations word-level timestamps. It does not cluster speech by speaker and it does not emit speaker labels. Anyone who has fed a multi-speaker recording through Whisper and gotten back one continuous transcript with no speaker breaks has run into exactly this gap. This is not a Whisper-specific limitation: pairing a separate diarization step with the transcription model is the usual approach regardless of which transcription model is doing the transcribing, because transcription and diarization are different tasks.
The common pattern is to run diarization as a separate step and merge the two outputs on timestamps: Whisper's word or segment timestamps are matched against the diarization system's speaker turns, and each transcribed word inherits the speaker label of the turn it falls inside. This works, but the merge is its own source of error, distinct from diarization error rate. Timestamps from the two systems rarely line up exactly at a turn boundary, so words spoken right at a speaker change can be assigned to the wrong speaker even when both the transcription and the diarization are individually correct on their own terms. The shorter the turn and the closer to a boundary a word falls, the more likely a merge error becomes, which is the same pattern that makes diarization struggle with short backchannels and fast turn-taking generally.
A buyer evaluating a Whisper-plus-diarization pipeline should score the merged output, not the two components separately: request per-word or per-segment speaker accuracy on the final transcript, and ask specifically how boundary words are handled, since that is where a pipeline built from two individually correct systems still produces a visibly wrong transcript. Telephony deployments compound the problem, since Whisper's own transcription accuracy already degrades on 8kHz call audio before diarization enters the pipeline; see our guide to Whisper on 8kHz phone audio for the transcription side of that failure mode.
Why diarization is still hard
Our blog post on where speaker labels break covers the diagnostic checks worth running on a demo before trusting it, such as comparing the speaker count a system returns against known metadata and looking at segment-duration distributions within a cluster. The list below is the buyer side of the same problem: what to specify in a brief for each condition, so acceptance testing is built around it instead of discovered after delivery.
- Overlapping speech. State whether overlapping intervals should get parallel speaker labels, an overlap flag, or a single dominant-speaker call, since most systems can only assign one label per interval and the brief has to say which loss is acceptable.
- Short backchannels. Set a minimum duration or evidence threshold below which a brief acknowledgement may be assigned to a neighboring speaker instead of scored as its own turn.
- Very short turns. Set a floor on turn length the system is expected to resolve reliably, since a shorter segment simply carries less signal for telling speakers apart.
- Similar-sounding speakers. Flag known risk factors, such as speakers matched in gender, age, accent, or recording device, so acceptance testing includes a slice for them instead of relying on one aggregate score.
- Channel bleed on shared microphones. Document the microphone and room setup for target recordings; one channel picking up several people mixes their voices together before diarization ever runs, and no downstream tuning fully separates them again.
- Far-field and telephony conditions. Name the target devices and channels, such as conference-room microphones, compressed calls, or telephony audio, since each degrades the signal differently and a system tuned on close-mic recordings will not automatically transfer.
- Unknown or changing speaker counts. State whether the speaker count is known in advance; when it is not, the system has to estimate it, and that estimate destabilizes when people join or leave mid-recording, so the brief should say how a wrong count gets handled.
Performance depends on the complete pipeline, the training and adaptation data, reference-label quality, scoring configuration, and how closely the evaluation resembles deployment audio; a clean two-person benchmark does not establish performance on a noisy multi-party meeting or a mixed call-center channel.
How to evaluate a diarization sample
Start with representative held-out audio and a human-reviewed reference created under the same written convention you expect in production. Freeze the scoring settings before results are seen, then report the headline and its missed-speech, false-alarm, and speaker-confusion components where DER is used.
Diarization error rate is a time-weighted ratio, not a count of mistakes: it sums the duration of missed speech, false-alarm speech, and speaker confusion, then divides by the total duration of reference speech. Missed speech is reference speech time the system failed to attribute to any speaker, not necessarily a whole missed segment; false alarm is time the system reported where the reference has none; speaker confusion is correctly detected speech time assigned to the wrong speaker label. Because it is a ratio of durations rather than a bounded accuracy figure, DER can exceed 100 percent when a system reports enough spurious or misassigned speech, which surprises buyers who expect it to behave like a percentage-correct score. None of the three components is optional to report; a headline DER that hides which one dominates hides where the system is actually failing.
Six settings move the number more than most buyers expect, and a vendor can choose favorable values on every one: the reference labels used as ground truth, the boundary collar (a small window of tolerance around each true segment boundary that gets excluded from scoring), the overlap-handling rule (whether overlapping speech is scored at all and how a single label for an overlapping interval is judged against two reference speakers), the speaker-mapping rule (how system labels get matched to reference labels before scoring), the scored regions (whether silence, non-speech, or low-confidence stretches are included or excluded), and the scoring implementation itself, since different tools compute the same nominal metric slightly differently. A DER number quoted without all six stated cannot be compared to another vendor's DER, even when both numbers use the same three letters.
- Report results by product-critical slices such as overlap, speaker count, channel, noise, language, device, and short-turn conditions.
- Record the distribution across files, not only one aggregate that can hide severe failures.
- Inspect speaker-count errors, label swaps, boundary errors, overlap, and examples with high product impact.
- Keep speakers, sessions, source recordings, and prompts separated from training or tuning where the evaluation design requires it.
- Agree the acceptance threshold, minimum slice coverage, evidence, and rework rule in writing rather than borrowing a universal target.
Use the ungated speaker diarization evaluation and acceptance template to record the reference, scoring configuration, held-out design, slices, deliverables, rights, and decision.
Training data for diarization
Training and adaptation may use multi-speaker conversation with verified turn labels, real overlap and interruptions, varied speakers, and channels and environments that represent deployment. Read or scripted speech alone is insufficient for testing natural turn-taking and overlap; the useful mix depends on the model job and failure analysis.
Separate channels preserve each speaker cleanly and simplify reference creation, while mixed channels represent what a single microphone or phone recording may deliver. Some projects need both. Our conversational speech data guide explains the collection choices, and the full-duplex collection offer describes a custom scope for buyers who also need new recordings.
For any source, verify the speaker and session coverage, channel and condition metadata, annotation convention, reference QA, provenance, permitted model use, restrictions, and evaluation separation. Our speech data licensing guide explains the corresponding diligence questions.