使用mic-recorder-to-mp3录制MP3调用Google Speech-to-Text报编码配置错误

出现bad encoding报错和录制的MP3文件本身是否损坏没有关系，本质是两个API配置和库输出不匹配的问题：

• Google Cloud Speech-to-Text 现行的校验逻辑下，直接在请求配置里写encoding: 'MP3'属于废弃的传参方式，会直接被网关拦截抛出编码错误
• 你代码里写的48000Hz采样率，和mic-recorder-to-mp3实际输出的44100Hz采样率参数不匹配，就算编码校验通过，也会出现识别精度错误
• 这个库默认输出单声道音频，代码里没有补充声道数的配置项，也是潜在的校验报错来源

最小改动兼容方案 #

直接调整请求配置，不需要修改前端录制逻辑：

1. 把原来硬编码的MP3编码字段，替换为未指定编码的枚举值，让API自动解析文件内置的编码元数据
2. 采样率参数修改为和实际输出匹配的44100Hz
3. 补全单声道的配置项，跳过声道校验
   调整后的可运行配置片段：

const config = {
    enableWordTimeOffsets: true,
    sampleRateHertz: 44100,
    encoding: 'ENCODING_UNSPECIFIED',
    languageCode: 'en-US',
    audioChannelCount: 1
};

这种传参方式是Google官方当前对MP3格式文件的兼容要求，绕过了之前对MP3编码枚举值的废弃校验逻辑，不会触发bad encoding的报错。

长期稳定性优化 #

如果需要更高的识别兼容性，可以在前端拿到录制的MP3流后，直接转成Google支持最完善的16bit线性PCM（WAV格式），对应把配置里的encoding改成LINEAR16即可，这种格式不存在编码适配的历史兼容问题。

• 不要照搬旧的博客或者SDK示例里的MP3编码写法，相关的MP3编码枚举值已经被标记为废弃，现在传参就会触发网关校验失败
• 用本地base64直传的短请求模式，总音频时长不要超过60秒，超过时长就算配置正确也会出现识别结果缺失

内容的提问来源于stack exchange，提问作者Rayhan Memon