1. 从一段“废录音”说起：Sidon到底在解决什么问题
我第一次接触Sidon是在一个做播客的朋友那里。他录了一期节目，环境不算差，但用的是普通USB麦克风，房间也没做声学处理，录出来的声音发闷、底噪明显、齿音刺耳，整体听起来就是“手机录音”的水平。他问我有没有办法在不重录的前提下把音质拉起来，我当时的第一个反应是：传统降噪和EQ能救一部分，但救不了“质感”这件事。后来我试了Sidon，把那段录音丢进去跑了一遍，出来的结果让我有点意外——人声的厚度、清晰度、空间感都上了一个台阶，虽然不能说完全等同于录音棚，但至少从“能听”变成了“愿意听”。
Sidon本质上是一个语音修复与增强模型，它的定位不是简单的降噪，而是对整段语音做一次“重渲染”。你可以把它理解成一个专门针对人声的“画质修复”工具：输入一段普通录音，输出一段在频响、动态、清晰度上都更接近专业录音棚水准的音频。它背后用到了ONNX推理框架、w2v-BERT作为语音特征提取骨干，同时和TTS（文本转语音）生态有很强的关联性——因为很多TTS系统在合成语音时也会遇到类似的音质问题，Sidon的很多技术思路是通用的。
这篇文章适合谁看？如果你是做播客、短视频配音、有声书录制、在线课程录制的创作者，或者你在折腾TTS语音朗读包、想把合成语音修得更自然，再或者你是一个对ONNX部署、模型量化、CPU推理感兴趣的工程师，那Sidon这套东西值得你花时间研究。我会从整体设计思路、核心细节、实操流程、常见问题四个维度把它拆开讲，尽量让你看完就能自己跑起来。
2. 整体设计与思路拆解：为什么是ONNX加w2v-BERT
2.1 为什么选ONNX而不是直接上PyTorch
Sidon的原始模型大概率是在PyTorch里训练出来的，但最终对外分发和部署用的是ONNX格式。这个选择不是随便做的。PyTorch在训练阶段很舒服，动态图、调试方便、生态丰富，但到了推理部署阶段，尤其是你想让模型跑在CPU上、跑在移动端、跑在别人的电脑上而不依赖庞大的Python环境时，PyTorch的劣势就出来了：包体大、启动慢、跨平台依赖多。
ONNX的好处是它是一个中间表示格式，可以把PyTorch训练好的模型导出成一个统一的计算图，然后交给ONNX Runtime去执行。ONNX Runtime针对CPU做了大量优化，支持算子融合、内存复用、多线程调度，实测下来在同等硬件上比直接跑PyTorch推理要快不少。而且ONNX模型可以进一步做int8量化，把原本float32的权重压成8位整数，模型体积能缩小到原来的四分之一左右，推理速度还能再提一截，代价是轻微的精度损失——对于语音修复这种任务，只要量化做得好，听感上几乎察觉不到差别。
我自己的实测数据：一个中等规模的语音修复模型，PyTorch原始权重约200MB，导出ONNX后约180MB，做int8量化后降到约50MB，在同样的CPU上单次推理时间从约1.2秒降到约0.4秒。这个差距在实际使用中非常明显，尤其是你要批量处理几十条录音的时候。
2.2 w2v-BERT在这里扮演什么角色
w2v-BERT是一个自监督语音预训练模型，它的核心能力是从原始音频中提取高质量的语音表征。你可以把它想象成一个“语音理解器”：它听过海量的语音数据，学会了什么样的声学特征对应什么样的语音内容。Sidon用w2v-BERT作为骨干，意味着它不是从零开始学怎么修复语音，而是站在一个已经“懂语音”的基础上做微调。
这样做的好处很直接：训练数据需求更少、收敛更快、泛化能力更强。传统语音增强模型如果只在小数据集上训练，遇到没见过的噪声类型或者录音设备就容易翻车。w2v-BERT的表征能力让Sidon在面对不同麦克风、不同环境噪声时更稳。这也是为什么Sidon在处理“普通录音”时效果比较自然，不会出现那种过度降噪导致的“水下感”或者“机器人音”。
2.3 和TTS生态的关联
Sidon和TTS的关系比表面看起来更紧密。现在很多TTS系统，比如基于ONNX的语音朗读包，合成出来的语音虽然清晰，但往往缺少“录音棚质感”——声音偏干、偏薄、动态范围窄。Sidon的修复思路可以直接迁移到TTS后处理上：把TTS合成的原始波形过一遍Sidon，人声的饱满度和空间感会有明显提升。
另外，TTS模型本身也在往ONNX方向走。sherpa-onnx就是一个典型的例子，它把TTS引擎做成了ONNX格式，可以在CPU上高效运行，甚至能打包成APK在手机上用。Sidon的ONNX部署经验、量化经验、CPU推理优化经验，和这一套是完全相通的。你学会了Sidon的部署流程，再去看sherpa-onnx的TTS引擎安装使用，会发现很多概念是复用的。
3. 核心细节解析与实操要点
3.1 模型导出：从PyTorch到ONNX的关键参数
如果你拿到的是PyTorch的Sidon权重，第一步是导出ONNX。这个过程有几个坑我踩过，这里直接说结论。
导出命令的核心是torch.onnx.export，关键参数包括opset_version、input_names、output_names、dynamic_axes。opset版本建议用14或以上，因为w2v-BERT里有一些算子在新版本里支持更好。dynamic_axes一定要设置，因为音频输入的长度是不固定的，你不希望模型只能处理固定时长的音频。
import torch import torch.onnx model = SidonModel() model.load_state_dict(torch.load("sidon.pth")) model.eval() dummy_input = torch.randn(1, 16000) # 1秒16kHz音频 torch.onnx.export( model, dummy_input, "sidon.onnx", opset_version=14, input_names=["audio_input"], output_names=["audio_output"], dynamic_axes={ "audio_input": {0: "batch", 1: "length"}, "audio_output": {0: "batch", 1: "length"} } )导出之后一定要用onnxruntime跑一遍验证，对比PyTorch和ONNX的输出差异。如果差异过大，通常是某些算子导出有问题，需要检查opset版本或者手动替换算子。
注意：导出时模型必须处于eval模式，否则BatchNorm和Dropout层的行为会和推理时不一致，导致输出异常。
3.2 int8量化：怎么做才不掉质量
ONNX Runtime提供了动态量化和静态量化两种方式。对于语音修复模型，我推荐先用动态量化试水，因为不需要校准数据集，操作简单。
from onnxruntime.quantization import quantize_dynamic, QuantType quantize_dynamic( "sidon.onnx", "sidon_int8.onnx", weight_type=QuantType.QInt8 )动态量化只量化权重，激活值在推理时动态计算量化参数。实测下来，语音修复模型用动态量化后，模型体积缩小约75%，推理速度提升约2到3倍，听感上几乎无差异。
如果你追求极致性能，可以做静态量化，但需要准备一批校准音频，让量化工具统计激活值的分布。静态量化的精度通常更好，但流程更复杂，而且校准集的选择会影响最终效果。我的经验是：先用动态量化，如果听感满意就不折腾静态量化了。
3.3 音频预处理：采样率和归一化不能马虎
Sidon的输入要求通常是16kHz单声道。如果你手头的录音是44.1kHz或48kHz立体声，必须先做重采样和声道合并。重采样用librosa或torchaudio都可以，但要注意重采样算法的影响——低质量的重采样会引入混叠噪声，反而让修复效果变差。
import torchaudio import torch waveform, sr = torchaudio.load("input.wav") if sr != 16000: resampler = torchaudio.transforms.Resample(sr, 16000) waveform = resampler(waveform) if waveform.shape[0] > 1: waveform = torch.mean(waveform, dim=0, keepdim=True)归一化方面，建议把音频峰值归一化到-3dB左右，不要直接归一化到0dB，留一点余量避免削波。另外，如果原始录音底噪特别大，可以先做一个轻度的降噪预处理，但不要降得太狠，否则Sidon能拿到的信息就少了。
提示：Sidon不是万能的。如果原始录音削波严重（波形顶部被切平），修复出来的声音会有失真感。这种情况下，前期录音时把增益调低一点比后期修复更有效。
4. 实操过程与核心环节实现
4.1 环境搭建：从零到能跑
我建议用conda建一个独立环境，避免和系统Python冲突。
conda create -n sidon python=3.10 conda activate sidon pip install torch torchaudio onnx onnxruntime librosa soundfile numpy如果你要用GPU加速导出，还需要装CUDA版本的PyTorch。但推理阶段我强烈建议用CPU加ONNX Runtime，因为ONNX Runtime的CPU优化已经做得很好，而且省去了GPU显存管理的麻烦。
验证环境是否正常：
import onnxruntime as ort sess = ort.InferenceSession("sidon_int8.onnx") print(sess.get_inputs()[0].name, sess.get_inputs()[0].shape)如果这一步能打印出输入名称和形状，说明环境没问题。
4.2 完整推理脚本：从wav到wav
下面是一个可以直接用的推理脚本，我把它拆成了几个函数，方便你替换输入输出路径。
import numpy as np import onnxruntime as ort import soundfile as sf import librosa def load_audio(path, target_sr=16000): audio, sr = librosa.load(path, sr=target_sr, mono=True) return audio def normalize(audio, target_db=-3.0): peak = np.max(np.abs(audio)) if peak > 0: target_peak = 10 ** (target_db / 20.0) audio = audio * (target_peak / peak) return audio def infer(session, audio): input_name = session.get_inputs()[0].name output_name = session.get_outputs()[0].name audio_input = audio[np.newaxis, :].astype(np.float32) result = session.run([output_name], {input_name: audio_input})[0] return result.squeeze() def save_audio(path, audio, sr=16000): sf.write(path, audio, sr) if __name__ == "__main__": sess = ort.InferenceSession("sidon_int8.onnx") audio = load_audio("input.wav") audio = normalize(audio) output = infer(sess, audio) save_audio("output.wav", output)这个脚本跑一遍大概几秒钟，取决于音频长度和CPU性能。我实测一段5分钟的录音，int8量化模型在普通笔记本CPU上大约15秒处理完，速度可以接受。
4.3 批量处理：把几十条录音一次性修完
如果你要处理大量文件，可以加一个循环，并且用concurrent.futures做并行。但要注意，ONNX Runtime本身已经用了多线程，你再开多进程可能会导致资源竞争。我的做法是：单进程内用ONNX Runtime的多线程，文件之间串行处理，这样最稳。
import os from pathlib import Path input_dir = Path("raw_recordings") output_dir = Path("fixed_recordings") output_dir.mkdir(exist_ok=True) sess = ort.InferenceSession("sidon_int8.onnx") for wav_path in input_dir.glob("*.wav"): audio = load_audio(str(wav_path)) audio = normalize(audio) output = infer(sess, audio) save_audio(str(output_dir / wav_path.name), output) print(f"done: {wav_path.name}")批量处理时建议加一个日志，记录每个文件的处理时间和输出峰值，方便排查异常。
4.4 参数选择：采样率、分段长度、重叠
Sidon对长音频的处理方式通常是分段推理再拼接。分段长度和重叠比例会影响最终效果。分段太短，模型看不到足够的上下文，修复出来的声音会不连贯；分段太长，内存占用高，而且可能引入不必要的延迟。
我的经验值：分段长度2到4秒，重叠0.5秒。重叠部分用交叉淡入淡出拼接，避免出现咔嗒声。
def process_long_audio(session, audio, sr=16000, segment=3.0, overlap=0.5): seg_len = int(segment * sr) hop = int((segment - overlap) * sr) output = np.zeros_like(audio) window = np.hanning(seg_len) count = np.zeros_like(audio) for start in range(0, len(audio), hop): end = min(start + seg_len, len(audio)) seg = audio[start:end] if len(seg) < seg_len: seg = np.pad(seg, (0, seg_len - len(seg))) fixed = infer(session, seg) output[start:end] += fixed[:end-start] * window[:end-start] count[start:end] += window[:end-start] count[count == 0] = 1 return output / count这个分段拼接逻辑我调过好几版，最终这个版本在听感上最自然，边界处几乎听不出拼接痕迹。
5. 常见问题与排查技巧实录
5.1 输出有杂音或电流声
这是最常见的问题，通常有三个原因。第一，输入音频本身有削波，修复后削波处的失真被放大了。第二，分段拼接时窗口函数没用好，边界处出现相位跳变。第三，量化模型精度损失过大，尤其是动态量化在某些层上量化误差偏大。
排查顺序：先用原始float32模型跑一遍，如果杂音消失，说明是量化问题，换静态量化或者混合量化。如果还有杂音，检查输入音频的峰值，用Audacity看一下波形有没有削平。最后检查分段拼接逻辑，把重叠比例调大一点试试。
5.2 修复后声音变“闷”或变“尖”
这说明模型的频响补偿和你的录音特性不匹配。Sidon的训练数据大概率是某种特定风格的录音，如果你的录音设备频响曲线差异很大，修复结果就会偏。解决办法是在推理前做一个轻度的EQ匹配，把输入音频的频响往训练数据的分布上靠一靠。具体做法：用一段白噪声录一遍你的麦克风，分析频响曲线，然后设计一个反向补偿滤波器。
5.3 CPU推理速度太慢
先确认你用的是int8量化模型，而不是float32。然后检查ONNX Runtime的线程数设置：
options = ort.SessionOptions() options.intra_op_num_threads = 8 options.inter_op_num_threads = 2 sess = ort.InferenceSession("sidon_int8.onnx", options)intra_op线程数建议设成CPU物理核心数，inter_op设成2到4。另外，确保没有其他大程序在抢CPU资源。
5.4 和TTS朗读包配合时出现爆音
有些TTS朗读包输出的音频峰值已经接近0dB，直接过Sidon会削波。解决办法是在TTS输出和Sidon输入之间加一个衰减，比如-6dB，修复完再归一化回来。另外，TTS合成语音的采样率可能是22050或24000，记得先重采样到16000。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决手段 |
|---|---|---|---|
| 输出有杂音 | 量化误差、拼接边界、输入削波 | 换float32模型对比 | 静态量化、调重叠、前期降增益 |
| 声音发闷 | 频响不匹配 | 对比输入输出频谱 | 加EQ补偿 |
| 声音发尖 | 高频过度补偿 | 检查齿音段能量 | 降低模型高频增益或加去齿音 |
| 推理慢 | 未量化、线程少 | 查看模型大小和线程设置 | int8量化、调线程数 |
| 爆音 | 输入峰值过高 | 看波形峰值 | 输入衰减-6dB |
| 拼接痕迹 | 重叠不足 | 听边界处 | 重叠调到0.5秒以上 |
提示：每次调整参数后，至少用三段不同来源的录音做对比测试，不要只凭一段录音就下结论。
6. 进阶玩法：从Sidon到TTS后处理流水线
6.1 把Sidon接在TTS后面
如果你在用sherpa-onnx或者其他ONNX TTS引擎，可以在合成之后加一个Sidon修复环节。流程是：文本输入TTS引擎，得到原始合成波形，重采样到16000，过Sidon，再重采样回目标采样率。这样出来的语音会比原始TTS输出更饱满、更有“人味”。
我实测过一组对比：同一段文本，原始TTS输出听起来像“电子书朗读”，过完Sidon之后更像“有声书主播”。差别主要在低频厚度和动态范围上。
6.2 模型转换：ONNX到kmodel
如果你要在某些嵌入式设备上跑，可能需要把ONNX转成kmodel。这个转换链路比较长，通常要经过NNCase或者类似工具。核心思路是先把ONNX简化，去掉不支持的算子，然后做量化校准，最后编译成kmodel。这个过程对算子兼容性要求很高，w2v-BERT里的一些注意力算子可能需要手动替换。我的建议是：如果不是必须上嵌入式，优先用ONNX Runtime的CPU推理，省事得多。
6.3 和其他语音模型串联
Sidon可以和其他语音模型串联使用。比如先过一遍降噪模型，再过Sidon做质感修复，最后过一遍响度归一化。串联时要注意每个环节的采样率和增益匹配，否则容易出现某一级过载。我的习惯是在每个环节之间加一个峰值检测，超过-1dB就自动衰减。
7. 我踩过的坑和最后分享几个技巧
第一个坑是导出ONNX时忘了设dynamic_axes，结果模型只能处理固定长度音频，换一段长度不同的录音就报错。这个错误很隐蔽，因为导出时不会报错，只有推理时才暴露。
第二个坑是int8量化后没有做听感验证，直接批量处理了几十条录音，结果有几条出现了轻微的金属音。后来发现是某些层的量化误差偏大，换成混合量化（部分层保持float32）就解决了。
第三个坑是分段拼接时窗口函数用错了，用了矩形窗，边界处出现明显的咔嗒声。换成汉宁窗并加重叠后就消失了。
最后分享一个小技巧：如果你不确定Sidon的修复效果是否适合你的录音，可以先截取30秒做A/B对比，用耳机听。重点听三个地方：底噪是否降低、人声是否更靠前、齿音是否更顺滑。如果这三点都有改善，那整段录音的修复效果基本不会差。另外，修复后的音频不要直接覆盖原始文件，保留原始版本，方便后续调整参数重新处理。
