Python语音识别系统实现：录音、MFCC与STT接口

脚本专家

在Python里做语音识别，常见链路是录音、音频预处理与特征展示、调用语音转文本接口。原文给出的示例覆盖了sounddevice录音、librosa提取MFCC、Google Speech-to-Text识别三段，但代码片段之间存在导入缺失和参数衔接问题。下面按可复现的模块重组这些实现，保留原文的库、参数和调用逻辑，并补上排查点。

一、环境与依赖
原文给出的安装命令是：

2. pip install SpeechRecognition
3. pip install google-cloud-speech

复制代码

代码中还引用了sounddevice、soundfile、librosa、matplotlib等库，原文未逐一给出安装命令，复现前需要确保这些依赖已可用。录音文件路径原文固定为/mnt/data/recording.wav，目录必须存在且有写权限。

二、录音模块
原文用sounddevice设置采样率44100、录音时长5秒、双通道，然后通过sd.wait()等待录音结束，最后用soundfile.write保存wav。原片段调用了soundfile.write却没有给出import soundfile，直接运行会触发NameError；整理后的代码如下：

2. import sounddevice as sd
3. import soundfile
5. fs = 44100
6. duration = 5
8. print('开始录音...')
9. recording = sd.rec(int(duration * fs), samplerate=fs, channels=2)
10. sd.wait()
11. print('录音完成')
13. recording_path = '/mnt/data/recording.wav'
14. soundfile.write(recording_path, recording, fs)
15. print(f'录音已保存至 {recording_path}')

复制代码

这里的fs同时参与采样点数和文件写入采样率，channels=2表示双通道录音。原文后续识别配置没有显式声道参数，因此复现时要确认送入识别接口的音频与配置匹配。

三、音频加载、归一化与MFCC
原文用librosa.load(recording_path, sr=None)加载录音，sr=None表示沿用文件原始采样率；随后用librosa.util.normalize做归一化，再通过librosa.feature.mfcc提取MFCC，并用matplotlib绘图展示。代码结构如下：

2. import librosa
3. import librosa.display
4. import matplotlib.pyplot as plt
6. audio, sr = librosa.load(recording_path, sr=None)
7. audio = librosa.util.normalize(audio)
8. mfccs = librosa.feature.mfcc(y=audio, sr=sr)
10. plt.figure(figsize=(10, 4))
11. librosa.display.specshow(mfccs, x_axis='time', y_axis='linear')
12. plt.colorbar(format='%+2.0f dB')
13. plt.title('MFCC')
14. plt.show()

复制代码

从原文流程看，MFCC主要用于特征提取和可视化，并没有作为Google Speech-to-Text的输入；识别阶段直接读取wav文件二进制。因此MFCC图更适合调试音频质量和观察特征，不是该示例的识别输入。

四、调用Google Speech-to-Text
原文使用google.cloud.speech_v1p1beta1，设置project_id和language_code='zh-CN'，创建SpeechClient，读取录音内容构造RecognitionAudio，再构造RecognitionConfig并调用recognize。整理后如下：

2. from google.cloud import speech_v1p1beta1 as speech
4. project_id = 'your_project_id'
5. language_code = 'zh-CN'
7. client = speech.SpeechClient(project=project_id)
9. with open(recording_path, 'rb') as audio_file:
10.     content = audio_file.read()
11. audio = speech.RecognitionAudio(content=content)
13. config = speech.RecognitionConfig(
14.     encoding=speech.RecognitionConfig.AudioEncoding.LINEAR16,
15.     sample_rate_hertz=sr,
16.     language_code=language_code,
17.     enable_word_time_offsets=True,
18. )
20. response = client.recognize(config=config, audio=audio)
22. for result in response.results:
23.     print('Transcript: {}'.format(result.alternatives[0].transcript))

复制代码

RecognitionConfig中的encoding指定LINEAR16，sample_rate_hertz使用librosa加载得到的sr，language_code指定中文识别，enable_word_time_offsets开启词级时间偏移。识别结果从response.results中遍历，取result.alternatives[0].transcript输出文本。

五、整合顺序与常见错误
整合时按“录音并保存wav→librosa加载并归一化→提取MFCC并展示→读取wav字节调用STT→遍历response.results”执行即可。原文实战案例重复了这些步骤，核心依赖关系没有变化。

常见问题主要有：1）soundfile未导入导致保存录音时报NameError，补import soundfile；2）/mnt/data/recording.wav路径不存在或无权限导致写文件失败；3）识别配置使用sr而不是录音变量fs，若混用会让sample_rate_hertz与音频实际采样率不一致；4）project_id仍是占位符，且原文未展示Google客户端认证配置，复现时要检查凭据和客户端初始化；5）录音为双通道，而RecognitionConfig未显式配置声道，需保证音频输入与接口参数一致；6）config指定LINEAR16，但原文没有转码步骤，需确保wav文件编码与配置字段对应。

从实现分层看，录音、MFCC展示和云STT调用是三个独立环节，替换识别后端时只需调整RecognitionConfig和客户端调用；保留MFCC可视化则便于在识别失败时先检查音频是否被正确加载和归一化。原文提到的应用场景包括智能音箱、智能手机和自动驾驶汽车，这个示例适合作为本地录音加云接口识别的入门骨架，但在实际使用中应优先处理导入、路径、采样率和认证这几类可复现问题。

热心网友1

感谢整理，这篇把录音、MFCC 和语音转文本拆成可复现模块，还点出了导入缺失、路径权限、采样率衔接和认证占位符这些实际容易卡住的地方，很实用。补充几个复现时的检查点：录音是双通道，而 LINEAR16 送入识别接口时常见单声道要求，建议要么录音时 channels=1，要么在识别前转成单声道并确认编码、采样率一致；sample_rate_hertz 用 sr 可以，但要确保它和最终送入接口的音频实际采样率一致，不要和录音时的 fs 混用；Google 客户端除了 project_id，还要确认凭据环境已配好；MFCC 图主要用来调试音频和观察特征，不参与识别；另外 SpeechRecognition 和 google-cloud-speech 是两条不同路线，示例实际走的是后者。最后一条常见问题被截断了，如果把声道一致性、编码格式和接口参数匹配写完整，对复现会更有帮助。

热心网友1

楼主整理得很清楚，尤其是把原文那些导入缺失和参数衔接问题点出来，复现时确实能少踩不少坑。我按自己踩过的经验补几个细节，供参考： 一是声道这个坑比想象中更隐蔽。录音用 channels=2 存成双声道 wav，后面 librosa.load 默认 mono=True，会把音频混成单声道再算 MFCC，所以 MFCC 图看着正常；但送 STT 时读的是原始 wav 文件字节，还是双声道，而 RecognitionConfig 里没有声道参数，LINEAR16 一般按单声道解析，容易识别失败或者结果很奇怪。最省事的做法是录音直接 channels=1，或者在送识别前用 soundfile 读出来取单声道再写一个临时文件，保证“分析用的音频”和“识别的音频”是同一份。 二是采样率。44100 对 MFCC 没影响，但对 STT 不是最优，Google 那边 16000 更稳妥。既然 sr=None 保留了原始采样率，sample_rate_hertz=sr 逻辑上是自洽的，但如果为了识别把音频重采样到 16k，就一定要同步更新这个参数，别一个 44100 一个 16000 混着用。 三是认证。GOOGLE_APPLICATION_CREDENTIALS 环境变量要在启动进程前设好，或者显式传 credentials；project_id 那行占位符不改的话，客户端初始化阶段就会报错，跟音频

热心网友1

感谢整理，这版把录音、MFCC展示和STT调用拆开讲得很清楚，尤其是把导入缺失、采样率衔接和占位符这些问题点出来，对复现很友好。顺着这个流程看，先录音保存、再用librosa做特征展示、最后单独读取wav字节送识别，确实更容易定位问题。补充一个小提醒：如果录音保持双通道，送Google STT前最好确认接口对声道的要求，或者录音时就用单声道，避免sample_rate_hertz和实际音频参数不一致；另外project_id和认证部分建议在复现前先单独跑通客户端初始化。整体很实用，感谢分享。