简介面向音频处理与降噪应用开发者这套C项目提供了一份注释清晰的音频去噪实现可对带噪语音进行降噪处理适合语音识别、音频分析、音乐后期等场景的入门与二次开发。压缩包共17个文件以C/C源码3个.c、3个.cpp与6个头文件为主同时附带Visual Studio解决方案.sln/.vcxproj、项目筛选文件以及一个WAV格式测试样本“带噪语音.wav”整体仅39KB打开工程即可编译运行。已有2178人查阅学习。代码实现了从WAV读取、FFT频域变换、噪声估计与抑制到去噪结果输出的完整链路并对阈值处理、滤波器、谱减等知识点进行了流程化注释借助这套代码可以快速理解经典去噪算法的工程化落地方式也便于在此基础上替换或扩展维纳滤波、LMS自适应滤波等更高级方法是一套值得阅读的音频降噪参考资源。 如果你正被一段录满了风扇声、空调底噪的音频折磨又不想为了去噪引入一整套深度学习框架那你大概率需要一段能直接看懂、能跑起来的音频去噪C代码。我整理的这个项目就是用C写的谱减法去噪实现依赖少、逻辑直观、注释清晰适合你快速移植进自己的音频处理管线也适合拿来入门语音前端处理。代码解决的是最实际的问题给定一段PCM音频去掉平稳背景噪声的同时尽可能保留语音清晰度。它不需要GPU、不需要训练数据一台普通PC上处理几秒钟音频几乎感觉不到耗时。无论是给录音软件做预处理还是给嵌入式设备做离线降噪这套代码都可以作为起点。我把算法选型、工程结构、核心实现、编译使用和调参经验全部拆开讲一遍该避的坑也会一并说清楚。1. 去噪算法的选型思路为什么我在C工程里选谱减法先说清楚一个经常被误解的事音频去噪不等于都要上神经网络。很多项目一看“降噪”两个字第一反应是RNN、U-Net或者是端到端模型。但落到C工程里要考虑部署体积、推理速度、可解释性和调试成本。深度模型效果上限确实高但一个注释清晰、可单步调试的传统算法往往是解决80%场景的最快路径。1.1 传统方案横评维纳滤波、小波去噪、谱减法该选谁传统音频去噪有三大类常见方案我当初都仔细比较过也分别写过测试代码验证效果。方案核心思路优点缺点适合场景维纳滤波估计信号和噪声的统计特性设计最优线性滤波器稳态噪声下理论性能好语音失真较小需要实时估计SNR参数推导复杂非平稳噪声下表现一般预先知道噪声类型的离线处理小波去噪对信号做小波分解把噪声对应的小波系数收缩置零后重构对脉冲噪声效果好多分辨率分析灵活阈值选择经验性强计算开销偏大C实现门槛偏高非平稳、瞬态噪声占主导的场景谱减法从带噪语音频谱中减去估计出的噪声频谱原理直观复杂度低只需FFT和幅度谱运算处理不当会引入“音乐噪声”对非平稳噪声效果有限稳态背景噪声、实时性要求高的场景这个表是筛选结论不是最终答案。真正让我下决心用谱减法的是两个工程现实第一算法链路短从PCM输入到降噪输出只有分帧、FFT、减谱、IFFT四步每一帧都能独立调试第二需要写的代码量少整个核心类只用一个文件就能装下这恰好符合“注释清晰可用”的项目定位。1.2 谱减法为什么匹配“注释清晰可用”这个定位很多人以为选型就是选一个效果最好的但实际工程里选型是在多重约束下做取舍。我选谱减法还有几个不太容易被注意到但很重要的理由。数学表达极其简洁。语音频谱减去噪声频谱公式写出来就两三行给任何维护代码的同事看一遍就能懂不需要解释什么是状态空间模型。FFT库非常成熟。C生态里FFTW是久经考验的底层库单精度接口效率高而且对ARM、x86平台都有良好支持不会成为移植的瓶颈。参数数量少可解释性强。真正需要调的只有过减因子、谱底限幅系数、噪声更新速度这几个量出问题可以很快定位是算法问题还是参数问题。中间结果便于验证。我可以把分帧后的数据、FFT后的幅度谱、噪声估计谱分别dump成文本文件在Python里画图对比这对调试和写注释都有很大帮助深度学习模型很难做到这种逐级验证。补充一句谱减法并不是万能的它的理想假设是噪声谱平稳且与语音不相关。如果你要处理的是街道上稀疏的汽车鸣笛、键盘敲击声这类瞬态噪声谱减法基本无能为力需要用专门的瞬态噪声压制手段。这个项目解决的是风扇声、环境底噪、录音设备自带的平稳噪声这一类最常见问题。2. 工程结构一个刚够用、又不臃肿的C去噪模块怎么搭代码的工程结构是我在重写第三版时才定下来的。第一版把所有逻辑堆在main函数里能跑但根本没法给别人看第二版拆分得过于细碎结构体、接口层层嵌套注释写得再多也难读。最终版遵循一个原则让读者从类接口就能猜到处理流程从注释就能知道每一段代码为什么存在。2.1 文件划分与类的职责边界整个项目只有四个文件多的一个都没有。denoise/ ├── CMakeLists.txt ├── include/ │ └── AudioDenoiser.h ├── src/ │ └── AudioDenoiser.cpp └── app/ └── main.cppAudioDenoiser是核心类负责从PCM数据进来到降噪后PCM数据出去的全过程。头文件里公开的接口尽量精简方便外部使用class AudioDenoiser { public: struct Config { int sampleRate 16000; // 采样率Hz int frameSize 512; // 帧长采样点数 int hopSize 256; // 帧移采样点数与frameSize配合实现50%重叠 float alpha 1.5f; // 过减因子越大噪声消得越狠 float beta 0.01f; // 谱底限幅系数越小越容易产生音乐噪声 int noiseFrames 15; // 用于估计初始噪声谱的起始帧数 }; explicit AudioDenoiser(const Config config); std::vectorfloat process(const std::vectorfloat pcm); };process函数只接收单声道float数组输出等长的PCM数据。刻意没把WAV读写逻辑放进类里因为读取音频文件属于I/O层去噪算法属于信号处理层混在一起会让测试和复用都变得困难。main.cpp里用libsndfile读取WAV、调用process、再写回文件职责非常清楚。2.2 数据流与接口设计背后的考虑整个处理流程用一张图就能说清我写代码时也把这张图画在了头文件的注释顶部方便阅读者快速建立整体认知。PCM输入 - 去直流(可选) - 分帧 - 加汉宁窗 - FFT - 功率谱计算 - 噪声谱估计/更新 - 谱减 - 增益计算 - 频域乘增益 - IFFT - 重叠相加 - PCM输出接口设计上有几个细节值得说。用float不用double。音频信号本身精度需求不高float的24位尾数对16bit PCM绰绰有余而且单精度运算在SIMD向量化时吞吐量高一倍对嵌入式平台也更友好。process传入的是整个音频向量而不是逐帧回调。这样便于使用者做批量处理也方便我写单元测试时直接造正弦波混合数据去验证。如果你需要实时流式处理把分帧逻辑改成带状态的流式接口即可核心算法不用动。Config里不暴露FFT长度等底层参数。frameSize、hopSize已经足够描述分帧行为FFT长度在构造时内部推导为frameSize少一个参数就少一个配置错误的机会。还有一个容易踩的坑预处理阶段最好先去直流偏置。很多音频采集设备会引入一个极低频的直流分量如果不去掉FFT后第0个频点会异常偏大导致这个频点被谱减错误处理输出出现严重的低频爆破声。我在process里会先对整个信号做一次均值相减成本极低但非常有用。3. 核心实现拆解从PCM到频谱从噪声估计到谱减恢复这一节是整篇最硬核的部分。我会沿着代码实际执行的顺序把分帧、加窗、FFT、噪声估计、谱减、IFFT每个环节的原理和代码细节说清楚同时说明注释里写了什么、为什么这么写。读懂这一段你就能自己维护和扩展这套代码。3.1 分帧加窗为什么帧长512、重叠50%音频去噪不是对整个文件做一次FFT而是分帧处理。语音信号在几十毫秒内可以看作平稳随机过程超过这个范围统计特性就会变化。我默认设frameSize512对应16kHz采样率下32ms正好落在这个平稳区间内。为什么不是更长或更短帧长越长频率分辨率越高但时间分辨率越差去噪时容易把短暂的语音碎成碎片也更容易产生音乐噪声。帧长越短时间分辨率越好但频率分辨率不足低频段的噪声估计会很粗糙去噪后容易感觉“闷”。FFT要求帧长是2的幂512在大多数场景下是兼顾分辨率和计算效率的平衡点。如果采样率是44.1kHz我会把frameSize调大到1024换算成时间约23ms效果更稳。分帧后必须加窗。直接对原始帧做FFT相当于加了矩形窗频谱旁瓣很高会让噪声能量泄漏到相邻频点。我用的汉宁窗公式和代码如下std::vectorfloat createHanningWindow(int size) { std::vectorfloat window(size); for (int i 0; i size; i) { window[i] 0.5f * (1.0f - std::cos(2.0f * M_PI * i / (size - 1))); } return window; }50%重叠不是随便定的。汉宁窗满足COLAconstant overlap-add条件在50%重叠时所有帧加窗后叠加起来的增益是常数这意味着只要你的分析窗满足这个条件合成阶段不需要额外做归一化直接重叠相加就能完美重构原始信号。注释里我会特别标注这一条防止后来的人在修改hopSize时破坏了重构性质。3.2 噪声估计与谱减规则过减因子、谱底限幅的确定谱减法最核心的问题是怎么知道当前噪声长什么样我的做法分为两步。第一步用开头若干帧做初始噪声谱估计。语音通常不会在录音第0毫秒就爆发前15帧约0.5秒可以假设为纯噪声这15帧的功率谱均值就作为初始噪声谱。// 初始噪声谱估计取前noiseFrames帧的功率谱平均值 for (int frameIdx 0; frameIdx noiseFrames; frameIdx) { // 对当前帧做FFT得到实部re、虚部im for (int k 0; k halfSpectrum; k) { float power re[k] * re[k] im[k] * im[k]; noiseSpectrum[k] (noiseSpectrum[k] * frameIdx power) / (frameIdx 1); } }第二步在后续处理中当检测到当前帧是噪声帧时用指数平滑方式缓慢更新噪声谱。这里有一个工程判断我用一个简单的能量阈值判断当前帧是否包含语音。如果当前帧总能量低于前导噪声平均能量的1.5倍就认为它是噪声帧用来更新噪声模型否则保留现有噪声谱。这种方式比全程固定噪声谱要鲁棒能适应缓慢变化的背景噪声。谱减核心规则如下也是整个项目注释最密集的地方。float noisePower noiseSpectrum[k] * noiseGain; // noiseGain略大于1等于给噪声估计留出余量 float totalPower re[k] * re[k] im[k] * im[k]; float cleanPower totalPower - alpha * noisePower; // 经典谱减公式 if (cleanPower beta * totalPower) { // 谱底限幅防止负值导致的音乐噪声 cleanPower beta * totalPower; } float gain std::sqrt(cleanPower / (totalPower 1e-10f)); re[k] * gain; // 对实部、虚部乘同一个增益保留原始相位 im[k] * gain;其中alpha是过减因子默认1.5。它控制减掉多少噪声能量alpha偏小残留噪声多但语音失真小alpha偏大噪声更干净但语音会明显变闷甚至产生颤抖感。beta是谱底限幅系数默认0.01目的是防止cleanPower减成负数。如果不加这个下限负值开方会直接出错加上一个很小的下限值能显著降低音乐噪声的可感知度。3.3 合成阶段与音乐噪声的抑制谱减之后得到的是修正后的幅度谱我没有修改相位直接用原始帧的相位做IFFT。这是语音增强里一个被反复验证的做法人耳对相位不敏感保留带噪相位带来的失真远小于重新估计相位的代价。更重要的是保留原始相位让代码实现大幅简化每一帧IFFT之后做重叠相加就能恢复时域信号。音乐噪声是谱减法绕不开的副产品。它的听感像背景里有一种忽隐忽现的“水声”或“嘶嘶声”成因是谱减后某些频点残留了随机出现的窄带峰值。抑制音乐噪声我在代码里做了两件事把beta限制在合理区间。beta太大会让噪声泄漏过多beta太小音乐噪声可感知度变强实测0.01到0.05之间是个比较安全的窗口。在频域对增益做时间上的平滑。具体做法是让当前帧的增益不要突跳跟上一帧增益做一阶滞后处理gainSmooth 0.7f * gainCurrent 0.3f * gainPrev。这个处理会让增益变化更平缓音频听起来更自然。合成阶段的IFFT和重叠相加代码不复杂但有一个细节值得注意因为加了汉宁窗并做了50%重叠IFFT出来的帧数据要等下一次相邻帧加窗叠加才能完整还原信号前半部分。所以我在类里用一个缓冲区累积上一帧的IFFT结果新帧算完后对应位置相加再输出。最后把输出数据除以2因为50%重叠加窗后信号幅度会加倍这一步在代码注释里写得很明确防止后人误以为是普通音量缩放。4. 编译、使用与实测怎么跑起来以及不同场景下参数怎么调代码写得再清楚跑不起来也是废的。这一节我会给出完整的依赖清单、CMake配置和命令行用法然后用几组实际测试说说效果差异。参数调优是音频去噪里最依赖经验的部分我把踩过的坑一并列出来。4.1 依赖与CMake构建项目依赖两个库FFTW3负责FFT计算libsndfile负责读写WAV文件。在Ubuntu系统上安装命令一条搞定sudo apt install libfftw3-dev libsndfile1-dev cmake gCMakeLists.txt我写得很克制没有引入外部子模块方便你直接并入现有工程cmake_minimum_required(VERSION 3.16) project(audio_denoise CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(FFTW3 REQUIRED) find_package(SndFile REQUIRED) add_library(denoise_core src/AudioDenoiser.cpp) target_include_directories(denoise_core PUBLIC include) target_link_libraries(denoise_core PRIVATE fftw3f sndfile) add_executable(denoise_app app/main.cpp) target_link_libraries(denoise_app PRIVATE denoise_core)编译和运行cmake -B build -DCMAKE_BUILD_TYPERelease cmake --build build -j ./build/denoise_app input.wav output.wav --sample-rate 16000 --alpha 1.5命令行参数在main.cpp里用简单的字符串解析实现input.wav是原始带噪音频output.wav是降噪后音频其余可选参数会覆盖Config中对应的默认值方便你在不修改代码的情况下快速试参数。4.2 三种典型噪声场景的实测表现我在三段真实录音上做了测试一段是白噪声污染的语音一段是空调风扇稳态噪声下的录音一段是办公室键盘和谈话混合噪声。主观听感和参数建议整理如下噪声类型输入听感降噪后效果推荐参数白噪声整体有明显沙沙声语音勉强可懂背景噪声基本消失语音清晰有轻微颗粒感alpha1.5beta0.01空调稳态噪声低频轰隆声持续存在语音被掩蔽低频明显收敛语音可懂度大幅提升留少量自然底噪alpha1.8beta0.03办公室混合噪声杂音多时有时无平稳段落有明显改善瞬态噪声如键盘声残留alpha1.5配合后续瞬态处理这组结果说明一个关键经验不要追求绝对寂静。把alpha拉到2.5以上确实能把噪声压得更狠但语音会失真非常明显听起来像隔着水在说话反而不利于听清内容。合适的alpha值是让残留噪声降到“不干扰理解”的程度而不是归零。4.3 我最常被问到的几个调参问题我把过去一段时间被问得最多、也是我自己反复踩过的坑集中回答一下。alpha到底调到多少最合适。看场景采样率和帧长。16kHz采样率下语音集中在0到4kHz过减因子给大一点问题不大44.1kHz音乐素材里语音带更宽alpha超过1.8容易把中高频细节削没。原则是从1.5起步每次加0.2听到语音变“闷”或发“嗡”就回到上一档。为什么总有“水声”和“金属声”。大概率是beta设置太低cleanPower频繁被压到很接近0IFFT后的时域包络出现剧烈起伏。先把beta提到0.05试一次如果音乐噪声还在考虑用我在3.3节说的增益平滑而不是继续加大alpha。为什么开头的语音字被吃掉了。这是因为前导静音太短算法还没建立准确的噪声谱前几个语音帧被当成了噪声来减。解决办法是把录音文件开头的静音段留长到400毫秒以上如果原始录音不允许就把noiseFrames调低同时把噪声更新速度调慢可以缓解这个问题。为什么输出音量比输入小。谱减本质是在做能量衰减输出信号整体电平比输入低是正常的。代码里可以加一个自动增益补偿统计输入输出RMS比例后统一抬升也可以在外层音频处理链路里做响度归一化不要直接在谱减法去噪后拉满音量否则残留噪声也会被同步放大。最后说一说代码之外的事代码部分到上一节就算讲完了。最后分享一点我在这个项目里最深的两点体会不算教学纯粹是经验。第一点关于注释。很多人写注释是在解释“这段代码在做什么”但代码本身已经表达了行为真正需要解释的是“为什么这么做”。我在这个项目里凡是涉及算法选型的地方比如窗口的类型、重叠长度的选取、过减因子的默认值都会在注释里写明当时的测试结论和引用的思路来源。这样做的好处是三个月后你回来看代码不需要重新读一遍论文才能改参数。以后你可以试试这个习惯把每一处“魔数”都写成带命名的常量并在常量旁注释其来由你会发现维护代码的心态完全不一样。第二点关于工具边界。谱减法是一把锋利的刀但它的适用边界非常清晰。如果你的项目主要处理的是环境突变噪声、多人重叠语音、混响严重的录音那么无论怎么调参谱减法都会让你撞上上限。这时候正确的做法不是继续死磕alpha和beta而是换一个其他类别的算法或者在谱减之后串接若干后处理模块。我在项目文档里也明确写了这一点这段代码适合做“预处理”把一个中等信噪比的录音变成信噪比更高的录音而不是做“重构”把完全被掩蔽的语音凭空变出来。你可以从今天这个项目开始先把WAV读取、分帧、FFT、谱减、IFFT、重叠相加这一条链路完整跑通然后放心地加注释、改参数、尝试新想法。音频处理这个东西真正积累了手感之后才会发现自己当初那些困惑都很值。本文还有配套的精品资源点击获取