用 Gradio 搭 TTS、语音克隆这类 WebUI 的人，大概率熟悉这个场景：gr.Audio 默认输出 WAV，稳妥但体积大，一条音频动辄几 MB。于是顺手把 format 参数改成 mp3，指望体积压到十分之一，结果出来的音频全是噪音。知乎更诡异的是，WAV 路径一直是好的，只有 mp3 出问题，第一反应都会怀疑是 ffmpeg 或 pydub 环境的问题，重装环境也解决不了。
先把结论说清楚：这个 bug 不是新东西，2023 年 5 月引入，藏了超过三年。知乎今年 5 月底，官方才在 6.15.2 里把它修掉。下面把原理、版本考古和现在该怎么办讲清楚。
float32 的音频数据，为什么变成噪音
问题出在 Gradio 落盘音频的中间层。Gradio 内部用 pydub（底层调 ffmpeg）编码 mp3，而 pydub 的 AudioSegment 裸构造器只支持整数 PCM，它会把 sample_width=4 解释成 int32，而不是 float32。GitHubTTS 模型输出的偏偏是 [-1, 1] 范围的 float32 幅度，这些字节按 int32 读出来，幅度变成巨大的随机整数，解码后自然全是噪声。
最早把这件事捅出来的知乎作者也做过验证：绕开 Gradio，直接用 pydub 手动编码同一段数据，结果同样是噪音，说明这是 pydub 处理 float32 时共有的坑，而 Gradio 的责任，是在把数据交给 pydub 之前，少做了一步 int16 转换。知乎
版本考古：真正的起点，比社区说的早一个版本
社区文章把 bug 的引入时间定在 2023 年 2 月的 3.41.0，认为是这个版本给 Audio 组件新增了 format 参数。知乎我把 PyPI 上的官方 wheel 包按版本逐个解包对比，结论不太一样：2023-05-16 发布的 3.31.0，audio_to_file 里已经出现「只对 WAV 做 int16 转换」的条件分支，而再往前一个的 3.30.0，还是不分格式统一转换。PyPI也就是说，真正的起点是 3.31.0，比社区说法早一个版本，最后一个安全版本是 3.30.0。这个 bug 从 3.31.0 一路活到 6.15.1，横跨 3.x、4.x、5.x 和 6.x 四条版本线。
官方修复了什么
2026-05-28 发布的 6.15.2，修复只有一处改动：audio_to_file 对所有输出格式统一执行 int16 转换，不再只管 WAV。Gradio官网PyPI新的转换函数还做了两件顺手的事：按峰值幅度归一化，避免乘 32767 后溢出；纯静音段直接输出全零，防止除零产生 NaN 噪声。这等于把第二个坑也一起堵上了——有些 TTS 模型输出的 float 幅度是 int16 量级的数值，在老版本上即使走 WAV 也可能溢出回绕出杂音。GitHub修完之后，编码出来的音频波形和输入一致，mp3、flac、ogg 都正常了。
现在该怎么办
先查版本：终端里跑一句 pip show gradio。
版本 ≥ 6.15.2：放心用 format=“mp3”，flac、ogg 也没问题，不需要任何补丁。
版本在 3.31.0 到 6.15.1 之间：优先考虑升级。Gradio 迭代很快，2026-08-24 刚发的 6.26.0，九个月里已经是第 26 个小版本，升级前先在测试环境过一遍自己项目的核心链路。PyPI
暂时不能升级：可以在 Gradio 启动前打 monkey patch，替换 audio_to_file 补上 int16 转换，社区文章里已经封装好现成模块，复制进来调用一次就行。知乎
最后提醒一句：如果你之前遇到过「Gradio 输出音质不太对劲」又说不清原因，很可能就是中的这个招。这次的经验也值得记住——默认参数往往是安全路径，非默认参数背后，可能藏着官方三年都没发现的分支。
