When Enrollment and Test Audio Use Different Sample Rates, Kaldi iVectors Lose Their Adaptive Edge

Why iVectors Stop Adapting

In Kaldi's speaker-adaptive ASR pipeline, iVectors compress speaker identity into a low-dimensional space derived from a universal background model and a total variability matrix. This compressed representation enables efficient maximum-a-posteriori adaptation, but the adaptation only works when the input features faithfully reflect the speaker's acoustic characteristics. When the feature extractor produces different statistics for enrollment versus test audio, the iVector no longer aligns with the adaptation space, and speaker verification or recognition accuracy can degrade silently.

The Feature Extraction Trap

Kaldi supports both mfcc and fbank feature pipelines, each configurable by sample rate, window size, and window function. A typical recipe uses a 25-millisecond Hamming window with a 10-millisecond shift. If enrollment audio was processed with those defaults but test audio used a 30-millisecond window—or if sample rates differed between the two corpora—the sufficient statistics accumulated by the pipeline become incomparable. The total variability matrix, which maps feature space to iVector space, was trained on one set of feature distributions; applying it to mismatched features produces a distorted iVector.

A Worked Example: Re‑extracting Features With Matched Parameters

Suppose you have a development set under $data_dir and an enrollment set under $enroll_dir. Before re‑extracting, check the existing configuration:

# Check the existing MFCC configuration cat conf/mfcc.conf # Sample output: sample-rate=16000 window-type=hamming frame-length=25 frame-shift=10

If the test set was generated with different values, re‑extract features using explicit, matching flags. The following command extracts fbank features at 16 kHz with a 25 ms Hamming window and 10 ms shift:

# Re‑extract fbank features at 16 kHz, 25 ms Hamming window, 10 ms shift steps/make_fbank.sh --cmd $train_cmd --nj 8 --sample-frequency 16000 --window-type hamming --frame-length 25 --frame-shift 10 $data/test exp/make_fbank/test

Run this from a shell with read access to $data and write access to $exp; the command does not modify the source audio or existing feature archives.

After feature extraction, run the iVector extractor with the same total‑variability space used during enrollment. The extractor expects features with the same distribution it was trained on:

steps/ivector_extractor.sh --cmd $train_cmd --ivector-dim 400 --total-variability-factor 0.5 $exp/extractor $data/test/ivector scp:data/test/feats.scp $exp/test_ivectors

the directory $exp/test_ivectors should contain iVectors whose dimension matches 400 (or whatever your extractor was trained with). you can verify the dimension with:

ivector-info $exp/test_ivectors/ivector.scp

if the output shows a different dimension, the feature extraction pipeline was not matched to the extractor, and you should revisit the make_fbank or mfcc configuration.

re‑extracting features wastes I/O and CPU if the original parameters were already correct, but it does not corrupt existing models or state.

Trade‑offs and Limitations

Even with perfectly matched feature extraction, iVectors have practical boundaries. the universal background model (UBM) must be trained on a representative speaker set; if the UBM was fitted on a narrow domain, adaptation will be poor regardless of feature alignment. additionally, ZT (zero‑length) normalization and length normalization trade off robustness against short utterances; ZT tends to stabilize verification scores for very brief enrollment audio, but may over‑shorten already concise recordings. kaldi offers both normalization strategies through the ivector-normalize-length and ivector-normalize-zt options in the extractor script.

Kaldi's steps/ivector_extractor.sh includes options to inspect the total variability space:

ivector-info $exp/extractor/ivector_extractor.mdl

Check that the total variability matrix dimension aligns with your --ivector-dim; a mismatch here signals a pipeline configuration error rather than a feature mismatch.

Actionable Next Step

Before tuning downstream ASR models, spend a few minutes confirming that every utterance—enrollment and test—was processed with identical sample-rate, frame-length, and frame-shift settings. use the ivector-info diagnostic to confirm vector dimensionality, then proceed with adaptation or verification. this single check resolves the most common silent failure mode in Kaldi's iVector pipeline.