1. 先搞明白：你听到的“嗡嗡声”到底是什么

我管这个项目叫“buzz”，起初没有那么多复杂的想法，纯粹是因为朋友问我“你天天在群里发的那堆音频处理脚本到底叫什么”，我就随口说：叫“buzz”吧，反正处理的也是各种录音里最让人头大的嗡嗡声。

后来发现“buzz”这个词还能读出另一层意思——互联网上常说的“热度、讨论度、声量”。一个视频或者一首歌要想在网络上有真正的“buzz”，前提是别人愿意点开听下去，而一段满是电流声和底噪的音频，大概率在开头三秒就能把人劝退。所以这篇博客想聊的，就是我把“buzz”从一个模糊的想法落地成一套可复用的音频处理流程：从检查素材底噪、定位噪声来源，到批量降噪、清洗、输出合格成品的完整过程。内容适用于视频剪辑师、播客制作者、会议录音整理者，也会让那些刚买了电容麦克风却到处踩坑的新手朋友少走很多弯路。

这套流程不是某个“一键降噪”插件能替代的。它由几个Python脚本和FFmpeg命令行组成，能批量扫描一堆文件，自动评估每一段的噪声水平，再按照不同的噪声类型套用不同的清洗链路。处理完还能输出一份报告，告诉你哪些素材可以直接用，哪些需要修，哪些干脆建议重录。我用了大半年，处理过的素材从几十秒的短视频剪辑到两小时的播客长音频都有，效果相对稳定，今天把完整方案整理出来。

1.1 三种噪声的“听感画像”

先别急着打开软件。我见过不少人拿到一段录音，听出有杂音，就直接丢给降噪插件一通猛操作，结果人声变形得厉害，杂音反而更明显。问题的根源在于：没有分清自己听到的到底是哪一种噪声。

“buzz”在口语里被说得很泛，但工程技术上至少该拆开看三类：

很多人把自己听到的杂音笼统叫“电流声”，但Hum和Buzz的处理方式完全不同。Hum通常用高通滤波和陷波器就能压制；Buzz里面带有大量的高次谐波，单纯切掉一个频点不够，反而需要更宽的频带切除或者深度学习降噪。Hiss则最麻烦，它往往藏在人声的频率范围内，切多了人声就闷，切少了又不干净。

1.2 嗡嗡声的五个常见来源

根据我处理过的素材，噪音来源基本逃不出这几类：

• 开关电源与PWM电路。笔记本电源适配器、LED灯驱动、无线路由器都可能是辐射源。尤其是把麦克风或音频线放在这些设备旁边，噪声会直接耦合进来。这种噪声往往带有明显的嗡嗡声和滋滋声，特征是关机后立刻消失。
• 接地环路。这个在台式机用户里非常普遍。电脑主机、显示器、音响各自接地，但地电位不一致，信号线两头一接，地环路就形成了。声音表现是持续的低频哼声，有时候拔掉某个设备的电源线，哼声瞬间就没了。
• 声卡或麦克风前置放大器的底噪。它是真实存在的，跟录音设备本身的信噪比相关。低成本的USB麦克风在增益开到七八成以上时，底噪会像潮水一样涌进来，这是很多新手最容易中招的地方。
• 数字压缩的“鬼影噪声”。微信语音、低码率会议软件、老旧的视频平台转码，都会在声音边缘产生类似“哗啦哗啦”的破碎感。很多人以为是录音有问题，其实是上游压缩环节把高频细节磨没了。
• 机械振动与结构噪声。机械硬盘读写、风扇叶片穿过气流、桌面被拍打时传递给麦克风的震动。这一类不完全是电子噪声，物理上过滤更有效。

每一类噪声都有“该用硬件解决的部分”和“只能用软件补救的部分”。比如接地环路的处理原则是物理上断开环路，而不是靠降噪滤镜硬扛，因为软件再怎么修，动态细节已经被掩模掉了。

1.3 处理前先做“声音体检”

我给这个习惯起了个名字叫“声音体检”：在正式处理任何素材之前，先录一段时间的内容作为分析样本。对已有的录音素材，找一段没人声、没音乐、没有明显瞬态声音的“空气声”片段，长度大约20到30秒就够了。

接下来看三个指标：

• RMS电平：录音在无话时段的总能量，代表底噪水平。RMS在-50dBFS以下，一般算干净；-45dBFS到-50dBFS属于可用但需要轻度处理；高于-40dBFS就是明显的噪声超标了。
• 峰值因数：峰值电平和RMS电平的差值。如果峰值比RMS高很多，说明底噪可能是偶发的脉冲式干扰，比如电器启动、灯管闪动，处理方式要和连续噪声区分开。
• 频谱分布：打开一个简单的频谱图，看看能量集中在哪个频段。如果是50Hz附近有一列竖线，大概率是Hum；如果整个高频区都平铺着一条“底毯”，那就要考虑Hiss。

这一步看似简单，但绝大多数人都会跳过。跳过之后的结果就是：降噪参数全靠猜，今天调出的效果明天换个素材就崩了。后面章节里我会给出具体的Python分析脚本，直接跑一遍就能自动生成报告。

2. 方案选型：我为什么没用“一键降噪”插件

在正式介绍我的方案之前，得先聊聊市面上常见的降噪工具，以及它们各自擅长什么、不擅长什么。很多人习惯了“导入插件-点一下预设-导出”的流程，却不知道这套流程背后的原理是什么，所以一旦遇到特殊素材，就完全没有方向。

2.1 主流工具与插件对比

我用过的方案不下十种，这里挑几个有代表性的列出来：

从这张表能看出来，真正适合批量处理的是后三类。而“一键降噪”类插件最大的问题，在于它把很多判断藏在黑盒背后。你只能拖一个滑杆，选个强度，完全不知道它动了哪些频段、压了多少动态。一旦某个素材处理完变得塑料感十足，想定位问题都不知道从哪下手。

2.2 核心降噪原理：三种路线，三种代价

我把常用降噪算法粗略归成三类，用大白话解释一下：

• 谱减法：先估算噪声的能量谱，然后在原信号里把这一部分“减掉”。就像洗碗时先用布擦掉大块油污，但布本身会留下细小的毛屑。算法减得太狠，就会产生那种“水声”“金属声”，业界管它叫音乐噪声。
• 维纳滤波：它不直接减，而是根据当前信号里噪声的比例动态决定保留多少，噪声大的地方多压，噪声小的地方轻压。这个思路更聪明，代价是需要比较准确的噪声估计。
• 深度神经网络：RNNoise这类模型在海量干净语音和带噪语音里学了一个映射，直接输入带噪波形，输出干净波形。它对人声的保留效果很出色，因为它知道人声的基频、共振峰这些特征长什么样，不会像传统算法那样一刀切。

理解这些原理的价值，不在于让你写算法，而在于让你选对工具。如果你面对的是稳定的电源Hum，最有效的是陷波器加高通滤波，而不是用神经网络去猜；如果你面对的是宽频段的话放嘶声，单纯切频段会连人声的高频齿音一起干掉，这种时候深度学习模型更有优势。

2.3 为什么选择了“组合拳+批处理脚本”

我真正决定写这套脚本，是连续处理三期播客之后。每期节目两个小时，三个人说话，背景里有空调声、电脑风扇声，偶尔还有远处马路上的车流声。用软件一个个拖进去处理，参数还不统一，第一集和第三集听起来音量忽大忽小。

所以我给自己定了三个原则：必须能批量、必须可复现、必须能自动生成报告。于是“buzz”项目的核心结构就变成了这样：

buzz/ ├── presets/ # 按场景划分的清洗预设，JSON格式 │ ├── speech_studio.json │ ├── speech_noisy.json │ └── mix_music.json ├── scripts/ │ ├── analyse_noise.py # 扫描素材，输出噪声报表 │ ├── clean_audio.py # 按预设批量处理音频 │ └── verify_output.py # 检查处理后文件是否达标 └── tools/ └── run_all.sh # 一键执行从分析到处理的全流程

这个结构看起来很普通，但它解决了一个关键问题：每一次处理都有参数记录，不会出现“上次调得挺好但忘了存”的情况。处理完后，再跑一遍验查脚本，对比处理前后的RMS、峰值和文件大小，自动判断有没有达标。

3. 实操：用buzz项目批量消灭嗡嗡声

3.1 环境准备

先说环境。最省事的组合是Python 3.9以上加FFmpeg和SOX。FFmpeg负责重型音频处理，SOX负责一些轻量滤波和格式转换，Python负责调度和参数计算。

安装命令在不同系统上略有区别，我这里给个通用思路：

# Debian/Ubuntu系 sudo apt install ffmpeg sox python3-pip # macOS 使用 Homebrew brew install ffmpeg sox python3

如果你在Windows上，推荐直接用WSL2，里面装Ubuntu之后跟Linux体验一致。尽量不要在Windows原生CMD里处理长路径和管道，烦心事太多。装好基础工具之后，再装Python依赖：numpy、soundfile、rnnoise（如果没有现成包，用ffmpeg的arnndn滤镜也行）。

这里多说一句：FFmpeg的降噪滤镜是afftdn，直接内置；RNNoise在FFmpeg里对应的是arnndn，需要编译时启用相关库。检查方式很简单：

ffmpeg -filters 2>/dev/null | grep -E "afftdn|arnndn"

如果arnndn不可用，就退而求其次用afftdn，也能达到不错的清洗效果。

3.2 第一步：给素材做“噪声体检”

拿到一批素材后，我不会直接处理，而是先跑一个分析脚本，把每个文件的底噪量化出来。下面这个脚本是我现在一直在用的精简版：

import wave import numpy as np def analyse_wav(path): with wave.open(path, 'rb') as w: sr = w.getframerate() ch = w.getnchannels() frames = w.readframes(w.getnframes()) data = np.frombuffer(frames, dtype=np.int16).astype(np.float32) / 32768.0 if ch > 1: data = data.reshape(-1, ch).mean(axis=1) rms = np.sqrt(np.mean(data ** 2)) peak = np.max(np.abs(data)) db_rms = 20 * np.log10(rms + 1e-10) db_peak = 20 * np.log10(peak + 1e-10) return sr, db_rms, db_peak if __name__ == "__main__": # 简单用法: python analyse_noise.py input.wav import sys path = sys.argv[1] sr, db_rms, db_peak = analyse_wav(path) print(f"采样率: {sr} Hz") print(f"RMS: {db_rms:.1f} dBFS") print(f"Peak: {db_peak:.1f} dBFS") print(f"峰值因数: {db_peak - db_rms:.1f} dB")

这个脚本的核心逻辑是读入WAV文件，把多声道混成单声道，然后计算RMS和峰值。实际操作里，建议用soundfile替代wave，因为wave不支持直接读取FLAC、MP3等格式，而soundfile可以通吃。对于MP3等压缩格式，也可以先用FFmpeg统一转成48kHz/24bit的WAV，再喂给分析脚本。

拿到报告后怎么判断？我的习惯是：

• RMS低于-50dBFS：素材干净，不需要大动作，最多做个轻量低切。
• RMS在-45dBFS到-50dBFS之间：有可用底噪，需要处理，但压力不大。
• RMS高于-40dBFS：噪声明显，得先查来源，是不是录制时增益开太高，或者周围有干扰源。
• 峰值因数大于15dB：说明噪声是偶发性的，重点排查会不会是电器启停、物体碰撞，不能当成连续噪声去降。

3.3 第二步：定制清洗链

“清洗链”是我自己起的名字，意思是一串音频滤镜按固定顺序执行。为什么不能只用一个滤镜？因为噪声是复合的，有低频Hum、高频Hiss、还有压缩残留，一条链路各管一段，互不干扰。

我的预设分三档：

第一档：电源Hum主导

听感是“嗡——”的声音盖过了其他细节，常见于用笔记本直接录音、接了外接电源没接地线的情况。清洗链以高通和陷波为主：

ffmpeg -i input.wav -af "highpass=f=80,notch=f=50:w=30,notch=f=100:w=30,notch=f=150:w=30,afftdn=nf=-35:nr=6" output.wav

参数说明：highpass=f=80把80Hz以下切除，主要去掉空调振动和电源低频哼声；notch=f=50:w=30在50Hz处挖一个带宽30Hz的坑，这是针对电源基频；100Hz和150Hz是二次、三次谐波，如果不挖掉，听感上还是有“嗡嗡”的残留。afftdn=nf=-35:nr=6则做最后的兜底，把残留的杂散噪声压一压。

第二档：话放嘶声主导

表现是“嘶——”一直存在，常见于入门级USB麦克风增益开太高。这种不能靠高通解决，因为嘶声的频段和人声齿音高度重叠，用神经网络降噪更合适：

ffmpeg -i input.wav -af "highpass=f=60,arnndn=model=/path/to/model.rnnn:snr=10" output.wav

如果FFmpeg没有arnndn支持，可以用Python的rnnoise包装库：

import soundfile as sf import numpy as np from rnnoise import RNNNoise denoiser = RNNNoise(sample_rate=48000) data, sr = sf.read("input.wav") out = denoiser.process(data.astype(np.float32)) sf.write("output.wav", out, sr)

注意RNNoise默认是按48000Hz采样率训练的，如果素材是44100Hz，先重采样再处理，否则会出怪声。

第三档：混合素材、保留环境声

制作播客或视频时，有时不想要完全“死寂”的背景，而是希望保留一点空气声，让人声不那么干。这种情况下降噪强度必须保守：

ffmpeg -i input.wav -af "highpass=f=70,afftdn=nf=-30:nr=3:tn=1" output.wav

这里tn=1表示开启阈值模式，只有超过阈值的噪声才被处理，低于阈值的自然声音保留下来。

每一条链路我都会在正式处理前，先裁剪10秒样本试听，而不是直接对整个文件跑。原因很简单：降噪是不可逆操作，一旦处理完发现人声变得干瘪，原素材又没备份，那才是真的翻车。

3.4 第三步：批处理脚本与试听验收

确认参数没问题之后，就把处理铺开。我最常用的是一个Shell脚本，遍历指定目录下所有音频文件，处理后统一放到“cleaned”文件夹：

#!/bin/bash INPUT_DIR="$1" OUTPUT_DIR="$2" PRESET="$3" mkdir -p "$OUTPUT_DIR" for f in "$INPUT_DIR"/*.wav; do name=$(basename "$f") echo "Processing: $name" ffmpeg -y -i "$f" \ -af "$(cat "presets/$PRESET.json")" \ -ar 48000 -ac 1 -sample_fmt s16 \ "$OUTPUT_DIR/$name" done echo "Batch done. Check $OUTPUT_DIR"

这里有个细节：输出统一用48kHz、单声道、16bit。为什么要统一？因为后续无论做语音识别还是发布到视频平台，统一的格式能避免很多兼容性问题。如果是音乐素材，建议保留原始采样率和声道数，不要一刀切。

处理完之后，再跑一遍分析脚本对比处理前后的RMS。处理后的RMS如果比原来低了5dB以上，说明降噪有效；如果只低了一点点，就要检查是不是清洗链没匹配噪声类型。不要只看指标，最终要戴上耳机听。重点检查三个位置：字头字尾有没有被切掉气息，句间停顿的时候背景是不是干干净净，整段听下来人声有没有“蒙上一层纱”。

4. 常见问题与排查技巧实录

这套流程我用到现在，踩过的坑不少。挑几个最常见的记录在这里，给后面接手的人省点时间。

4.1 五个翻车现场

翻车一：人声像含了一口水

这是谱减法用药过猛最典型的表现，听起来低频变浑、辅音模糊，好像有人捂住了嘴。原因多半是afftdn的nr值开太大，或者nf设得太低。解决办法是减小nr到3到5，再把nf往上提一点。如果还是不行，就换RNNoise这类基于神经网络的方案，它对语音破坏更小。

翻车二：处理完出现“水声”

“水声”在音频行话里叫音乐噪声，是谱减法估计噪声不准、随机残留形成的。在频谱图上看，就像水面上飘着的碎泡沫。解决方案有三个：增大FFT窗口让频域分辨率更高；降低降噪强度；或者开启afftdn的平滑参数，让频域变化更平缓。

翻车三：批处理把环境音当噪声吞了

有一次我处理一段外景采访，背景有轻微的鸟叫声和树叶声，结果批处理之后，这些环境音全被压没了，人声反而显得很干、很突兀。原因是降噪门限没设好，把有用的背景声当成噪声处理了。正确做法是分开两个预设：一边处理人声主轨，一边拿一条环境声备用，最后在剪辑软件里自然混合，而不是在降噪阶段就把环境音灭掉。

翻车四：处理后的音量忽大忽小

降噪和压缩同时开的时候，容易出现声音忽大忽小。因为压缩器基于振幅检测，降噪又改变了噪声底，两个算法互相干扰。解决顺序是“先降噪，再压缩”，而且压缩参数不要设太激进，音量自动化用剪辑软件里的手动包络来做，不要指望一个滤镜全搞定。

翻车五：输出文件比原文件还大

用FFmpeg处理时没管编码参数，默认输出可能是无损PCM，而原文件是192kbps的MP3，当然会变大。处理完一定要统一指定编码器和码率：播客用128kbps到192kbps的AAC或MP3，视频配音用256kbps的AAC，没特殊需求别用PCM。

4.2 排查速查表

这张表是我每次处理新素材前必看的东西，遇到问题直接查，不用再从头试。

4.3 批量处理前必做的“小样试运行”

我在批处理流程里固定加了一步：先挑三个有代表性的文件，每个文件只截前20秒，跑一遍完整清洗链，戴上耳机听。这三个文件最好分别代表“最干净”“最差”“中间水平”，这样能快速判断预设是否合理。

具体命令：

ffmpeg -i original.wav -t 20 -af "highpass=f=80,notch=f=50:w=30,afftdn=nf=-35:nr=6" sample_clean.wav

-t 20就是只处理前20秒，几乎一瞬间完成。这一步花不了两分钟，却能避免跑完整个文件夹才发现参数是错的，省下的时间远大于麻烦。我见过有朋友一上来就全量处理120个文件，睡醒一看全报废，原素材还没备份，那种绝望我不想再体验第二次。

另外还有两个细节容易忽略：一是处理前先看一眼时间轴，如果某个片段本来就有砸东西、关门、拍手这类瞬态音，降噪时大概率会处理成“噗”的破音，这种片段建议先切掉再降噪；二是多声道素材里，如果人声在左声道、音乐在右声道，建议分声道处理或直接把单声道提取出来，混在一起降噪会互相影响。

5. 一些进阶玩法与项目心得

5.1 从“修音频”变成“语音识别前处理”

我做这套工具的初衷是给播客降噪，但后来发现它对语音识别同样有价值。把降噪后的音频喂给语音转文字工具，识别准确率明显提升，尤其是那些在嘈杂环境里录的会议录音，效果更直观。原理不复杂：ASR模型在干净语音上训练，底噪会干扰特征提取，降噪相当于把输入的“信噪比”拉高了。

如果你打算这么做，我有个额外建议：不要用音乐素材处理用的重降噪，也不要压缩太狠，因为语音识别需要保留尽可能多的语音细节。highpass=f=80加afftdn=nf=-35:nr=4这个组合，再配合RNNoise轻处理，是比较稳妥的起点。如果你的素材是电话或会议软件录的，可能还包含编解码带来的金属感，这时可以先做一次轻度EQ，把4kHz附近过亮的频段压一点。

5.2 想自己训练模型？先别急

RNNoise本身支持训练自定义模型，我也见过有人想训练一个专门针对自己房间底噪的模型。我的建议是：在你手里有几十上百小时、成对标注好的“干净语音+带噪语音”数据之前，不要轻易动这个念头。数据配对是非常脏的活，稍有不慎就会学出奇怪的伪影。

如果你确实想尝试，可以走一条轻量路线：先录一段自己房间的纯底噪，拿这段底噪叠加到任意干净语音上，构造出一批“伪带噪样本”，用官方训练脚本跑一轮。这样能让你理解训练流程，出来一个玩票性质的模型，但指望它比官方通用模型更好用，希望不大。

5.3 一点个人体会

“buzz”这个项目给我的最大收获，是养成了一套处理音频时的“先诊断、后处理”习惯。以前拿到一段脏素材，第一反应是“赶紧找个滤镜把噪声抹掉”，现在会先问几个问题：这是Hum还是Buzz还是Hiss？来源是什么？有没有可能通过重录或调增益把问题消灭在源头？想清楚之后再做降噪，需要动用的强度反而小了很多。

如果你只想从这套文章里带走一样东西，那就是：先录一段空气声，把底噪看清，再谈降噪。音频处理里90%的翻车，都发生在没看清单、没做备份、参数盲调这三件事上。

到现在，我依然会在处理完一批素材之后随机抽几条戴上耳机认真听一遍。数字指标只是参考，耳朵才是最后的裁判。这套脚本谈不上多高级，它就是老老实实把“体检、清洗、验收”三件事跑通，然后让这个过程可以重复、可追溯。你完全可以根据自己的情况只取一部分使用，哪怕只是借那个分析脚本给你的录音做一次“体检”，这个项目也算发挥了价值。