一个浏览器标签页里的三个音频工具

约 9 分钟

完整过程

视频把三个工具从头到尾跑了一遍：一首歌拆成阿卡贝拉和伴奏，一段人声录音把声音背后的房间抽掉，还有一行打出来的文字被读出来。一次跑完，一台机器 — 而这正是重点，因为那台机器是你的，不是我们的。

录屏证明不了的那部分

一段工具能用的视频，只说明工具能用。它没法告诉你文件去了哪里，而那恰恰是唯一值得怀疑的那句话 — 每个免费音频网站都会说些关于隐私的安慰话，而其中大多数仍然先把你的录音放到服务器上。

这一条你可以从自己这边验证，不必听任何人的保证：

1. 打开三个工具中的任意一个，按 F12 (⌥⌘I （Mac 上），然后选 网络 面板。
2. 勾上 禁用缓存，这样模型下载会出现在列表里，而不是直接从磁盘读走。
3. 把文件拖进去，让它跑完。
4. 看那份列表。每一条请求都会是 GET，而且每一条要的都是这个站点上的模型或脚本。

你要看的是「缺了什么」：没有 POST，没有任何把你的音频放在请求体里的请求，完全没有上传进度。流量是单向的。是模型被取到你文件所在的地方，而不是你的文件被送到模型所在的地方——这个先后顺序就是全部的架构差别 — 它不是一条下个季度可能悄悄改掉的留存政策。

模型缓存好之后把网线拔了，工具照样能用。这是同一个事实，从另一头看过去。

这要你付出什么

在本地跑模型不是免费的 — 只是计费方式不同。你付出的不是我们的服务器时间，而是首次访问的一次下载，加上处理过程中你自己的处理器：

工具	首次访问下载量	上限
人声分离	约 52 MB — 12 MB 的运行时，加上两个 20 MB 的模型文件，每条音轨一个	5 分钟，300 MB
降噪	约 16 MB	5 分钟，300 MB
文字转语音	传输量约 64 MB	每次生成 500 字符

每个工具只下载一次，之后由浏览器缓存，所以第二次访问立刻就能开始，也不需要联网。长度上限和下载是同一个原因：一段 5 分钟的立体声音频展开成浮点数之后，已经是单个浏览器标签页里很大的一块东西，而整首歌会直接终结这个会话，而不是排在付费墙后面等着。先用任意编辑器把你要的那段切出来，再送进去。

把文字转语音的模型弄上静态托管，最后成了这个项目里更难的那一半。那段经历 — 每文件 25 MiB 的墙、跨源隔离，以及一个你问它压缩情况时会给出与事实相反答案的托管平台 — 另写了一篇.

把一首歌拆成两条音轨

人声分离接收一段混音，返回两个文件：单独取出的人声，和剩下的伴奏。它靠的是识别而不是相减，而这个区别决定了它在你的曲子上能不能行。

大家熟悉的那个免费方法 — Audacity 内置的那个 — 是相位抵消。它把左右声道共有的部分减掉，前提假设是主唱在正中间。有时候确实是。但底鼓、贝斯和军鼓通常也在正中间，而且贝斯在大约 120 Hz 以下常常是有意合成单声道的，于是它们一起被带走。单声道文件根本没有可相减的对象；人声浸在立体声混响里时，混响活了下来而干声消失了，听起来比不处理还糟。我们写过 在 Audacity 里怎么做，以及什么时候行不通，还附了一个用你自己文件做的 30 秒测试。

分离模型学过歌唱的人声在时间和频率上长什么样，所以它是把每一部分重建出来，而不是拿一个去抵消另一个。这就是它能应付单声道录音、偏离中心的人声和重混响的原因，也是伴奏能保住低频的原因。它做不到的是凭空造出混音里本来就没有的细节：当人声和吉他在同一瞬间占据同一条窄频带时，总得把它判给其中之一，而这个判断，就是分离伪影的来源。

把房间从录音里拿掉

降噪是给语音用的，不是给音乐用的。它按短帧看录音，对每个频带估计有多少是人声、多少是房间，再据此给每个频带施加增益。稳定、重复的噪声 — 风扇嗡鸣、空调、电源交流声、麦克风嘶声 — 是这类模型读得最可靠的，因为它的模式是静止的，而语音一直在动。

值得理解的那个控件是 微调，它设置的是以分贝为单位的衰减上限：模型最多被允许去掉多少。它之所以存在，是因为降噪的坏结果不是残留的嘶声，而是一个被嚼成水糊糊、金属味的声音。给削减量设上限，声音保住了，噪声留下一点——对任何需要一个人连听半小时的素材来说，这通常是更划算的取舍。

有一段 9 秒的室内录音放在 降噪页面 上，播放过程中可以在处理前和处理后之间来回切。在句与句之间 — 9 秒里有 27 处间隙，那正是噪声最容易听出来的地方 — 底噪下降约 17 dB。而语音本身回来时，比进去时只低了 0.5 dB。第二个数字才是你在任何降噪工具上都该核对的，包括这一个：把整段录音调小，底噪看上去总会更好，但 0.5 dB 不是靠调小换来的。

它治不了的是混响。回声是人声的副本，而不是坐在人声背后的东西，所以模型没有可分离的对象。那个问题靠把麦克风挪近解决，不是事后解决。

把打出来的文字读出来

第三个工具方向相反：进去的是文字，出来的是音频。有 19 个音色，分属 14 个口音族，每次生成上限 500 字符 — 大约 80 个词，或者约 30 秒的语音。那是一句旁白或一条字幕，也正是多数人真正需要的形态；而且一行一行改稿子，比重新剪一个长文件容易。

它也能从一小段样本里克隆音色，而这段样本遵守和这里其他一切相同的规则：在标签页里读取，不发往任何地方。找个安静的地方录。克隆会连同音色一起复现房间和说话方式，所以背景里有风扇的样本，做出来的声音里就带着风扇。

哪些情况下浏览器是错的地方

• 一整张专辑。 一次 5 分钟覆盖得了大多数单曲，但四十首仍然是四十次。批量工作该交给一台你可以放着跑的机器。
• 四条或更多音轨。 分离器把人声和其余一切分开。要把鼓、贝斯和别的声部单独分出来，需要另一种模型，以及超出一个标签页该承担的算力。
• API。 从构造上就没有可调用的端点 — 因为根本没有服务器在干活。
• 手机上按流量计费的连接。 首次下载是实打实的，而文字转语音是重的那个。
• 精细的韵律控制。 没有 SSML，没有音素编辑器，也不能逐词调音高。你靠改写文本来控制朗读。

常见问题