Linguacorpus

Speaker Identification vs Speaker Verification

Short answer. Identification asks which of your enrolled speakers this is: a closed-set N-way choice, scored by top-1 accuracy, where the error rate grows as you add speakers. Verification asks whether this is the claimed speaker: a yes/no decision against a threshold, scored by false accept and false reject rates, where the error rate depends on where you set that threshold. The same embedding model serves both tasks, but the numbers are not interchangeable, and a verification score is not a probability.

How to do it

Fix which question you are answering before you touch a model

Identification is 1:N. You have a closed set of enrolled speakers, and every test utterance is assigned to one of them. There is no "none of the above" unless you add one explicitly, which turns it into open-set identification and makes it much harder.

Verification is 1:1. A speaker claims an identity, the system compares the test utterance against that one enrollment and returns a decision. The set size never enters the calculation, which is why a verification system that works with 50 enrolled speakers still works with 50,000.

The practical consequence: identification degrades as the enrolled population grows, and verification does not. If your product is a wake-word-plus-owner-check on a phone, you want verification. If it is "who in this meeting said that," you want identification, and you should expect to report accuracy together with the number of speakers.

Score identification as a ranking problem

Identification is scored with top-1 accuracy: for each test utterance, rank all enrolled speakers by similarity and check whether the correct one is first. Always print the chance level next to it, because 1/N moves fast.

  • 8 speakers: chance is 0.125, so 0.90 accuracy is a real result.
  • 100 speakers: chance is 0.01, so 0.90 accuracy is a different result.
  • 1,000 speakers: chance is 0.001, and 0.90 is a strong result that most off-the-shelf embeddings will not reach without a trained backend.
  • Open-set identification (with a reject option) also needs a threshold, so it inherits every verification problem on top of the ranking problem.

Score verification with a threshold sweep, never a single number

A verification system outputs a score, not a decision. The decision appears when you pick a threshold, and every error rate you quote is conditional on that threshold. Two systems can have identical score distributions and different error rates because someone picked a different operating point.

Report the sweep: false accept rate (accepting an impostor) and false reject rate (rejecting the true speaker) at several thresholds, plus the equal error rate where the two curves cross. EER is convenient for comparing systems but it is rarely the operating point you will deploy, and it hides the fact that the curves are not symmetric in cost. A bank wants FAR near zero and will accept a high FRR. A personalization feature wants FRR near zero and will tolerate the occasional wrong profile.

A verification score of 0.72 is not a 72% chance that the speakers match. The mapping from score to probability depends on the trial distribution, and it changes when the enrollment audio gets shorter, noisier, or comes from a different microphone.

The data requirement is different for the two tasks

Identification evaluation needs many speakers with several utterances each, split into enrollment and test sets. Verification evaluation needs many same-speaker and different-speaker pairs, which you generate from the same corpus by choosing which pairs to score. The pair count grows quadratically with the number of speakers, so a corpus with 200 speakers can produce hundreds of thousands of trials, but only if the enrollment and test sides are speaker-disjoint and condition-matched.

The single most common way to inflate both numbers is to enroll and test on audio from the same session. The model then matches on channel and content rather than voice, and the reported accuracy collapses the first time it sees a new recording session.

Code

Closed-set identification and threshold-based verification over the same synthetic embeddings, so the two error questions are visible side by side.

import numpy as np

rng = np.random.default_rng(7)
DIM, UTT, N_SPK, JITTER = 32, 6, 8, 1.0

# Speaker centroids, plus per-utterance jitter, then L2-normalize every vector.
centroids = rng.normal(size=(N_SPK, DIM))
emb = np.array([[c + JITTER * rng.normal(size=DIM) for _ in range(UTT)]
                for c in centroids])
emb /= np.linalg.norm(emb, axis=2, keepdims=True)
enroll, test = emb[:, 0], emb[:, 1:]

print('--- 1:N identification: one answer per utterance ---')
for n in (2, 4, 8):
    e, t = enroll[:n], test[:n]
    acc = np.mean([int(np.argmax(e @ t[i, j])) == i
                   for i in range(n) for j in range(UTT - 1)])
    print('N=%d  top-1 accuracy %.3f   chance level %.3f' % (n, acc, 1.0 / n))

print('--- 1:1 verification: a score, then a threshold ---')
same = np.array([enroll[i] @ test[i, j]
                 for i in range(N_SPK) for j in range(UTT - 1)])
diff = np.array([enroll[i] @ test[(i + 1) % N_SPK, j]
                 for i in range(N_SPK) for j in range(UTT - 1)])
print('same-speaker  cosine: mean %.3f  min %.3f' % (same.mean(), same.min()))
print('diff-speaker  cosine: mean %.3f  max %.3f' % (diff.mean(), diff.max()))

for thr in np.linspace(0.1, 0.9, 9):
    far = float((diff >= thr).mean())      # impostor accepted
    frr = float((same < thr).mean())       # true speaker rejected
    print('threshold %.2f -> FAR %.3f  FRR %.3f' % (thr, far, frr))
  • No third-party packages. Requires numpy only.
  • Expected output: identification accuracy near 1.0 for every N, with the chance level falling from 0.500 to 0.125 as N grows — that fall is the point, since the accuracy column alone does not tell you how hard the task was.
  • The verification block prints the same score distribution two ways. Watch the FAR and FRR columns swap places as the threshold passes roughly 0.55, and note that no single row is "the" error rate.
  • Raise JITTER to 1.6 and rerun: identification accuracy drops first, and the FAR/FRR curves stop crossing at a clean point. That is what a weak embedding looks like from the outside.

Where this goes wrong

Quoting a verification score as a probability

A cosine similarity of 0.72 means "these two vectors point in a similar direction under this model," nothing more. Turning it into a probability requires a calibration set drawn from the same population, channel, and utterance length as your deployment. Teams that skip that step ship a threshold tuned on studio recordings and find that a phone-channel impostor passes it. If you need a probability, calibrate on matched data and report the calibration error, not just the EER.

Comparing identification accuracy across datasets with different speaker counts

Ninety-five percent on a 10-speaker task and 95% on a 1,000-speaker task are not the same achievement, and the chance levels differ by two orders of magnitude. A vendor table that lists accuracy without N is not comparable to anything. Ask for N, the enrollment size per speaker, and whether the set was closed or open.

Describing a deployed system with a closed-set number

In deployment the speaker is frequently not enrolled at all, which a closed-set test cannot represent: every trial has a correct answer by construction, so the system is never measured on rejection. The gap between closed-set accuracy and open-set accuracy on the same corpus is routinely 10 to 25 points, and it is entirely the reject decision that costs you.

Enrolling and testing on the same recording session

If the enrollment utterance and the test utterance come from one session, they share the microphone, the room, and often the sentence content. The embedding matches on those factors as much as on voice, and accuracy on the test set runs 10 to 20 points above what the same system gets on a genuinely new session. Split by session, not by utterance.

Using one global threshold for every speaker

Speakers are not equally far from the cohort mean. A global threshold that gives 1% FAR on average can give 0.1% for one speaker and 6% for another, because the impostor scores for some voices sit closer to their own scores. Score normalization against a cohort (subtract the mean impostor score for that enrollment) or per-speaker thresholds fixes most of it. Report the per-speaker spread, not just the average.

When to buy the data instead of building the pipeline

Buy when you need a speaker set large enough to produce meaningful trial counts — a few hundred speakers with several sessions each, split so enrollment and test never share a session — and when you cannot record that yourself in the channels you will deploy on. Buy when the evaluation has to survive scrutiny from a customer or an auditor, which means a speaker manifest, session IDs, and consistent channel metadata. If you are prototyping an embedding model on 20 speakers you recorded in one afternoon, that is the right call and no dataset will be cheaper — but do not quote those numbers as a system evaluation.

How buying training data works →

More technical reference

All technical reference →

Need data for Speaker Identification vs Speaker Verification?

Tell us the language, the hours, and what the data needs to look like. You will get a real number and a real timeline — not a range. If we cannot source it well, we will tell you that instead.

  • Pilot batch before the full run, so problems surface early.
  • Consent documentation delivered with the data.
  • No medical or clinical data. No recorded telephone calls.

We reply within two business days. Your details are used only to answer this request. See our privacy policy.

Contact

Talk to a human

Send a specification and we will come back with a real number and timeline.

Submit a sourcing request

Or email hello@linguacorpus.com