企业官网建设流程全解析

简介：本资源是一套面向信号处理初学者与音频算法实践者的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毫秒帧移是工程实践里经过大量验证的平衡点。

用采样率换算成点数：假设采样率fs=16000Hz，帧长25毫秒就是0.025×16000=400个采样点，帧移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 + 1（MATLAB索引从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或-1（0保持不变），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); ... end

5.4 双声道未处理导致的矩阵错乱

如果 x 是 N×2 的双声道矩阵，直接喂给buffer，MATLAB会把整个2D矩阵展开成向量，结果非常诡异。比如数据原本10000×2，buffer会把它当作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 一个小技巧：窗函数归一化

有些任务里，加窗会让信号整体能量变小，因为窗的两端把幅度压低了。如果你希望加窗前后能量平均水平保持一致，可以给窗乘一个归一化系数，让窗序列的均值等于1：

w = w / mean(w);

这样处理之后，语音特征的绝对数值范围更稳定。不过要小心，如果一帧内信号大部分能量恰好集中在帧两端（这种情况很少但并非没有），归一化窗反而可能放大边界影响。多数情况下，常规做法是直接使用标准汉明窗不做修正，我个人只在做能量特征跨模型对比时才加这一步。

6. 一点实用建议：帧长、重叠比例与后续任务的匹配

做完基础分帧加窗，你会发现自己能做的事情一下子多了起来。这里再补充一些我在实际项目里反复权衡过的经验，供选参数时参考。

如果做的是基频提取、共振峰分析，帧长建议取长一点，比如30甚至40毫秒。因为这类分析需要足够的频率分辨率，短帧算出来的频谱“糊”，基频容易测偏。对应地，帧移可以取10毫秒，保证轨迹平滑。

如果做的是语音识别前端特征（MFCC、Fbank），25ms帧长、10ms帧移是事实上的业界标准，不要轻易改。不是因为这个参数对每个人最优，而是因为所有预训练模型、后端模型都默认这套时间尺度，改了反而匹配不上。

如果做的是乐器音频分析、音乐信息检索，帧长可以缩短到10到20毫秒，因为音乐中瞬态信号很多，比如鼓点、拨弦，短帧能更好捕捉瞬时变化。这时候帧移5毫秒也不算过分。

如果做的是实时流式处理（比如实时VAD），帧长会被系统的延迟预算卡住。假设要求处理延迟不超过50ms，那帧长加帧移的总时长就得控制在50ms内，常见方案是帧长20ms、帧移10ms，加窗后立即出特征，这样算法侧延迟就能控制在30ms左右。

选参数没有绝对正确，关键是理解每个参数背后的物理含义，然后根据任务倒推需求。我踩过最大的坑就是在一开始不加思考地抄别人的参数，后来换成自己的录音数据时，结果一塌糊涂，排查半天才发现是帧长和语音内容不匹配——内容是高音女声，但还在用为低频男声优化的30ms帧长。

调试分帧加窗这段代码，其实没有什么高深秘诀，就是多画图、多看中间结果。每次改动参数或换数据，我至少会画三张图：原始波形加帧边界、某几帧加窗前后对比、短时能量曲线和波形对齐图。三张图一摆出来，大多数问题都能一眼定位。

最后再分享一个小技巧：在MATLAB里调试分帧代码时，不要一上来就用真实的几十分钟录音。先用一个简单合成信号，比如t = (0:fs-1)/fs; x = sin(2*pi*440*t)'，加几段间歇，这样你心里完全清楚正确的输出应该是什么，再去测分帧函数就很容易判断对错。用真实数据调试，出问题你都不知道是分帧的bug还是录音本身的问题。

本文还有配套的精品资源，点击获取