开视频会议时打开降噪开关，键盘声瞬间没了，人声也还算自然。同一段录音下班后拿后期软件跑一遍降噪，出来的效果明显更干净，底噪压得更彻底，人声的齿音和气口也保住了。于是很自然会问：既然离线能做到这个程度，实时为什么不行？把同一个算法放到通话链路里不就完了吗？
答案是放不进去。不是算力不够，也不是没做优化，而是这两件事在数学上就不是同一个问题。
音频降噪底层原理
降噪的常规做法是分帧处理：把音频切成 20~40ms 的短帧，每帧做一次 STFT（短时傅里叶变换）得到频谱，估算出这一帧里哪些频点是噪声，给它们乘一个小于 1 的增益系数压下去，再逆变换回时域拼起来。关键在于"哪些频点是噪声"这个判断从哪来。
离线模式可以做两遍处理：第一遍先把整段扫完，从所有能量最低的片段里统计出一份可靠的噪声谱模板；第二遍才真正做谱减。这份模板是全局最优的，包括那些出现在音频中后段的空调启动声，第一遍就已经记录在案。
三个权衡：实时端的每一个决定都在付代价
权衡一：延迟预算 vs 前瞻窗口
前瞻（look-ahead）是实时算法唯一能"偷看未来"的手段：先把音频缓存若干帧再开始处理。对瞬态噪声特别有效——听到即将的键盘敲击，才能在出现前把增益压下去，避免咔哒声漏出半个头。
代价是刚性的：缓存 3 帧就多 3 帧延迟，一帧都省不掉。而延迟预算是外部给定的：
- 实时通话：端到端 150ms 以内才算舒适，留给降噪的通常不超过 40ms
- 直播推流：200ms 量级可接受，前瞻能开得比通话大
- 后期制作：不设上限，前瞻等于整段
所以通话场景的降噪必然比直播弱，直播必然比后期弱。这个顺序由链路预算决定，不由算法优劣决定。
权衡二：帧长 vs 频率分辨率
帧越短延迟越低，但频率分辨率随之变差。48kHz 采样下 1024 点帧长对应约 21ms、频率分辨率 47Hz；砍到 256 点后延迟降到 5ms，分辨率却掉到 188Hz。
188Hz 的分辨率意味着 100Hz 的空调低频嗡鸣和男声基频挤在同一个频点里，算法无法区分，只能整体压或整体留。这正是低延迟实时降噪常见的通病：中高频挺干净，低频那层闷响去不掉。
权衡三：一遍决策 vs 二遍复核
离线可以在做完一遍后回看结果：哪几段过减了、哪几段残余明显，然后调整参数重跑，或者对不同片段用不同强度。实时没有"回看"这个动作，每一帧的决定一旦输出就不可撤回，判错了只能让它错过去。
后果是实时算法必须保守。宁可少减 3dB 留点底噪，也不能激进到某一帧把人声整个吃掉——离线出这种错可以重跑，实时出这种错对方直接听到一段静音。
音频降噪的有效解决方案
按这套逻辑，一条正常的处理链是：录制端只保留必要的增益控制，不做激进降噪 → 拿到完整素材 → 离线跑降噪 → 有需要再做人声分离或均衡。
用 AIFooler 的一键降噪走这一步时，上传本地音频文件后可以直接对比降噪前后的效果，浏览器里完成，无需安装，文件 24 小时后自动删除。它只处理你上传的本地文件，不支持粘贴链接在线解析，素材得先落到本地。
如果同一批素材还要做格式统一或响度校准，放在降噪之后、交付之前集中做一次即可，免费音频编辑平台上这几步能接在一条流程里，不必来回倒手文件。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/tmwanlya/article/details/164063737
