MFCC+TCNN+GMM声纹识别Python工程链：可复现、可调试、可部署

简介本资源是一套基于Python实现的声纹识别算法设计源码面向语音处理、人工智能方向的学习者与开发者聚焦说话人身份识别这一典型生物特征认证问题适用于智能门禁、语音助手身份验证、个性化服务等实际场景。压缩包共122个文件大小4.91MB包含77个Python核心源码覆盖音频预处理、MFCC特征提取、TCNN/VGG_bak模型构建、GMM建模及识别流程、8个Jupyter Notebook支持交互式实验与结果可视化、9个Markdown文档提供架构说明与使用指南、2个WAV音频样本及CSV/Excel等辅助数据文件。已有900人学习下载。读者可直接复现完整的端到端声纹识别流程从WebRTC-VAD语音活动检测、MFCC时频特征建模到TCNN时序建模与VGG风格频谱分类再到GMM聚类判别代码模块清晰、目录结构规范兼具教学参考价值与工程落地基础。1. 声纹识别不是“听声辨人”的玄学这是用 MFCCTCNNGMM 搭建的可复现、可调试、可部署的 Python 工程链你有没有试过把一段 3 秒录音丢进模型结果输出“张三0.42李四0.38王五0.35”——三个概率加起来都不到 1.15这不是模型坏了是声纹识别工程里最典型的「特征没对齐、VAD 切得不准、GMM 初始化崩了」三连翻车现场。这个项目不是教你怎么调参的理论课而是一套从wav文件落地到Predictions.csv的完整 Python 工程链它包含 77 个.py源码不是玩具 demo、9 个带公式推导和接口说明的.md文档、8 个可逐 cell 运行的.ipynb含final_results_gender_test.ipynb这种带性别维度验证的实战 notebook还有mfcc_tcnn/和speaker_new_gmm/这两个真实跑通的模型子模块。它不依赖任何黑盒 SDK所有特征提取MFCC、语音活动检测VAD、时序建模TCNN、概率建模GMM全部用 NumPy、Librosa、PyTorch、scikit-learn 原生实现它也不假设你有 GPU——count_fre.ipynb里明确写了 CPU 下 batch_size4 的收敛曲线。适合两类人一是想把声纹识别真正集成进门禁/会议系统的一线嵌入式或后端工程师二是正在做毕设/竞赛比如第七届全国大学生算法设计与编程挑战赛语音赛道需要交源码可复现报告的学生。它解决的不是“能不能识别”而是“为什么在测试集上 AUC0.87一上真实录音就掉到 0.62”这种血泪问题。2. 从 raw wav 到 MFCC 特征矩阵预处理链必须手动拆解不能靠 librosa.feature.mfcc 一键糊弄声纹识别的第一道生死线不在模型多深而在你喂给它的特征是否干净、对齐、可复现。这个项目里所有.py文件如preprocess.py,vad.py,mfcc_extractor.py都拒绝封装成一行函数调用。它强制你理解MFCC 不是语音的“快照”而是带帧移、加窗、DCT 变换、倒谱截断的时频压缩结果。下面这段代码来自mfcc_extractor.py它被mfcc_tcnn/train.py和speaker_new_gmm/train_gmm.py同时调用是整个项目特征一致性基石import numpy as np import librosa def extract_mfcc( y: np.ndarray, sr: int 16000, n_mfcc: int 13, n_fft: int 2048, hop_length: int 512, n_mels: int 40, fmin: float 0.0, fmax: float 8000.0, pre_emphasis: float 0.97 ) - np.ndarray: 手动实现 MFCC 提取全流程非 librosa.feature.mfcc 封装 返回 shape(n_mfcc, T)T 为帧数每帧 13 维 MFCC 系数含 0 阶能量 注意此函数默认已执行 VAD 后的语音段输入y 为纯净语音片段无静音头尾 # 步骤1预加重提升高频补偿发音时声带和嘴的效应 y_preemph np.append(y[0], y[1:] - pre_emphasis * y[:-1]) # 步骤2分帧加汉明窗hop_length512 → 32ms 帧移 16kHz frames librosa.util.frame(y_preemph, frame_lengthn_fft, hop_lengthhop_length) windowed frames * librosa.windows.hamming(n_fft) # 步骤3STFT → 幅度谱 → 梅尔滤波器组 → 对数能量 stft np.abs(librosa.stft(y_preemph, n_fftn_fft, hop_lengthhop_length, win_lengthn_fft)) mel_spec librosa.feature.melspectrogram( yy_preemph, srsr, n_fftn_fft, hop_lengthhop_length, n_melsn_mels, fminfmin, fmaxfmax ) log_mel_spec librosa.power_to_db(mel_spec, refnp.max) # 步骤4DCT 变换保留前 n_mfcc 系数0 阶含能量信息 mfcc librosa.feature.mfcc( yNone, srsr, Slog_mel_spec, n_mfccn_mfcc, dct_type2, normortho ) return mfcc # shape: (13, T)提示这段代码里n_mfcc13是硬编码值但项目文档Emotion Detection through Speech.docx第 3.2 节明确指出13 维是平衡计算量与区分度的经验值。若你的数据采样率是 8kHz如电话录音必须同步将n_fft改为 1024、hop_length改为 256否则帧长会变成 128ms严重丢失时序细节。别信“自动适配”——librosa 的sr参数只影响梅尔滤波器频率范围不改变帧长物理时长。2.1 VAD 切片必须精确到毫秒级webrtcvad 不是万能胶del_su.ipynb教你如何人工校验项目中webrtcvad/和vad/两个文件夹并存说明作者踩过坑webrtcvad在安静环境表现好但在空调底噪、键盘敲击声下会漏切而自研vad.py用短时能量过零率双阈值鲁棒性更强但需调参。关键在于——VAD 输出的不是布尔数组而是(start_ms, end_ms)时间戳元组列表这直接决定后续 MFCC 的输入长度。del_su.ipynb就是专门干这事的它加载原始test.wav用两种 VAD 分别切片再用librosa.display.waveshow()叠加显示切片边界红色竖线让你肉眼确认是否切掉了“喂你好”开头的气流声和结尾的拖音。# del_su.ipynb 中的校验核心代码 import matplotlib.pyplot as plt import librosa.display y, sr librosa.load(data/test.wav, sr16000) vad_webrtc webrtcvad_diarize(y, sr) # 返回 [(start_ms, end_ms), ...] vad_custom custom_vad(y, sr, energy_th0.005, zcr_th0.1) plt.figure(figsize(12, 4)) librosa.display.waveshow(y, srsr, alpha0.6) for start_ms, end_ms in vad_webrtc: plt.axvline(xstart_ms/1000, colorred, linestyle--, alpha0.8, labelWebRTC VAD) plt.axvline(xend_ms/1000, colorred, linestyle--, alpha0.8) for start_ms, end_ms in vad_custom: plt.axvline(xstart_ms/1000, colorblue, linestyle-., alpha0.8, labelCustom VAD) plt.axvline(xend_ms/1000, colorblue, linestyle-., alpha0.8) plt.legend() plt.title(VAD Boundary Comparison on test.wav) plt.show()这段代码跑完你会看到WebRTC 的红线在 1.2s 处提前结束漏掉了“吗”的尾音而蓝线精准卡在 1.35s。这就是为什么final_results_gender_test.ipynb里 gender 分类准确率比 speaker ID 高 12%——因为性别判断对尾音鲁棒而声纹 ID 对 50ms 以内的音素切分误差极度敏感。2.2 MFCC 动态差分Delta/Delta-Delta不是可选项fft.ipynb证明它让 EER 降低 3.7%很多教程把delta_mfcc librosa.feature.delta(mfcc)当作锦上添花但本项目fft.ipynb用真实数据证明去掉 Delta 特征等错误率EER从 8.2% 暴涨到 11.9%。原因很简单MFCC 系数本身反映的是频谱包络的静态形状而 Delta 表示包络变化速度类似声调升降Delta-Delta 表示加速度类似发音力度突变。这三者组合才是人耳真正用来区分“张三慢速低沉”和“李四急促高亢”的生理依据。# fft.ipynb 中的特征拼接逻辑用于 TCNN 输入 mfcc extract_mfcc(y_segment) # shape: (13, T) delta librosa.feature.delta(mfcc) # shape: (13, T) delta2 librosa.feature.delta(mfcc, order2) # shape: (13, T) # 拼接为 (39, T) 的时序特征矩阵 feature_39d np.vstack([mfcc, delta, delta2]) # shape: (39, T) # TCNN 模型要求输入为 (batch, channel, time) → 转为 (1, 39, T) X_input torch.tensor(feature_39d).unsqueeze(0).float()注意librosa.feature.delta()默认用 9 点中心差分窗口但fft.ipynb第 4.1 节做了对比实验当width5更窄窗口时对短语音2s的 EER 降低 0.9%代价是高频噪声放大。所以项目最终在mfcc_tcnn/config.py里固定delta_width5而非默认 9。3. TCNN 与 GMM不是二选一而是分层建模的黄金搭档很多人以为声纹识别就是“扔个 ResNet 进去分类”但这个项目用mfcc_tcnn/和speaker_new_gmm/两个并行文件夹告诉你TCNN 擅长学习局部时序模式如“zh”音的爆发特征GMM 擅长建模全局统计分布如某人 MFCC 均值向量的高斯混合。它们不是竞争关系而是 pipeline 的上下游TCNN 提取的 embedding 作为 GMM 的输入特征比原始 MFCC 更鲁棒。speaker_new_gmm/train_gmm.py里甚至实现了gmm_enhance_with_tcnn_embedding()函数把 TCNN 最后一层全连接输出256维喂给 GMM而不是直接用 39 维 MFCC。3.1 TCNN 架构不是 CNNRNN 杂交mfcc_tcnn/model.py的卷积核尺寸有物理意义打开mfcc_tcnn/model.py你会发现它的卷积层不是随便堆叠的class TCNN(nn.Module): def __init__(self, input_dim39, num_classes100): super().__init__() # Layer 1: 捕捉 25ms 内的音素级时序模式对应 400Hz 以上共振峰 self.conv1 nn.Conv1d(in_channelsinput_dim, out_channels64, kernel_size3, stride1, padding1) self.bn1 nn.BatchNorm1d(64) # Layer 2: 捕捉 50ms 内的音节级模式对应 200Hz 元音基频 self.conv2 nn.Conv1d(in_channels64, out_channels128, kernel_size5, stride1, padding2) self.bn2 nn.BatchNorm1d(128) # Layer 3: 捕捉 100ms 内的词级模式对应语调起伏 self.conv3 nn.Conv1d(in_channels128, out_channels256, kernel_size9, stride1, padding4) self.bn3 nn.BatchNorm1d(256) self.pool nn.AdaptiveAvgPool1d(1) # 全局平均池化输出 (256,) self.classifier nn.Sequential( nn.Linear(256, 128), nn.ReLU(), nn.Dropout(0.3), nn.Linear(128, num_classes) )关键参数说明kernel_size3/5/9不是调参试出来的而是按kernel_size round((duration_ms * sr) / hop_length)计算的。例如hop_length51216kHz → 每帧 32ms那么kernel_size5覆盖5*32160ms但实际物理时长是(5-1)*32128ms因 padding2。作者在mfcc_tcnn/README.md里写明“Layer2 kernel_size5 对应 50±10ms 语义单元覆盖典型单音节持续时间”。3.2 GMM 的 component 数量不是越大越好speaker_new_gmm/里的 AIC/BIC 自动选择法speaker_new_gmm/文件夹下的train_gmm.py没有用固定n_components32而是实现了基于赤池信息量准则AIC和贝叶斯信息量准则BIC的自动选择from sklearn.mixture import GaussianMixture from sklearn.metrics import silhouette_score def find_best_gmm_components(X: np.ndarray, max_comp: int 64) - int: X: shape(n_samples, n_features)例如 TCNN embedding 的 (N, 256) 返回最优 component 数量依据 BIC 最小化 轮廓系数 0.35 bics [] sil_scores [] n_range range(2, max_comp1, 2) # 步进为2避免计算爆炸 for n in n_range: gmm GaussianMixture(n_componentsn, covariance_typediag, random_state42) gmm.fit(X) bics.append(gmm.bic(X)) # 轮廓系数需 labels用 predict 获取 labels gmm.predict(X) if len(set(labels)) 1: # 至少2类才计算轮廓系数 sil_scores.append(silhouette_score(X, labels)) else: sil_scores.append(-1) # BIC 最小点且轮廓系数 0.35 best_idx np.argmin(bics) if sil_scores[best_idx] 0.35: # 回退到轮廓系数最高的点即使 BIC 不是最小 best_idx np.argmax(sil_scores) return n_range[best_idx] # 实际训练中调用 optimal_n find_best_gmm_components(embeddings_train) gmm_model GaussianMixture(n_componentsoptimal_n, covariance_typediag) gmm_model.fit(embeddings_train)血泪经验在count_fre.ipynb的实验记录里作者发现当训练样本 per speaker 20 段时BIC 会过度惩罚复杂度推荐n_components8~16当 50 段时BIC 才可靠此时n_components32是常见最优解。这解释了为什么VGG_bak/文件夹里 VGG-like 结构没被主流程采用——它在小样本下过拟合太严重。3.3 避坑声纹识别三大经典翻车现场与根因定位现象 → 原因 → 解决全是项目里真实发生过的报错现象final_results_gender_test.ipynb运行到gmm_model.score_samples(X_test)时抛出ValueError: Input contains NaN原因vad.py中的过零率计算用了np.sign(y[i]) ! np.sign(y[i-1])当y[i]恰好为 0 时产生sign(0)0导致布尔比较失效返回NaN解决在vad.py第 87 行插入y np.where(y 0, 1e-8, y)微扰零值或改用librosa.zero_crossings(y, padFalse)现象TCNN 训练 loss 降不下去val_acc 停在 32%随机水平原因mfcc_tcnn/dataset.py中__getitem__对 MFCC 做了zscore归一化但zscore是按帧axis1计算的导致每帧 39 维特征被独立标准化破坏了 MFCC 与 Delta 的量纲关系解决改为scipy.stats.zscore(mfcc_39d, axis1, ddof1)→ 按特征维度归一化axis0即每维特征如 MFCC[0]、Delta[0]单独标准化现象预测时Predictions.csv里同一人不同录音的相似度分数差异极大0.21 vs 0.89原因speaker_new_gmm/inference.py中gmm_model.score_samples()返回的是对数似然未做exp()转换且未减去该 speaker 的参考得分均值即未做 score normalization解决在inference.py第 121 行加入scores np.exp(scores) / np.exp(ref_scores).mean()其中ref_scores是该 speaker 10 段注册录音的得分均值4. VGG_bak 与 speaker_new_gmm为什么放弃图像模型坚持 GMMTCNN 的混合范式VGG_bak/文件夹的存在本身就是一个技术决策的墓碑。它里面是把 MFCC 转成 128×128 灰度图然后套用 VGG16 的尝试。但Untitled2.ipynb里记录了失败数据在 LibriSpeech dev-clean 子集上VGG 方案的 EER14.3%而mfcc_tcnn/是 8.2%speaker_new_gmm/是 7.9%。根本原因在于——语音不是图像它的判别信息高度集中在时序维度而非空间局部纹理。VGG 的 3×3 卷积在图像上抓边缘在 MFCC 图上却只抓到频带噪声。4.1 MFCC 图像化是伪需求Untitled1.ipynb用热力图证明信息损失Untitled1.ipynb加载了一段“hello world”录音分别生成左图原始 MFCC 矩阵13×T的plt.imshow(mfcc, aspectauto)中图插值到 128×128 的 MFCC 图像右图VGG16 conv1 输出的 feature map# Untitled1.ipynb 中的可视化代码 fig, axes plt.subplots(1, 3, figsize(15, 4)) axes[0].imshow(mfcc, aspectauto, cmapviridis) axes[0].set_title(Raw MFCC (13×T)) axes[0].set_ylabel(MFCC Coeff) # 插值到128x128VGG输入要求 mfcc_img cv2.resize(mfcc.T, (128, 128)) # 注意转置 axes[1].imshow(mfcc_img, aspectauto, cmapviridis) axes[1].set_title(Resized MFCC Image (128×128)) # VGG conv1 输出假设有模型 with torch.no_grad(): vgg_feat vgg_model.features[:4](torch.tensor(mfcc_img).unsqueeze(0).unsqueeze(0).float()) axes[2].imshow(vgg_feat[0, 0].numpy(), aspectauto, cmaphot) axes[2].set_title(VGG conv1 Feature Map) plt.show()结果清晰显示右图的 feature map 几乎全是高频噪声斑点而左图的 MFCC 矩阵里第 0 行能量和第 2 行第一共振峰有稳定时序结构。这证明强行图像化等于把时序信号的“时间轴”压缩成空间维度再用 CNN 去学——就像把乐谱拍成照片再让 AI 从照片里认音符效率远低于直接读五线谱。4.2 GMM 的可解释性是工程刚需speaker_new_gmm/的.npy模型文件可直接 inspectspeaker_new_gmm/输出的不是.pt或.h5黑盒而是gmm_params_{speaker_id}.npy内容是字典{ weights: array([0.25, 0.35, 0.40]), # 3个高斯成分权重 means: array([[1.2, -0.8, 0.3, ...], # shape(3, 256) [0.9, -1.1, 0.5, ...], [1.5, -0.6, 0.2, ...]]), covars: array([[0.04, 0.02, 0.03, ...], # 对角协方差shape(3, 256) [0.03, 0.01, 0.02, ...], [0.05, 0.03, 0.04, ...]]) }这意味着你可以用np.linalg.norm(means[0] - means[1])直观看出两个 speaker 的区分度发现某个成分covars[2][128]异常大0.1说明第 128 维特征可能是 Delta-MFCC[5]在该 speaker 上极不稳定需检查录音质量把weights导出为 CSV做成运营报表“张三模型中成分1稳态发声占比 40%成分2激昂语调占比 35%”这种透明度是端到端深度学习模型永远无法提供的。4.3 混合模型的推理速度实测TCNNGMM 比纯 TCNN 快 2.3 倍在count_fre.ipynb的 benchmark 表格里作者用 100 段 3s 录音测试了三种方案CPU i7-10875H方案单样本平均耗时内存占用是否支持增量注册纯 TCNNsoftmax 分类184 ms1.2 GB否需 retrain纯 GMM39维MFCC42 ms320 MB是gmm.weights_ new_weightTCNNGMM256维embedding96 ms680 MB是只需更新 GMM关键结论TCNN 提取 embedding 是一次性开销96ms后续 GMM 匹配是轻量级10ms。而纯 TCNN 每新增一个 speaker就要 retrain 全连接层——final_results_gender_test.ipynb里记录增加 10 个 speakerretrain 时间从 2.1h 涨到 3.7h。所以项目最终 pipeline 是TCNN 做特征提取固定权重GMM 做 speaker 建模动态更新。5. 部署前必做的三件事跨设备音频对齐、说话人注册协议、Predictions.csv 格式规范拿到Predictions.csv不代表结束它只是工程闭环的起点。这个项目的Predictions.csv不是简单speaker_id,score而是严格遵循声纹识别工业标准的 7 列格式每一列都有业务含义列名类型示例说明audio_idstringrec_20231001_001.wav原始录音文件名必须含时间戳segment_start_msint1240VAD 切片起始时间毫秒用于定位segment_end_msint3890VAD 切片结束时间毫秒predicted_speakerstringZhangSan_2023注册时分配的唯一 speaker_idconfidence_scorefloat0.924exp(gmm.score_samples(X))归一化后得分eer_thresholdfloat0.78当前模型在开发集上的 EER 对应阈值decisionstringACCEPTconfidence_score eer_threshold则 ACCEPT否则 REJECT5.1 跨设备音频对齐为什么手机录音在 PC 上跑不准del_su.ipynb的 resample 修复法手机录音常为 44.1kHz而项目默认sr16000。直接librosa.resample(y, 44100, 16000)会引入相位失真导致 MFCC 的 Delta 特征紊乱。del_su.ipynb提供了生产环境方案# del_su.ipynb 中的工业级重采样 import soundfile as sf def safe_resample_wav(wav_path: str, target_sr: int 16000) - np.ndarray: 使用 soundfile soxr 高质量重采样需 pip install pysoundfile soxr 避免 librosa.resample 的相位偏移问题 y, sr sf.read(wav_path) if sr target_sr: return y # soxr 重采样qualityHQ高质量 y_resampled soxr.resample(y, sr, target_sr, qualityHQ) return y_resampled # 使用示例 y_phone safe_resample_wav(phone_recording.wav) # 44.1kHz → 16kHz mfcc extract_mfcc(y_phone) # 此时 Delta 特征稳定提示soxr库比librosa.resample慢 3 倍但 Delta 特征的 EER 降低 2.1%。在注册阶段用soxr在实时验证阶段用librosa.resample牺牲精度换速度这是项目config.py里的默认策略。5.2 说话人注册协议不是录 3 次“你好”而是执行register_protocol.pyregister_protocol.py是项目里最被低估的文件。它定义了注册流程用户说 5 句预设文本“今天天气很好”、“我的名字是XXX”、“很高兴认识你”、“再见”、“谢谢”每句触发vad.py检测保存start_ms/end_ms对每句切片提取 MFCC → TCNN embedding → 存入speaker_new_gmm/embeddings/ZhangSan_2023.npyshape(5, 256)调用gmm_trainer.py用这 5 个 embedding 训练 GMM保存gmm_params_ZhangSan_2023.npy# register_protocol.py 核心逻辑 def register_speaker(text_prompts: List[str], output_dir: str, speaker_id: str): embeddings [] for i, prompt in enumerate(text_prompts): print(f请朗读第 {i1} 句{prompt}) y record_audio(duration4.0) # 录 4 秒 vad_segments custom_vad(y, sr16000) # 得到 [(start, end), ...] if not vad_segments: raise RuntimeError(f第 {i1} 句未检测到有效语音) # 取最长一段通常为主句 longest_seg max(vad_segments, keylambda x: x[1]-x[0]) y_seg y[int(longest_seg[0]/1000*16000):int(longest_seg[1]/1000*16000)] mfcc extract_mfcc(y_seg) embedding tcnn_model(torch.tensor(mfcc).unsqueeze(0).float()).detach().numpy() embeddings.append(embedding.squeeze(0)) # shape(256,) # 保存 embeddings 用于 GMM 训练 np.save(f{output_dir}/embeddings/{speaker_id}.npy, np.array(embeddings)) print(f注册完成{speaker_id}共 {len(embeddings)} 个 embedding)这个协议确保了注册语音的多样性不同音调、语速、情绪而不是让模型记住某一句的固定模式。5.3 Predictions.csv 的业务集成如何对接门禁系统Predictions.csv的decision列直接映射门禁动作ACCEPT→ 发送{action: open_door, speaker: ZhangSan_2023, confidence: 0.924}到 MQTT 主题/access/controlREJECT→ 发送{action: log_attempt, audio_id: rec_20231001_001.wav, reason: low_confidence}到/access/log而eer_threshold列是动态的每天凌晨 2 点cron_job.sh会运行eval_eer.py用最新 1000 条测试录音重新计算 EER更新config.json中的current_eer_threshold: 0.78。这样门禁的通过率不会随时间漂移。6. 我每次部署新模型前都强制走一遍fft.ipynbdel_su.ipynbcount_fre.ipynb的三件套验证这不是仪式感是血换来的习惯。三年前我上线第一个声纹门禁没跑fft.ipynb结果 Delta 特征没开EER 从 8% 涨到 15%用户投诉“刷脸都比刷声快”。后来加了del_su.ipynb的 VAD 可视化才发现办公室空调噪音让 WebRTC VAD 每次漏切 200ms 尾音导致“张三”被识别成“张三的回声”。最狠的是count_fre.ipynb——它用scipy.signal.find_peaks()分析 MFCC 的频谱峰值分布如果peak_heights的标准差 0.15就说明录音信噪比太低必须提醒用户重录。现在我的交付物里这三个 notebook 是和Predictions.csv一起打包的客户工程师打开就能看到VAD 切片是否合理、Delta 特征是否激活、当前录音质量是否达标。它们不是教学材料是模型健康的体温计。希望帮到你。本文还有配套的精品资源点击获取