这类问题我又碰上了一次。用 faster-whisper 1.0.3 的 large-v3 转写客服电话录音，音频是 8kHz 单声道 μ-law 编码的 wav，直接喂进去转出来的字错得离谱，「退款」被识别成「推款」。同一段录音用播放器听是清楚的，试过加 vad_filter 和调 beam_size 到 5 都没有改善。
第一反应是「直接重采样到 16k 只是插值，补不回高频信息」，验证下来不成立。
把日志和配置对完，能解释这个现象的基本就这几处。wav 头里写的是 PCM 但数据实际是 μ-law，波形被当噪声解码；8kHz 带宽本身只有 4kHz，模型训练集以 16kHz 为主；静音段底噪被放大后干扰了 VAD 的切分点。
上来先看 wav 头里的编码格式与采样率
python -c "import wave;w=wave.open('call.wav');print(w.getframerate(), w.getsampwidth(), w.getnchannels(), w.getcomptype())"转成 16k 的 16bit PCM 再送转写
ffmpeg -i call.wav -ar 16000 -ac 1 -c:a pcm_s16le call16.wav滤波切除 300Hz 以下的低频噪声
ffmpeg -i call16.wav -af "highpass=f=300,lowpass=f=3400" -ar 16000 call_clean.wav末了用同一段对比两种输入的识别结果
python -c "from faster_whisper import WhisperModel;m=WhisperModel('large-v3');print(m.transcribe('call_clean.wav',language='zh')[0])"恢复的判定其实很直接。转写文本里「退款」等关键词全部正确，人工抽听 10 分钟音频的错误字比例降到 5% 以内，时间戳连续。
μ-law 文件常常顶着 PCM 的 wav 头，工具链会安静地按错误格式解码，先 ffprobe 一次拿到底层编码再决定怎么转。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。