尧图网页设计 
简介本资源是一套面向信号处理初学者与音频算法实践者的MATLAB轻量级工具包聚焦音频分帧与加窗这一语音识别、特征提取等任务的基础预处理环节。包内含2个核心.m函数enframe.m实现带重叠的分帧frame2time.m提供帧时间戳映射及1个封装rar压缩文件总计3个文件体积仅1KB便于快速集成与调试。已有771人下载学习适用于课程实验、毕设开发或算法原型验证场景。用户可直接调用函数完成音频读取、自定义帧长/帧移设置、汉明窗加窗及帧时间对齐等全流程操作代码简洁规范、注释清晰省去从零编写分帧逻辑的时间特别适合作为语音信号处理入门的即用型脚本支撑。 做语音相关项目时拿到手的往往是一段连续的wav文件但无论做语音识别、声纹确认、情感分析还是简单的端点检测第一步几乎都逃不开同一个操作把长信号切成短块。这个短块就是“帧”切的过程就是“分帧”而分帧之后紧跟着要做的“加窗”则是决定后续特征质量的关键一步。这篇文章我就围绕 MATLAB 里的音频分帧和加窗把从原理到代码、从坑点到优化技巧一次性讲透适合刚接触语音信号处理的学生也适合想把手写算法跑稳一点的工程师参考。1. 为什么音频分帧是语音信号处理的“地基”1.1 音频信号到底有多“不稳定”语音信号本质上是非平稳的也就是说它的统计特性均值、方差、频谱形状随时间一直在变。你今天录一句“你好”波形细节和昨天录的绝对不可能完全一样甚至连同一个词内部的声母、韵母、音调转折都在持续变化。这样的信号如果整段拿去做傅里叶变换得到的频谱是所有时刻特性的“平均”等于把不同发音的细节搅在了一起特征完全失去意义。但语音又有一个很重要的性质叫“短时平稳性”虽然长期看变化剧烈但在很短时间内——比如10到30毫秒——声带振动和声道形状基本可以看作没变。这个特性是语音信号处理真正的立足点。分帧做的事就是把一段长语音切成一个个短段让每一帧都近似满足“平稳”条件这样才能对每一帧单独做频谱分析、提取特征。可以把它理解成电影胶片单看每一帧是静止的连续播放才有动态分帧就是在取那一帧一帧的画面。1.2 帧长和帧移怎么定才既不丢信息又不算太慢帧长不是随便拍的它直接决定频率分辨率。一般来说语音处理里帧长取20到30毫秒比较合适常用的是25毫秒。为什么是这个范围太短了比如5毫秒一帧内只包含几十个采样点频率分辨率很低而且无法覆盖一个完整的基音周期成年男性基频约100Hz周期10毫秒女性约200Hz周期5毫秒分析出来连音高都测不准太长了比如100毫秒语音的平稳假设就站不住脚一帧里可能包含多个音素的变化特征被“糊”掉了。帧移是相邻两帧起始点之间的距离通常取帧长的三分之一到二分之一也就是10毫秒左右。帧移决定了帧与帧之间有多少重叠。有人会问既然要分帧为什么不首尾相接、一帧挨着一帧切非要重叠因为如果完全不重叠帧与帧之间的衔接点附近的信息会被截断边界影响而且后续提取的特征时序平滑度很差。举个例子提取基频曲线时如果不重叠每一帧的基频值跳变很大画出来像锯齿叠加50%重叠后相邻帧共享一半数据特征曲线平滑很多。更重要的是许多后端算法比如HMM、CTC对特征的时间分辨率有要求10毫秒帧移是工程实践里经过大量验证的平衡点。用采样率换算成点数假设采样率fs16000Hz帧长25毫秒就是0.025×16000400个采样点帧移10毫秒是160个采样点。这就是代码里最常用的两个数字。1.3 为什么必须加窗不加窗会怎样分帧只是切出片段切这个动作本身就会引入问题。假设你截取一段400点的信号相当于把这个片段和一个矩形窗相乘——片段内为1、片段外为0。矩形窗在时域上看起来“干净”但到了频域它的频谱是sinc函数旁瓣很高会把信号频谱“抹”得一团糟。这就是频谱泄漏本来只在某个频率处有能量结果因为截断能量扩散到了旁边一大片频率上。真实语音处理里用的几乎都是非矩形窗最典型的是汉明窗Hamming Window。汉明窗的特点是两端趋近于0、中间接近1乘上信号后帧边缘的幅度被平滑压低避免截断处产生阶跃跳变频谱泄漏大幅减少。代价是窗本身等效降低了帧的有效长度频率分辨率略有下降但跟泄漏带来的问题相比这点损失完全可以接受。一句话总结分帧解决“平稳性”问题加窗解决“截断泄漏”问题。两者永远配套出现只分帧不加窗在大多数任务里都会直接拉低特征质量。2. MATLAB环境准备与音频数据读取2.1 读取音频的前置准备开始写代码前先把环境理清楚。MATLAB从R2016b开始音频读取推荐用audioread不再推荐旧版的wavread虽然还能用但很多新版MATLAB里已经标记为将要移除。另外确保你的机器上音频文件路径没有中文或特殊字符这一点在Windows上尤其容易踩坑某些情况下audioread读中文路径会直接报错或者读出来的数据不对。还要检查一下是否有 Signal Processing Toolbox信号处理工具箱。分帧这个操作本身用基础MATLAB就能写但后面如果想调用hamming、buffer、spectrogram这些函数就需要这个工具箱。如果没有也可以用基础函数手动生成窗函数后面我会给出替换方法。2.2 audioread 的正确打开方式[x, fs] audioread(speech.wav);第一返回值 x 是采样点数据第二返回值 fs 是采样率。这里有个细节如果音频是双声道x 是一个 N×2 的矩阵每一列是一个声道如果是单声道则是 N×1 列向量。很多新手在这里不检查就直接做后续处理结果矩阵维度对不上报错报得莫名其妙。测试时确认信息disp([采样率: , num2str(fs), Hz]); disp([数据大小: , num2str(size(x, 1)), 样本, , num2str(size(x, 2)), 声道]);audioread返回的 x 并不是真的“原始”数据它会根据文件格式自动做归一化。比如读16-bit WAV时MATLAB会把整数采样值除以32768转换为范围约 [-1, 1] 的浮点数。这是好事意味着你不用自己处理位深转换。2.3 预处理双声道合并、去直流、归一化一条龙拿到原始数据后我几乎总是先做三件事顺序固定第一双声道合并。除非做双耳声源定位等特殊任务绝大多数特征提取都只需要单声道。最简单的合并方式是取平均if size(x, 2) 1 x mean(x, 2); end还有一个备选方案是直接取左声道x x(:, 1)。两条路都行取平均的抗噪性略好一点但如果左右声道有相位差取平均可能造成部分频率抵消实际使用时看情况选。我用取平均多一点。第二去直流。录音设备往往会给信号叠加一个直流偏置表现在波形上是整个信号在0轴上下不对称。虽然大部分情况下直流分量对后续特征影响不大但在计算短时能量时直流偏置会带来一个不想要的常数项。去除方法很直接x x - mean(x);第三归一化。把信号峰值缩放到 [-1, 1] 范围避免后续计算中数值溢出也方便统一不同录音的音量差异x x / max(abs(x));这三步做完信号就可以进入分帧环节了。3. 手写一个完整的分帧加窗函数3.1 思路拆解从“想到”到“能跑”先说清楚目标输入是一段一维信号 x长度任意输出是一个二维矩阵 frames行数等于帧数列数等于帧长。实现分帧最核心的就是搞清楚两个索引问题每一帧的起始位置在哪一帧内包含哪些采样点设信号总长度为 siglen帧长为 winlen帧移为 wininc。那么总帧数的计算公式是num_frames floor((siglen - winlen) / wininc) 1这个公式怎么来的第一帧从第1个点开始占 winlen 个点之后每移动 wininc 个点取一帧。能取到完整一帧的最大起始位置是 siglen - winlen 1MATLAB索引从1开始所以可取的帧起点共有floor((siglen - winlen) / wininc) 1个。注意如果信号不够长比如 siglen winlen这个公式算出来是0甚至负数必须提前报错。第 i 帧的起始索引是start_idx (i - 1) * wininc 1结束索引就是end_idx start_idx winlen - 1这就是整个分帧的全部数学基础理解了这两行后面无论怎么写都跑不出这个框架。3.2 第一个版本循环实现作为baseline先写一个最直观的循环版本function frames framing_loop(x, winlen, wininc) % 信号分帧 - 循环实现 % x: 单声道信号(列向量) % winlen: 帧长(采样点数) % wininc: 帧移(采样点数) % 返回 frames: 帧数 x 帧长 的矩阵 x x(:); % 强制转成列向量 siglen length(x); num_frames floor((siglen - winlen) / wininc) 1; if num_frames 1 error(信号长度不足以构成一帧请减小帧长); end frames zeros(num_frames, winlen); for i 1:num_frames start_idx (i - 1) * wininc 1; frames(i, :) x(start_idx : start_idx winlen - 1); end end这个版本没有任何花哨技巧逻辑一目了然。性能上如果你的语音只有几秒钟帧数也就几百帧循环完全够用但如果处理的是长录音或批量处理大量文件循环就会成为瓶颈这时要看下面的高效版本。3.3 高效版本用 buffer 函数重写MATLAB 信号处理工具箱里有个专为分帧设计的函数buffer很多人没用过但它几乎就是为这个场景准备的。基本用法frames buffer(x, winlen, overlap);其中 overlap 是重叠的采样点数等于 winlen - wininc。比如帧长400点、帧移160点重叠就是240点。注意buffer有几个跟直觉不符的细节默认返回的矩阵是“帧长×帧数”每一列是一帧通常需要转置才能得到我们习惯的“帧数×帧长”格式。默认会在信号开头补零以保证第一帧的起点是信号的“历史缓冲”。我们通常不想要这个补零要加nodelay参数取消。如果信号长度不能正好整除最后一帧可能不满buffer默认会在末尾补零填满。补零本身不一定是坏事但要心里有数别让补零的帧混进特征计算。实际推荐用法frames buffer(x, winlen, winlen - wininc, nodelay);这一行等价于上面整个循环而且是用底层C实现速度优势明显。实测下来处理几十万点的信号循环可能要一两秒buffer基本瞬间完成。我的建议是理解循环实现的原理代码里优先用buffer因为高效、可靠、边界处理更完善。如果不想依赖 Signal Processing Toolbox比如在一些精简版MATLAB环境里也可以用矩阵索引 repmat实现类似的效果idx (1:winlen) (0:(num_frames-1)) * wininc; % 构造索引矩阵 frames x(idx);这种方法既快又不需要额外工具箱但要求你能一次性构造出完整的索引矩阵比较吃内存。3.4 加窗环节汉明窗的实现细节分帧完成后接下来就是加窗。最常见的窗函数是汉明窗MATLAB里可以直接调用w hamming(winlen, periodic);注意第二个参数periodic和symmetric的区别。谈一下这个很多人会忽略但实际影响不小。语音/音频处理里推荐用periodic窗因为它末端多采一个点处理后可以周期延拓适合频谱分析symmetric窗适合做FIR滤波器设计。两者在窗长不大时差别很小但养成习惯、用对参数能少莫名其妙的误差。如果不想依赖工具箱可以手动生成汉明窗n 0:winlen-1; w 0.54 - 0.46 * cos(2 * pi * n / (winlen - 1));这个公式就是汉明窗的定义0.54和0.46是两个固定系数改成0.5和0.5就是汉宁窗。手动生成的数值跟hamming(winlen, symmetric)结果一致。加窗的操作本质是让每一帧信号逐点乘上窗序列。一个常见错误是维度没对齐frames 是“帧数×帧长”窗 w 是 1×winlen用 MATLAB 的隐式扩展时直接frames .* w是可以的R2016b之后但为了代码清晰我习惯写成frames_win frames .* repmat(w, size(frames, 1), 1);repmat把窗函数复制成和 frames 同样大小的矩阵然后对应点相乘。虽然隐式扩展更简洁但repmat写法在旧版本MATLAB里也能跑兼容性更好。3.5 完整函数代码把分帧和加窗串起来给一个可以直接抄走的完整函数function [frames, frames_win] frame_and_window(x, winlen, wininc) % 音频分帧加窗 % 输入: % x : 单声道信号(列向量) % winlen : 帧长(采样点数) % wininc : 帧移(采样点数) % 输出: % frames : 分帧结果, 帧数 x 帧长 % frames_win: 加窗结果, 帧数 x 帧长 x x(:); siglen length(x); num_frames floor((siglen - winlen) / wininc) 1; if num_frames 1 error(信号长度不足以构成一帧); end % 分帧 frames buffer(x, winlen, winlen - wininc, nodelay); % 如果没装信号处理工具箱改用下面这行替代: % idx (1:winlen) (0:(num_frames-1)) * wininc; % frames x(idx); % 加窗 w hamming(winlen, periodic); % 没有工具箱就手动生成 % w 0.54 - 0.46 * cos(2*pi*(0:winlen-1)/(winlen-1)); frames_win frames .* repmat(w, size(frames, 1), 1); end主脚本测试[x, fs] audioread(speech.wav); if size(x, 2) 1, x mean(x, 2); end x x - mean(x); x x / max(abs(x)); winlen round(0.025 * fs); wininc round(0.010 * fs); [frames, frames_win] frame_and_window(x, winlen, wininc); fprintf(原始信号: %d 样本, 采样率 %d Hz\n, length(x), fs); fprintf(分帧结果: %d 帧, 每帧 %d 点\n, size(frames, 1), size(frames, 2));跑通这段你的分帧加窗流程就算立起来了。4. 分帧之后干什么短时能量、过零率与可视化4.1 短时能量计算的三种写法分帧加窗不是终点它只是给后续特征计算提供“数据容器”。最常见的快速应用就是算短时能量它在端点检测区分静音和语音、语音活动检测VAD里用途很广。公式很简单每一帧所有采样点的平方和。energy sum(frames.^2, 2);返回一个 N×1 向量N是帧数。如果要归一化可以除以帧长得到平均能量energy_avg sum(frames.^2, 2) / winlen;如果你想算的是分贝形式比如用在对数域里做特征加上energy_db 10 * log10(energy_avg eps);加 eps 是为了防止 log10(0) 出现无穷小语音静音段能量本来就接近0这里常见坑不处理会得出 -Inf后面画图会很难看。实际拿到能量序列后很多人会忽略它是一个“按帧索引”的序列不是“按时间”的序列。要做时间对齐每一帧的实际时间戳大概是(i-1)*wininc/fs秒。这个在画图或跟其他模态数据对齐时非常关键。4.2 短时过零率实战过零率Zero Crossing Rate, ZCR是另一个经典短时特征表示一帧内信号穿越零轴的次数常用于区分清音和浊音、区分语音和环境噪声。实现很直接zcr sum(abs(diff(sign(frames), 1, 2)), 2) / (2 * (winlen - 1));这里拆解一下sign(frames)把每个采样点变成1或-10保持不变diff(..., 1, 2)对每一帧、沿时间方向做差分。如果相邻两个点符号不同差分结果是2或-2绝对值再求和就得到了符号变化的次数。除以2*(winlen-1)是为了做归一化。注意一个细节diff假设信号已经是归一化到 [-1,1] 的浮点信号。对于整数信号低频漂移会让过零率失真。所以前面强调的“去直流、归一化”预处理在这里就发挥作用了。把短时能量和过零率合起来看已经可以用来做简单的语音活动检测了。比如设定能量阈值低于阈值的帧判为静音对于能量较高但过零率极高的帧往往对应的是清辅音或噪声。4.3 检查分帧结果用plot看帧边界写完算法第一件事永远是“眼见为实”。我会用代码直观检查分帧是否合理figure; t (0:length(x)-1) / fs; plot(t, x, b); hold on; % 每隔10帧画一条帧起始线 for i 1:10:size(frames, 1) start_t (i - 1) * wininc / fs; xline(start_t, --r, LineWidth, 0.5); end xlabel(时间 (s)); ylabel(幅度); title(分帧边界可视化);运行后红色虚线应该均匀分布在整个波形上每两条线之间的间距正好是帧移对应的时间。用眼睛确认一下如果线太密说明帧移太小特征提取的计算量会很大如果太疏时间分辨率可能不够。另外一个很直观的检查方式是画某一帧的波形对比加窗前后的差异。加窗后帧边缘会被压到接近0中间基本不变这是汉明窗生效的标志figure; subplot(2,1,1); plot(frames(50, :)); title(第50帧 - 原始); subplot(2,1,2); plot(frames_win(50, :)); title(第50帧 - 加窗后);如果加窗后波形两端没被压制检查窗序列有没有正确乘上去很多人会在这一步发现repmat方向搞反了。5. 高频踩坑与排查技巧5.1 最后一帧不满怎么办手写分帧函数时如果信号长度不是“帧移的整数倍”最后一帧可能凑不齐 winlen 个点。我在上一节给的floor(...)1公式选择了“丢弃不完整帧”这是最保守的做法对大多数语音任务没问题因为它丢掉的通常只是尾部几十毫秒的静音。但有些场景下比如处理固定时间窗的生物信号丢掉尾部意味丢掉了可能有用的信息。这时可以选择补零zero-padding把最后一帧撑满用buffer函数的话它默认就会补零。如果你用自定义的分帧循环手动补零也很方便x_pad [x; zeros(winlen - mod(length(x) - winlen, wininc), 1)];补零后再用原来的方法分帧最后一帧就能形成完整帧。但要记住补零等同于人为引入了幅值跳变加窗后影响会被抑制一些特征计算时如果做频域分析补零帧的频谱会有一定误差最好在特征里标记出来或者直接不参与统计。5.2 行向量和列向量的坑这是MATLAB里最高频的报错来源。audioread返回的是列向量buffer返回的是列优先矩阵mean(x, 2)输出的也是列向量。但很多习惯Python的人或者从别的代码抄来的片段可能把信号写成行向量。一旦信号变成了 1×N 的行向量length(x)还能得到正确长度但切片、索引、后续的矩阵乘法很容易错。我的建议是在函数开头强制转换x x(:);让所有处理统一走列向量路径。在调用buffer之后记得判断是否需要转置buffer输出是“帧长×帧数”需要转成“帧数×帧长”时直接转置。注意如果 x 是复数信号比如处理频域数据或解析信号要用.而不是后者会做共轭转置。5.3 采样率不匹配帧长参数换算错的连锁反应帧长和帧移按毫秒算实际在使用时必须换算成采样点数。最容易翻车的场景是先用 44.1kHz 的音频调试了代码后来换成 16kHz 的数据忘了把帧长从round(0.025*44100)改成round(0.025*16000)。这样帧长变成1103点也还能跑但等效时间变成69毫秒已经超出语音平稳范围特征结果会莫名其妙地差。更隐蔽的是帧移也错了帧移从round(0.010*44100)441 变成160重叠比例从75%变成47%后续时序模型的特征帧率也跟着变了。我的习惯是把 fs 作为参数传进函数所有帧长设置都从毫秒实时换算不在外部写死function [frames, frames_win] frame_and_window_fs(x, fs, winlen_ms, wininc_ms) winlen round(winlen_ms * fs / 1000); wininc round(wininc_ms * fs / 1000); ... end5.4 双声道未处理导致的矩阵错乱如果 x 是 N×2 的双声道矩阵直接喂给bufferMATLAB会把整个2D矩阵展开成向量结果非常诡异。比如数据原本10000×2buffer会把它当作20000×1处理帧内容里混着左右声道的交替数据特征完全失真。处理方案很简单预处理阶段必须检查size(x, 2)要么取平均要么取单通道。我的代码模板里这个判断永远放在最前面养成条件反射。5.5 内存烧穿与小批量处理分帧后数据量会膨胀。假设一段10秒、16kHz的音频帧长400点、帧移160点大约620帧分帧矩阵大小是620×400×8字节约2MB不算大。但如果处理一小时的长录音或者批量处理几百个文件帧数会达到上百万矩阵直接占好几GB内存MATLAB直接卡死。应对办法是“分块处理”不要一次性把整个文件读进内存分帧而是按块读入、逐块处理。用audioread配合[x, fs] audioread(file.wav, [startSample, endSample])可以只读取指定区间。或者先把长音频切成小段比如10秒一段每段分帧处理最后合并特征。如果非要一次性处理注意定期用clear释放不再需要的变量尤其别在循环里累积大矩阵。另外如果机器上装了并行计算工具箱对每个文件做特征提取时可以用parfor并行显著缩短批量处理时间。这里提醒一下parfor的循环体内不要写入共享变量否则性能反而会下降。5.6 一个小技巧窗函数归一化有些任务里加窗会让信号整体能量变小因为窗的两端把幅度压低了。如果你希望加窗前后能量平均水平保持一致可以给窗乘一个归一化系数让窗序列的均值等于1w w / mean(w);这样处理之后语音特征的绝对数值范围更稳定。不过要小心如果一帧内信号大部分能量恰好集中在帧两端这种情况很少但并非没有归一化窗反而可能放大边界影响。多数情况下常规做法是直接使用标准汉明窗不做修正我个人只在做能量特征跨模型对比时才加这一步。6. 一点实用建议帧长、重叠比例与后续任务的匹配做完基础分帧加窗你会发现自己能做的事情一下子多了起来。这里再补充一些我在实际项目里反复权衡过的经验供选参数时参考。如果做的是基频提取、共振峰分析帧长建议取长一点比如30甚至40毫秒。因为这类分析需要足够的频率分辨率短帧算出来的频谱“糊”基频容易测偏。对应地帧移可以取10毫秒保证轨迹平滑。如果做的是语音识别前端特征MFCC、Fbank25ms帧长、10ms帧移是事实上的业界标准不要轻易改。不是因为这个参数对每个人最优而是因为所有预训练模型、后端模型都默认这套时间尺度改了反而匹配不上。如果做的是乐器音频分析、音乐信息检索帧长可以缩短到10到20毫秒因为音乐中瞬态信号很多比如鼓点、拨弦短帧能更好捕捉瞬时变化。这时候帧移5毫秒也不算过分。如果做的是实时流式处理比如实时VAD帧长会被系统的延迟预算卡住。假设要求处理延迟不超过50ms那帧长加帧移的总时长就得控制在50ms内常见方案是帧长20ms、帧移10ms加窗后立即出特征这样算法侧延迟就能控制在30ms左右。选参数没有绝对正确关键是理解每个参数背后的物理含义然后根据任务倒推需求。我踩过最大的坑就是在一开始不加思考地抄别人的参数后来换成自己的录音数据时结果一塌糊涂排查半天才发现是帧长和语音内容不匹配——内容是高音女声但还在用为低频男声优化的30ms帧长。调试分帧加窗这段代码其实没有什么高深秘诀就是多画图、多看中间结果。每次改动参数或换数据我至少会画三张图原始波形加帧边界、某几帧加窗前后对比、短时能量曲线和波形对齐图。三张图一摆出来大多数问题都能一眼定位。最后再分享一个小技巧在MATLAB里调试分帧代码时不要一上来就用真实的几十分钟录音。先用一个简单合成信号比如t (0:fs-1)/fs; x sin(2*pi*440*t)加几段间歇这样你心里完全清楚正确的输出应该是什么再去测分帧函数就很容易判断对错。用真实数据调试出问题你都不知道是分帧的bug还是录音本身的问题。本文还有配套的精品资源点击获取 MATLAB音频分帧加窗全解析：从原理到代码实战
简介本资源是一套面向信号处理初学者与音频算法实践者的MATLAB轻量级工具包聚焦音频分帧与加窗这一语音识别、特征提取等任务的基础预处理环节。包内含2个核心.m函数enframe.m实现带重叠的分帧frame2time.m提供帧时间戳映射及1个封装rar压缩文件总计3个文件体积仅1KB便于快速集成与调试。已有771人下载学习适用于课程实验、毕设开发或算法原型验证场景。用户可直接调用函数完成音频读取、自定义帧长/帧移设置、汉明窗加窗及帧时间对齐等全流程操作代码简洁规范、注释清晰省去从零编写分帧逻辑的时间特别适合作为语音信号处理入门的即用型脚本支撑。 做语音相关项目时拿到手的往往是一段连续的wav文件但无论做语音识别、声纹确认、情感分析还是简单的端点检测第一步几乎都逃不开同一个操作把长信号切成短块。这个短块就是“帧”切的过程就是“分帧”而分帧之后紧跟着要做的“加窗”则是决定后续特征质量的关键一步。这篇文章我就围绕 MATLAB 里的音频分帧和加窗把从原理到代码、从坑点到优化技巧一次性讲透适合刚接触语音信号处理的学生也适合想把手写算法跑稳一点的工程师参考。1. 为什么音频分帧是语音信号处理的“地基”1.1 音频信号到底有多“不稳定”语音信号本质上是非平稳的也就是说它的统计特性均值、方差、频谱形状随时间一直在变。你今天录一句“你好”波形细节和昨天录的绝对不可能完全一样甚至连同一个词内部的声母、韵母、音调转折都在持续变化。这样的信号如果整段拿去做傅里叶变换得到的频谱是所有时刻特性的“平均”等于把不同发音的细节搅在了一起特征完全失去意义。但语音又有一个很重要的性质叫“短时平稳性”虽然长期看变化剧烈但在很短时间内——比如10到30毫秒——声带振动和声道形状基本可以看作没变。这个特性是语音信号处理真正的立足点。分帧做的事就是把一段长语音切成一个个短段让每一帧都近似满足“平稳”条件这样才能对每一帧单独做频谱分析、提取特征。可以把它理解成电影胶片单看每一帧是静止的连续播放才有动态分帧就是在取那一帧一帧的画面。1.2 帧长和帧移怎么定才既不丢信息又不算太慢帧长不是随便拍的它直接决定频率分辨率。一般来说语音处理里帧长取20到30毫秒比较合适常用的是25毫秒。为什么是这个范围太短了比如5毫秒一帧内只包含几十个采样点频率分辨率很低而且无法覆盖一个完整的基音周期成年男性基频约100Hz周期10毫秒女性约200Hz周期5毫秒分析出来连音高都测不准太长了比如100毫秒语音的平稳假设就站不住脚一帧里可能包含多个音素的变化特征被“糊”掉了。帧移是相邻两帧起始点之间的距离通常取帧长的三分之一到二分之一也就是10毫秒左右。帧移决定了帧与帧之间有多少重叠。有人会问既然要分帧为什么不首尾相接、一帧挨着一帧切非要重叠因为如果完全不重叠帧与帧之间的衔接点附近的信息会被截断边界影响而且后续提取的特征时序平滑度很差。举个例子提取基频曲线时如果不重叠每一帧的基频值跳变很大画出来像锯齿叠加50%重叠后相邻帧共享一半数据特征曲线平滑很多。更重要的是许多后端算法比如HMM、CTC对特征的时间分辨率有要求10毫秒帧移是工程实践里经过大量验证的平衡点。用采样率换算成点数假设采样率fs16000Hz帧长25毫秒就是0.025×16000400个采样点帧移10毫秒是160个采样点。这就是代码里最常用的两个数字。1.3 为什么必须加窗不加窗会怎样分帧只是切出片段切这个动作本身就会引入问题。假设你截取一段400点的信号相当于把这个片段和一个矩形窗相乘——片段内为1、片段外为0。矩形窗在时域上看起来“干净”但到了频域它的频谱是sinc函数旁瓣很高会把信号频谱“抹”得一团糟。这就是频谱泄漏本来只在某个频率处有能量结果因为截断能量扩散到了旁边一大片频率上。真实语音处理里用的几乎都是非矩形窗最典型的是汉明窗Hamming Window。汉明窗的特点是两端趋近于0、中间接近1乘上信号后帧边缘的幅度被平滑压低避免截断处产生阶跃跳变频谱泄漏大幅减少。代价是窗本身等效降低了帧的有效长度频率分辨率略有下降但跟泄漏带来的问题相比这点损失完全可以接受。一句话总结分帧解决“平稳性”问题加窗解决“截断泄漏”问题。两者永远配套出现只分帧不加窗在大多数任务里都会直接拉低特征质量。2. MATLAB环境准备与音频数据读取2.1 读取音频的前置准备开始写代码前先把环境理清楚。MATLAB从R2016b开始音频读取推荐用audioread不再推荐旧版的wavread虽然还能用但很多新版MATLAB里已经标记为将要移除。另外确保你的机器上音频文件路径没有中文或特殊字符这一点在Windows上尤其容易踩坑某些情况下audioread读中文路径会直接报错或者读出来的数据不对。还要检查一下是否有 Signal Processing Toolbox信号处理工具箱。分帧这个操作本身用基础MATLAB就能写但后面如果想调用hamming、buffer、spectrogram这些函数就需要这个工具箱。如果没有也可以用基础函数手动生成窗函数后面我会给出替换方法。2.2 audioread 的正确打开方式[x, fs] audioread(speech.wav);第一返回值 x 是采样点数据第二返回值 fs 是采样率。这里有个细节如果音频是双声道x 是一个 N×2 的矩阵每一列是一个声道如果是单声道则是 N×1 列向量。很多新手在这里不检查就直接做后续处理结果矩阵维度对不上报错报得莫名其妙。测试时确认信息disp([采样率: , num2str(fs), Hz]); disp([数据大小: , num2str(size(x, 1)), 样本, , num2str(size(x, 2)), 声道]);audioread返回的 x 并不是真的“原始”数据它会根据文件格式自动做归一化。比如读16-bit WAV时MATLAB会把整数采样值除以32768转换为范围约 [-1, 1] 的浮点数。这是好事意味着你不用自己处理位深转换。2.3 预处理双声道合并、去直流、归一化一条龙拿到原始数据后我几乎总是先做三件事顺序固定第一双声道合并。除非做双耳声源定位等特殊任务绝大多数特征提取都只需要单声道。最简单的合并方式是取平均if size(x, 2) 1 x mean(x, 2); end还有一个备选方案是直接取左声道x x(:, 1)。两条路都行取平均的抗噪性略好一点但如果左右声道有相位差取平均可能造成部分频率抵消实际使用时看情况选。我用取平均多一点。第二去直流。录音设备往往会给信号叠加一个直流偏置表现在波形上是整个信号在0轴上下不对称。虽然大部分情况下直流分量对后续特征影响不大但在计算短时能量时直流偏置会带来一个不想要的常数项。去除方法很直接x x - mean(x);第三归一化。把信号峰值缩放到 [-1, 1] 范围避免后续计算中数值溢出也方便统一不同录音的音量差异x x / max(abs(x));这三步做完信号就可以进入分帧环节了。3. 手写一个完整的分帧加窗函数3.1 思路拆解从“想到”到“能跑”先说清楚目标输入是一段一维信号 x长度任意输出是一个二维矩阵 frames行数等于帧数列数等于帧长。实现分帧最核心的就是搞清楚两个索引问题每一帧的起始位置在哪一帧内包含哪些采样点设信号总长度为 siglen帧长为 winlen帧移为 wininc。那么总帧数的计算公式是num_frames floor((siglen - winlen) / wininc) 1这个公式怎么来的第一帧从第1个点开始占 winlen 个点之后每移动 wininc 个点取一帧。能取到完整一帧的最大起始位置是 siglen - winlen 1MATLAB索引从1开始所以可取的帧起点共有floor((siglen - winlen) / wininc) 1个。注意如果信号不够长比如 siglen winlen这个公式算出来是0甚至负数必须提前报错。第 i 帧的起始索引是start_idx (i - 1) * wininc 1结束索引就是end_idx start_idx winlen - 1这就是整个分帧的全部数学基础理解了这两行后面无论怎么写都跑不出这个框架。3.2 第一个版本循环实现作为baseline先写一个最直观的循环版本function frames framing_loop(x, winlen, wininc) % 信号分帧 - 循环实现 % x: 单声道信号(列向量) % winlen: 帧长(采样点数) % wininc: 帧移(采样点数) % 返回 frames: 帧数 x 帧长 的矩阵 x x(:); % 强制转成列向量 siglen length(x); num_frames floor((siglen - winlen) / wininc) 1; if num_frames 1 error(信号长度不足以构成一帧请减小帧长); end frames zeros(num_frames, winlen); for i 1:num_frames start_idx (i - 1) * wininc 1; frames(i, :) x(start_idx : start_idx winlen - 1); end end这个版本没有任何花哨技巧逻辑一目了然。性能上如果你的语音只有几秒钟帧数也就几百帧循环完全够用但如果处理的是长录音或批量处理大量文件循环就会成为瓶颈这时要看下面的高效版本。3.3 高效版本用 buffer 函数重写MATLAB 信号处理工具箱里有个专为分帧设计的函数buffer很多人没用过但它几乎就是为这个场景准备的。基本用法frames buffer(x, winlen, overlap);其中 overlap 是重叠的采样点数等于 winlen - wininc。比如帧长400点、帧移160点重叠就是240点。注意buffer有几个跟直觉不符的细节默认返回的矩阵是“帧长×帧数”每一列是一帧通常需要转置才能得到我们习惯的“帧数×帧长”格式。默认会在信号开头补零以保证第一帧的起点是信号的“历史缓冲”。我们通常不想要这个补零要加nodelay参数取消。如果信号长度不能正好整除最后一帧可能不满buffer默认会在末尾补零填满。补零本身不一定是坏事但要心里有数别让补零的帧混进特征计算。实际推荐用法frames buffer(x, winlen, winlen - wininc, nodelay);这一行等价于上面整个循环而且是用底层C实现速度优势明显。实测下来处理几十万点的信号循环可能要一两秒buffer基本瞬间完成。我的建议是理解循环实现的原理代码里优先用buffer因为高效、可靠、边界处理更完善。如果不想依赖 Signal Processing Toolbox比如在一些精简版MATLAB环境里也可以用矩阵索引 repmat实现类似的效果idx (1:winlen) (0:(num_frames-1)) * wininc; % 构造索引矩阵 frames x(idx);这种方法既快又不需要额外工具箱但要求你能一次性构造出完整的索引矩阵比较吃内存。3.4 加窗环节汉明窗的实现细节分帧完成后接下来就是加窗。最常见的窗函数是汉明窗MATLAB里可以直接调用w hamming(winlen, periodic);注意第二个参数periodic和symmetric的区别。谈一下这个很多人会忽略但实际影响不小。语音/音频处理里推荐用periodic窗因为它末端多采一个点处理后可以周期延拓适合频谱分析symmetric窗适合做FIR滤波器设计。两者在窗长不大时差别很小但养成习惯、用对参数能少莫名其妙的误差。如果不想依赖工具箱可以手动生成汉明窗n 0:winlen-1; w 0.54 - 0.46 * cos(2 * pi * n / (winlen - 1));这个公式就是汉明窗的定义0.54和0.46是两个固定系数改成0.5和0.5就是汉宁窗。手动生成的数值跟hamming(winlen, symmetric)结果一致。加窗的操作本质是让每一帧信号逐点乘上窗序列。一个常见错误是维度没对齐frames 是“帧数×帧长”窗 w 是 1×winlen用 MATLAB 的隐式扩展时直接frames .* w是可以的R2016b之后但为了代码清晰我习惯写成frames_win frames .* repmat(w, size(frames, 1), 1);repmat把窗函数复制成和 frames 同样大小的矩阵然后对应点相乘。虽然隐式扩展更简洁但repmat写法在旧版本MATLAB里也能跑兼容性更好。3.5 完整函数代码把分帧和加窗串起来给一个可以直接抄走的完整函数function [frames, frames_win] frame_and_window(x, winlen, wininc) % 音频分帧加窗 % 输入: % x : 单声道信号(列向量) % winlen : 帧长(采样点数) % wininc : 帧移(采样点数) % 输出: % frames : 分帧结果, 帧数 x 帧长 % frames_win: 加窗结果, 帧数 x 帧长 x x(:); siglen length(x); num_frames floor((siglen - winlen) / wininc) 1; if num_frames 1 error(信号长度不足以构成一帧); end % 分帧 frames buffer(x, winlen, winlen - wininc, nodelay); % 如果没装信号处理工具箱改用下面这行替代: % idx (1:winlen) (0:(num_frames-1)) * wininc; % frames x(idx); % 加窗 w hamming(winlen, periodic); % 没有工具箱就手动生成 % w 0.54 - 0.46 * cos(2*pi*(0:winlen-1)/(winlen-1)); frames_win frames .* repmat(w, size(frames, 1), 1); end主脚本测试[x, fs] audioread(speech.wav); if size(x, 2) 1, x mean(x, 2); end x x - mean(x); x x / max(abs(x)); winlen round(0.025 * fs); wininc round(0.010 * fs); [frames, frames_win] frame_and_window(x, winlen, wininc); fprintf(原始信号: %d 样本, 采样率 %d Hz\n, length(x), fs); fprintf(分帧结果: %d 帧, 每帧 %d 点\n, size(frames, 1), size(frames, 2));跑通这段你的分帧加窗流程就算立起来了。4. 分帧之后干什么短时能量、过零率与可视化4.1 短时能量计算的三种写法分帧加窗不是终点它只是给后续特征计算提供“数据容器”。最常见的快速应用就是算短时能量它在端点检测区分静音和语音、语音活动检测VAD里用途很广。公式很简单每一帧所有采样点的平方和。energy sum(frames.^2, 2);返回一个 N×1 向量N是帧数。如果要归一化可以除以帧长得到平均能量energy_avg sum(frames.^2, 2) / winlen;如果你想算的是分贝形式比如用在对数域里做特征加上energy_db 10 * log10(energy_avg eps);加 eps 是为了防止 log10(0) 出现无穷小语音静音段能量本来就接近0这里常见坑不处理会得出 -Inf后面画图会很难看。实际拿到能量序列后很多人会忽略它是一个“按帧索引”的序列不是“按时间”的序列。要做时间对齐每一帧的实际时间戳大概是(i-1)*wininc/fs秒。这个在画图或跟其他模态数据对齐时非常关键。4.2 短时过零率实战过零率Zero Crossing Rate, ZCR是另一个经典短时特征表示一帧内信号穿越零轴的次数常用于区分清音和浊音、区分语音和环境噪声。实现很直接zcr sum(abs(diff(sign(frames), 1, 2)), 2) / (2 * (winlen - 1));这里拆解一下sign(frames)把每个采样点变成1或-10保持不变diff(..., 1, 2)对每一帧、沿时间方向做差分。如果相邻两个点符号不同差分结果是2或-2绝对值再求和就得到了符号变化的次数。除以2*(winlen-1)是为了做归一化。注意一个细节diff假设信号已经是归一化到 [-1,1] 的浮点信号。对于整数信号低频漂移会让过零率失真。所以前面强调的“去直流、归一化”预处理在这里就发挥作用了。把短时能量和过零率合起来看已经可以用来做简单的语音活动检测了。比如设定能量阈值低于阈值的帧判为静音对于能量较高但过零率极高的帧往往对应的是清辅音或噪声。4.3 检查分帧结果用plot看帧边界写完算法第一件事永远是“眼见为实”。我会用代码直观检查分帧是否合理figure; t (0:length(x)-1) / fs; plot(t, x, b); hold on; % 每隔10帧画一条帧起始线 for i 1:10:size(frames, 1) start_t (i - 1) * wininc / fs; xline(start_t, --r, LineWidth, 0.5); end xlabel(时间 (s)); ylabel(幅度); title(分帧边界可视化);运行后红色虚线应该均匀分布在整个波形上每两条线之间的间距正好是帧移对应的时间。用眼睛确认一下如果线太密说明帧移太小特征提取的计算量会很大如果太疏时间分辨率可能不够。另外一个很直观的检查方式是画某一帧的波形对比加窗前后的差异。加窗后帧边缘会被压到接近0中间基本不变这是汉明窗生效的标志figure; subplot(2,1,1); plot(frames(50, :)); title(第50帧 - 原始); subplot(2,1,2); plot(frames_win(50, :)); title(第50帧 - 加窗后);如果加窗后波形两端没被压制检查窗序列有没有正确乘上去很多人会在这一步发现repmat方向搞反了。5. 高频踩坑与排查技巧5.1 最后一帧不满怎么办手写分帧函数时如果信号长度不是“帧移的整数倍”最后一帧可能凑不齐 winlen 个点。我在上一节给的floor(...)1公式选择了“丢弃不完整帧”这是最保守的做法对大多数语音任务没问题因为它丢掉的通常只是尾部几十毫秒的静音。但有些场景下比如处理固定时间窗的生物信号丢掉尾部意味丢掉了可能有用的信息。这时可以选择补零zero-padding把最后一帧撑满用buffer函数的话它默认就会补零。如果你用自定义的分帧循环手动补零也很方便x_pad [x; zeros(winlen - mod(length(x) - winlen, wininc), 1)];补零后再用原来的方法分帧最后一帧就能形成完整帧。但要记住补零等同于人为引入了幅值跳变加窗后影响会被抑制一些特征计算时如果做频域分析补零帧的频谱会有一定误差最好在特征里标记出来或者直接不参与统计。5.2 行向量和列向量的坑这是MATLAB里最高频的报错来源。audioread返回的是列向量buffer返回的是列优先矩阵mean(x, 2)输出的也是列向量。但很多习惯Python的人或者从别的代码抄来的片段可能把信号写成行向量。一旦信号变成了 1×N 的行向量length(x)还能得到正确长度但切片、索引、后续的矩阵乘法很容易错。我的建议是在函数开头强制转换x x(:);让所有处理统一走列向量路径。在调用buffer之后记得判断是否需要转置buffer输出是“帧长×帧数”需要转成“帧数×帧长”时直接转置。注意如果 x 是复数信号比如处理频域数据或解析信号要用.而不是后者会做共轭转置。5.3 采样率不匹配帧长参数换算错的连锁反应帧长和帧移按毫秒算实际在使用时必须换算成采样点数。最容易翻车的场景是先用 44.1kHz 的音频调试了代码后来换成 16kHz 的数据忘了把帧长从round(0.025*44100)改成round(0.025*16000)。这样帧长变成1103点也还能跑但等效时间变成69毫秒已经超出语音平稳范围特征结果会莫名其妙地差。更隐蔽的是帧移也错了帧移从round(0.010*44100)441 变成160重叠比例从75%变成47%后续时序模型的特征帧率也跟着变了。我的习惯是把 fs 作为参数传进函数所有帧长设置都从毫秒实时换算不在外部写死function [frames, frames_win] frame_and_window_fs(x, fs, winlen_ms, wininc_ms) winlen round(winlen_ms * fs / 1000); wininc round(wininc_ms * fs / 1000); ... end5.4 双声道未处理导致的矩阵错乱如果 x 是 N×2 的双声道矩阵直接喂给bufferMATLAB会把整个2D矩阵展开成向量结果非常诡异。比如数据原本10000×2buffer会把它当作20000×1处理帧内容里混着左右声道的交替数据特征完全失真。处理方案很简单预处理阶段必须检查size(x, 2)要么取平均要么取单通道。我的代码模板里这个判断永远放在最前面养成条件反射。5.5 内存烧穿与小批量处理分帧后数据量会膨胀。假设一段10秒、16kHz的音频帧长400点、帧移160点大约620帧分帧矩阵大小是620×400×8字节约2MB不算大。但如果处理一小时的长录音或者批量处理几百个文件帧数会达到上百万矩阵直接占好几GB内存MATLAB直接卡死。应对办法是“分块处理”不要一次性把整个文件读进内存分帧而是按块读入、逐块处理。用audioread配合[x, fs] audioread(file.wav, [startSample, endSample])可以只读取指定区间。或者先把长音频切成小段比如10秒一段每段分帧处理最后合并特征。如果非要一次性处理注意定期用clear释放不再需要的变量尤其别在循环里累积大矩阵。另外如果机器上装了并行计算工具箱对每个文件做特征提取时可以用parfor并行显著缩短批量处理时间。这里提醒一下parfor的循环体内不要写入共享变量否则性能反而会下降。5.6 一个小技巧窗函数归一化有些任务里加窗会让信号整体能量变小因为窗的两端把幅度压低了。如果你希望加窗前后能量平均水平保持一致可以给窗乘一个归一化系数让窗序列的均值等于1w w / mean(w);这样处理之后语音特征的绝对数值范围更稳定。不过要小心如果一帧内信号大部分能量恰好集中在帧两端这种情况很少但并非没有归一化窗反而可能放大边界影响。多数情况下常规做法是直接使用标准汉明窗不做修正我个人只在做能量特征跨模型对比时才加这一步。6. 一点实用建议帧长、重叠比例与后续任务的匹配做完基础分帧加窗你会发现自己能做的事情一下子多了起来。这里再补充一些我在实际项目里反复权衡过的经验供选参数时参考。如果做的是基频提取、共振峰分析帧长建议取长一点比如30甚至40毫秒。因为这类分析需要足够的频率分辨率短帧算出来的频谱“糊”基频容易测偏。对应地帧移可以取10毫秒保证轨迹平滑。如果做的是语音识别前端特征MFCC、Fbank25ms帧长、10ms帧移是事实上的业界标准不要轻易改。不是因为这个参数对每个人最优而是因为所有预训练模型、后端模型都默认这套时间尺度改了反而匹配不上。如果做的是乐器音频分析、音乐信息检索帧长可以缩短到10到20毫秒因为音乐中瞬态信号很多比如鼓点、拨弦短帧能更好捕捉瞬时变化。这时候帧移5毫秒也不算过分。如果做的是实时流式处理比如实时VAD帧长会被系统的延迟预算卡住。假设要求处理延迟不超过50ms那帧长加帧移的总时长就得控制在50ms内常见方案是帧长20ms、帧移10ms加窗后立即出特征这样算法侧延迟就能控制在30ms左右。选参数没有绝对正确关键是理解每个参数背后的物理含义然后根据任务倒推需求。我踩过最大的坑就是在一开始不加思考地抄别人的参数后来换成自己的录音数据时结果一塌糊涂排查半天才发现是帧长和语音内容不匹配——内容是高音女声但还在用为低频男声优化的30ms帧长。调试分帧加窗这段代码其实没有什么高深秘诀就是多画图、多看中间结果。每次改动参数或换数据我至少会画三张图原始波形加帧边界、某几帧加窗前后对比、短时能量曲线和波形对齐图。三张图一摆出来大多数问题都能一眼定位。最后再分享一个小技巧在MATLAB里调试分帧代码时不要一上来就用真实的几十分钟录音。先用一个简单合成信号比如t (0:fs-1)/fs; x sin(2*pi*440*t)加几段间歇这样你心里完全清楚正确的输出应该是什么再去测分帧函数就很容易判断对错。用真实数据调试出问题你都不知道是分帧的bug还是录音本身的问题。本文还有配套的精品资源点击获取