简介ITU-T P.862标准即感知语音质量评价PESQ由国际电信联盟制定是全球广泛采用的客观语音质量评估方法。它通过比较原始与处理后的语音信号综合信号失真、噪声、回声及延迟等因素输出1.0至4.5的感知质量得分常用于语音编码器评估、网络传输质量监测、设备测试及语音增强技术验证。面向通信工程师、音频处理研发人员和语音质量研究学者该资源提供了基于MATLAB的PESQ实现与配套测试材料。压缩包共8个文件涵盖2个M脚本、2个WAV样本、2个RAW音频数据及2个TXT文档整体仅332KB结构简洁。M脚本用于计算PESQ得分测试脚本可验证算法正确性音频样本支持直接运行与结果对比说明文档则包含使用指引和授权条款。资源已有641人学习下载借助示例音频与脚本读者可直观理解PESQ评估流程为后续算法优化和质量研究提供参考。 做语音通信、音视频质量评估的同行应该都绕不开一个东西ITU-T P.862也就是俗称的 PESQ全称 Perceptual Evaluation of Speech Quality。如果你在项目里接到过“给这条语音处理链路打个分”的需求或者想量化某个编解码器把语音糟蹋成什么样、某次网络抖动对通话造成了多大损伤PESQ 大概率是你的第一选择。它是一套客观语音质量评估标准核心逻辑是把参考语音和经过系统处理后的输出语音做对比输出一个贴近人耳主观感受的 MOS 分值。VoIP 通话质量测试、编解码器选型、回声消除效果验证、网络损伤模拟这些场景里PESQ 几乎是行业默认的度量尺。这篇文章不准备把标准条款从头到尾念一遍我更想结合这几年在项目里实际跑 PESQ 的经验讲清楚它到底做了什么、跑测试有哪些坑、分数怎么读才不出错。无论你是刚接触音质评估的新人还是已经在用但经常被结果问号困扰的老手都可以拿这篇当一份实操备忘录。1. P.862在评估体系里的位置1.1 为什么需要客观评估主观MOS的痛语音质量最终极的评判标准是人耳也就是主观试听。行业内通用的做法是找一批听音员让他们对一段语音按 1 到 5 分打分最后算平均分这就是主观 MOSMean Opinion Score。问题是这套流程又贵又慢几十个听音员、专业听音室、严格的测试流程走下来一个版本要等好几周。而且主观分数天然带波动换个听音员、换个时间点结果可能差出 0.3 分这在版本迭代频繁的开发环境里根本没法用。所以行业里一直想要一把“尺子”用算法算出一个足够接近人耳主观判断的分数可以跑回归测试、可以横向对比不同算法、可以挂到自动化流水线里。早期的信噪比 SNR 做得太粗糙它逐点比较波形差异但人耳对失真的感知不是线性的很多在 SNR 里显得很大的误差人耳根本注意不到反过来很多 SNR 看不出差异的损伤人耳却能敏锐察觉。ITU-T 在 2001 年发布 P.862就是想把“人耳感知”这个事用数学模型复刻出来。我记得早期做回声消除AEC性能评估的时候领导直接给一句“这个版本音质有没有变差”没有 PESQ 这种客观工具的话我只能在开发机和测试机之间来回切 A/B 试听耳朵都快听麻了。后来上了 PESQ每次改动跑一遍拿分数说话效率完全不一样。1.2 PESQ的核心参考、退化、感知差异PESQ 的输入有两个信号一个是参考信号也就是原始干净语音另一个是退化信号也就是经过被测系统处理之后输出来的语音。它要做的事情就是比较这两个信号差异但要命的是这个差异不能直接在波形层面比得先映射到“人耳听感”层面再比。算法会模拟人耳的听觉处理过程包括频率到 Bark 域的映射、响度密度的计算、掩蔽效应的模拟等等把两个信号都转换到感知域然后计算它们之间的距离。距离小说明损伤很小距离大说明损伤明显。最终输出的结果是一个 raw 分范围大概在 -0.5 到 4.5 之间再经过映射变成大家习惯的 MOS-LQO 分值。整个过程说起来简单但内部实现相当复杂光是时间对齐、电平归一化、感知滤波这些预处理步骤就够写一大篇。它的核心价值在于不关心失真是什么形式只关心失真人耳能不能听出来、有多烦人。1.3 P.862家族版本与扩展P.862 不是一个孤立文本它配套了好几个文件和扩展很多人在项目里容易混。标准编号名称/内容适用场景ITU-T P.862核心算法 PESQ用于 8kHz 采样率的窄带语音传统电话、窄带 VoIP、G.711/G.729 编解码评估ITU-T P.862.1定义 raw 分到 MOS-LQO 的逻辑回归映射让结果更贴近主观 MOS需要输出“可直接对外沟通”的 MOS 分时ITU-T P.862.2宽带扩展支持 16kHz 采样率通常叫 PESQ-WB宽带语音、VoLTE、高清语音HD Voice场景ITU-T P.862.3应用指南给使用示例和约束条件决定测试方法和边界时有依据实际项目里我们一般直接说“跑一下 PESQ”但心里要清楚测的是哪个版本、用的是哪套参数。同一段语音窄带和宽带跑出来的分可能差很多对外汇报/对内回归要提前统一口径不然会闹笑话。2. PESQ评分逻辑从波形到感知距离的换算2.1 感知模型模拟人耳不是简单比对波形PESQ 最核心的设计思路是把“声音信号”变成“人耳听到的感觉”。人耳并不是均匀感知所有频率的对 1kHz 到 4kHz 的中频段最敏感对低频和高频迟钝得多。另外还有掩蔽效应一个强的声音会掩盖旁边弱的声音如果退化信号里混入的噪声恰好被原语音的强分量掩盖掉了人耳根本听不到那在感知域里这项差异就应该被忽略。PESQ 内部会做一组听觉变换先做短时傅里叶变换把声音拆解成时频表示再映射到 Bark 尺度然后计算每个频带的响度密度。这个过程相当于把声音“翻译”成人耳听神经收到的刺激强度模式。接着对参考信号和退化信号各自做这套变换再求差。因为是在感知域做差所以算出来的“距离”天然更接近人的主观感受。这也是为什么 PESQ 比 SNR 强得多。SNR 把静音区一个微弱的底噪算作很大的相对误差但人耳在别人说话的时候对这点底噪基本无感。PESQ 里这种失真会被掩蔽掉对最终分数影响很小这才符合“听起来怎么样”的真实体验。2.2 时间对齐最容易理解错的一环跑 PESQ 时最容易忽略但又影响巨大的环节是时间对齐。被测系统比如 VoIP 网关或网络模拟器会给信号带来延迟。你拿参考信号和经过系统出来的退化信号直接逐帧比较时间错位哪怕几十毫秒感知域里差异都会爆表出来的分数会离谱地低。PESQ 内部其实自带对齐机制它会对两个信号做包络分析和相关计算先粗对齐再精对齐尽量补偿固定时延。但要注意的是它补偿的是整体时延如果被测系统引入了时变时延也就是抖动尤其抖动幅度很大PESQ 的对齐能力就会捉襟见肘。实测下来规整的固定 100 毫秒时延PESQ 自己就能处理得很好但网络模拟器跑出忽大忽小的瞬时抖动分数通常会偏低而且这个偏低不完全代表听感变差更像是对齐阶段“报错”了。所以处理抖动比较大的信号时有两个选择一是在跑 PESQ 前手动做一次粗对齐把两个信号的大致起点拉齐二是改用专门处理时变时延的测试方案比如 POLQA 或者结合抖动缓冲机制再测。2.3 从扰动到MOS分P.862.1映射PESQ 内部算完感知域差异之后会生成一个 raw 分这个分数不太适合直接跟主观试听结果挂钩。ITU-T 后来发布 P.862.1定义了 raw 分到 MOS-LQO 的映射用的是一个逻辑回归函数呈 S 形曲线把分数压到跟主观 MOS 差不多可比的区间。映射之后4.5 分以上基本是透明传输人耳听不出和原始语音的区别4.0 到 4.5 之间属于质量良好可能只有轻微损伤3.0 到 3.5 就是能明显听出失真但仍可接受低于 2.5 基本属于通信质量崩了听感已经很难受了。这是我自己习惯的分段供参考具体阈值没有强制标准但大体趋势是公认的。有一点要提醒PESQ 分数区间上限是 4.5 左右不是 5.0。所以看到 4.5 不用怀疑是不是满分已经是这个尺子的天花板了。做横向对比时同样条件下不同版本的分数才更有意义别纠结绝对数值。3. 实操完整跑一次PESQ测试3.1 工具选型官方代码还是开源实现跑 PESQ 的工具来源主要有两个一是 ITU-T 官方发布的参考代码C 语言实现从 ITU 官网可以下载编译成可执行文件二是各种开源移植和封装比如 Python 的 pypesq、pesq 等库很多都是对官方 C 代码的编译封装接口更友好。如果是做一次性实验、验证概念直接用 Python 封装最省事。但如果是搭自动化回归测试平台需要长期稳定、结果可追溯我更倾向把官方 C 代码编译成命令行工具输入输出都是文件报错也好查。实测中有些开源封装对输入格式的严格程度不一样同一个 WAV 文件这个库能跑那个库可能因为头部信息不规范直接报错这种一致性问题在自动化流程里很头疼。官方参考代码的典型命令行用法是这样的# 窄带模式8000Hz采样率 ./pesq 8000 reference.wav degraded.wav # 宽带模式16000Hz采样率 ./pesq 16000 reference.wav degraded.wav运行结束结果会写在当前目录的 results.txt 里里面包含参考文件、退化文件、raw 分和映射后的 MOS-LQO 分。注意官方代码对文件名比较敏感路径里尽量别带空格和中文不然容易踩奇怪的坑。3.2 测试语音样本准备PESQ 是对语音设计的算法输入必须是语音内容拿纯音乐、纯噪声去跑出来的分数没有意义。测试语音一般选 8 到 15 秒的连续话语太短了统计样本不够分数波动大太长了计算时间变长且容易出现对齐偏移。内容上建议包含不同音节、有静音段落也有连续语音最好模拟真实通话场景。我常用的是 ITU-T P.50 人工嘴录音或者自录的清晰普通话但要保证内容是连续的语义流不是零散的词。采样率要和被测系统匹配窄带系统定 8k宽带系统定 16k。量化位数统一 16bit PCM这是最稳的组合。文件格式 WAV 优先虽然官方代码也支持 raw PCM但得自己保证格式参数别传错。准备参考信号和退化信号时有一条铁律两个信号必须同源只是其中一个经过被测系统处理。拿两段独立录音去跑 PESQ 没有任何意义那测的不是系统损伤是两个语音内容的天然差异。3.3 执行过程与结果解读我习惯的做法是先建立起一套标准的测试语音集固定几段内容录制参考信号后保存好。每次评估一个新系统把参考信号作为输入经过被测系统采集输出再把成对的参考/退化信号丢给 PESQ。比如评估一个语音编码器对音质的影响就直接拿参考语音经过编码器编解码输出接 PESQ评估网络对语音的影响就丢进网络损伤模拟器再采集。跑完会有两个数值需要注意raw 分和 MOS-LQO。平时我们说的是 MOS-LQO对外汇报也用这个raw 分更多是调试时看趋势用因为它的变化敏感度更高有些细小的损伤在映射后变化不明显但 raw 分能看出差异。对比两个版本时多看几个样本的平均分单条样本的随机波动很大最好凑 5 到 10 组语音取平均和标准差一起看。我在实际项目里习惯顺手做个表格把每个样本的 raw 分、映射分都记下来标出最高最低和平均。只报一个平均分其实信息量不够标准差大说明系统不稳定比如时延抖动起伏大或者某段语音被特殊处理过。4. 常见问题与排查技巧实录4.1 参考信号和退化信号不同源这个问题听起来低级但我真见过不止一次。有同事把 A 会议的参考录音和 B 会议的输出录音配对去测PESQ 直接给了 1 分左右他还以为是系统出了问题排查了半天。这类问题其实很好判断PESQ 分数如果低到离谱比如低于 1.5但主观听感并没有完全不可懂大概率是对齐或者同源出了问题。可以先用波形工具把两个文件的波形并排看一下如果语音包络位置都对不上赶紧换配对。还有一种情况是参考和退化信号采样率不同比如参考是 16k 采集的系统输出是 8k 的直接拿给 PESQ 跑会报错或分数失真。务必在进入测试前统一格式。4.2 时延和长度不一致PESQ 对信号长度有要求参考信号和退化信号的时长差异不能太大官方代码一般会截短到两个信号中较短的长度再处理。如果退化信号比参考信号长很多比如网络抖缓冲把音频尾部拉长了几百毫秒最终截断后的结果可能丢掉了部分真实内容分数偏差很大。我的处理办法是在采集退化信号后先做一次静音检测把前导静音和后置静音裁掉再跑 PESQ。这不仅是为了对齐也是为了让 PESQ 自己那套时间对齐发挥更好。信号内部如果有时变延迟比如网络模拟器导致的抖动可以在对比时用固定丢包/固定抖动配置尽量让延迟分布平稳这样 PESQ 的结果才稳定可解释。4.3 采样率、量化位数与文件头官方 C 代码对 WAV 头支持有点老派有些现代工具生成的 WAV 文件头比如带有额外 chunk 信息它不认会导致读文件失败或者采样数据错位。而且 PESQ 对量化位数有要求双声道、24bit、浮点 WAV 这些格式大多数封装不支持。最好在测试链路入口统一加一个音频格式转码步骤一律转成单声道、16bit PCM、WAV采样率按需求 8k 或 16k。看起来多了一步实际能省掉一堆莫名其妙的报错。我在自动化回归脚本里是这么写的ffmpeg -y -i input.wav -ac 1 -ar 16000 -sample_fmt s16 aligned.wav跑 PESQ 之前所有文件先过一遍这个命令格式问题基本绝迹。4.4 PESQ和主观听感对不上的典型场景任何客观模型都有盲区PESQ 也不例外。我遇到最明显的一个情况是某些语音增强算法在安静环境下做了很强的降噪PESQ 分数反而下降了但主观试听时大家觉得听起来更干净了。原因在于降噪算法对噪声的抑制被 PESQ 感知成了信号畸变而人耳对稳态底噪和轻微音乐噪声的容忍度比 PESQ 高。还有一个典型场景是参考信号本身包含一定环境噪声时PESQ 容易把噪声变化也算进失真里。如果你的测试系统是在真实环境录音而不是在理想安静环境使用 PESQ 前要先想清楚噪声要不要算作被测系统的损伤。如果系统本来就是降噪类算法建议结合主观试听和 PESQ 一起看不要只信分数。5. PESQ之后POLQA与评估方案的选型思考5.1 P.863POLQA改进了什么PESQ 发布之后通信技术演进很快从 3G 到 4G/5G从窄带到宽带再到超宽带PESQ 基于 8k 窄带设计的感知模型逐渐不够用了。ITU-T 在 2011 年发布 P.863也就是 POLQA支持从 8k 到 48kHz 采样率能覆盖超宽带语音处理时变延迟的能力也更强对现代编解码器的适应性更好。实际测评中POLQA 在宽带和超宽带的分数与主观感受的相关性确实比 PESQ 好尤其是处理 3GPP EVS、Opus 这类现代编码器时PESQ 的分数经常偏低或区分度不足。如果项目涉及到 VoLTE、高清语音、统一通信这类场景预算和时间允许的话直接上 POLQA 会更省心。5.2 还在用PESQ的场景但这不意味着 PESQ 该被丢掉。很多存量系统仍然是窄带语音比如传统电话网关、旧式 IVR 系统PESQ 对这些场景的适配非常成熟。而且 PESQ 计算量相对小、算法透明、参考代码稳定嵌入式设备或自动化测试环境里跑起来非常省事。一些监管合规或者客户合同里甚至明确指定要用 P.862 做验收这时候 POLQA 反而不合适。所以我的建议是按被测系统的采样率选型。8k 窄带系统的验收和回归测试用 PESQ 没问题16k 以上特别是超宽带系统有条件就上 POLQA。两种工具的结果不能直接换算对比换工具等于换尺子历史数据会断掉要提前评估。5.3 评估语音质量时我的一些习惯用 PESQ 这几年我养成了几个习惯分享给大家参考。第一每次评估先定好“尺子”再动手测试前确定是窄带还是宽带、用 raw 分还是 MOS-LQO 汇报全程保持一致。第二测试语音集固定且足够多样别每次开会临时换语音不然历史数据没法比较。第三PESQ 分数只作为筛选和回归手段最终上线前一定结合主观试听尤其是声音的“自然度”这种指标客观模型很难完全反映。最后再说一个小技巧当你拿 PESQ 做对比测试时尽量让两个版本在完全相同的条件下跑包括同一台机器、同一组语音、同一次采集环境。曾经我有一次对比两个降噪版本A 版本跑出来的分数比 B 高后来发现是 A 版本测试时网络模拟器没开抖动B 版本开了差异根本不是算法优劣纯粹是测试条件不一致。这类低级失误说多了都是泪但把流程规范化之后基本就能避免。本文还有配套的精品资源点击获取
PESQ语音质量评估实战：从原理到测试避坑指南
简介ITU-T P.862标准即感知语音质量评价PESQ由国际电信联盟制定是全球广泛采用的客观语音质量评估方法。它通过比较原始与处理后的语音信号综合信号失真、噪声、回声及延迟等因素输出1.0至4.5的感知质量得分常用于语音编码器评估、网络传输质量监测、设备测试及语音增强技术验证。面向通信工程师、音频处理研发人员和语音质量研究学者该资源提供了基于MATLAB的PESQ实现与配套测试材料。压缩包共8个文件涵盖2个M脚本、2个WAV样本、2个RAW音频数据及2个TXT文档整体仅332KB结构简洁。M脚本用于计算PESQ得分测试脚本可验证算法正确性音频样本支持直接运行与结果对比说明文档则包含使用指引和授权条款。资源已有641人学习下载借助示例音频与脚本读者可直观理解PESQ评估流程为后续算法优化和质量研究提供参考。 做语音通信、音视频质量评估的同行应该都绕不开一个东西ITU-T P.862也就是俗称的 PESQ全称 Perceptual Evaluation of Speech Quality。如果你在项目里接到过“给这条语音处理链路打个分”的需求或者想量化某个编解码器把语音糟蹋成什么样、某次网络抖动对通话造成了多大损伤PESQ 大概率是你的第一选择。它是一套客观语音质量评估标准核心逻辑是把参考语音和经过系统处理后的输出语音做对比输出一个贴近人耳主观感受的 MOS 分值。VoIP 通话质量测试、编解码器选型、回声消除效果验证、网络损伤模拟这些场景里PESQ 几乎是行业默认的度量尺。这篇文章不准备把标准条款从头到尾念一遍我更想结合这几年在项目里实际跑 PESQ 的经验讲清楚它到底做了什么、跑测试有哪些坑、分数怎么读才不出错。无论你是刚接触音质评估的新人还是已经在用但经常被结果问号困扰的老手都可以拿这篇当一份实操备忘录。1. P.862在评估体系里的位置1.1 为什么需要客观评估主观MOS的痛语音质量最终极的评判标准是人耳也就是主观试听。行业内通用的做法是找一批听音员让他们对一段语音按 1 到 5 分打分最后算平均分这就是主观 MOSMean Opinion Score。问题是这套流程又贵又慢几十个听音员、专业听音室、严格的测试流程走下来一个版本要等好几周。而且主观分数天然带波动换个听音员、换个时间点结果可能差出 0.3 分这在版本迭代频繁的开发环境里根本没法用。所以行业里一直想要一把“尺子”用算法算出一个足够接近人耳主观判断的分数可以跑回归测试、可以横向对比不同算法、可以挂到自动化流水线里。早期的信噪比 SNR 做得太粗糙它逐点比较波形差异但人耳对失真的感知不是线性的很多在 SNR 里显得很大的误差人耳根本注意不到反过来很多 SNR 看不出差异的损伤人耳却能敏锐察觉。ITU-T 在 2001 年发布 P.862就是想把“人耳感知”这个事用数学模型复刻出来。我记得早期做回声消除AEC性能评估的时候领导直接给一句“这个版本音质有没有变差”没有 PESQ 这种客观工具的话我只能在开发机和测试机之间来回切 A/B 试听耳朵都快听麻了。后来上了 PESQ每次改动跑一遍拿分数说话效率完全不一样。1.2 PESQ的核心参考、退化、感知差异PESQ 的输入有两个信号一个是参考信号也就是原始干净语音另一个是退化信号也就是经过被测系统处理之后输出来的语音。它要做的事情就是比较这两个信号差异但要命的是这个差异不能直接在波形层面比得先映射到“人耳听感”层面再比。算法会模拟人耳的听觉处理过程包括频率到 Bark 域的映射、响度密度的计算、掩蔽效应的模拟等等把两个信号都转换到感知域然后计算它们之间的距离。距离小说明损伤很小距离大说明损伤明显。最终输出的结果是一个 raw 分范围大概在 -0.5 到 4.5 之间再经过映射变成大家习惯的 MOS-LQO 分值。整个过程说起来简单但内部实现相当复杂光是时间对齐、电平归一化、感知滤波这些预处理步骤就够写一大篇。它的核心价值在于不关心失真是什么形式只关心失真人耳能不能听出来、有多烦人。1.3 P.862家族版本与扩展P.862 不是一个孤立文本它配套了好几个文件和扩展很多人在项目里容易混。标准编号名称/内容适用场景ITU-T P.862核心算法 PESQ用于 8kHz 采样率的窄带语音传统电话、窄带 VoIP、G.711/G.729 编解码评估ITU-T P.862.1定义 raw 分到 MOS-LQO 的逻辑回归映射让结果更贴近主观 MOS需要输出“可直接对外沟通”的 MOS 分时ITU-T P.862.2宽带扩展支持 16kHz 采样率通常叫 PESQ-WB宽带语音、VoLTE、高清语音HD Voice场景ITU-T P.862.3应用指南给使用示例和约束条件决定测试方法和边界时有依据实际项目里我们一般直接说“跑一下 PESQ”但心里要清楚测的是哪个版本、用的是哪套参数。同一段语音窄带和宽带跑出来的分可能差很多对外汇报/对内回归要提前统一口径不然会闹笑话。2. PESQ评分逻辑从波形到感知距离的换算2.1 感知模型模拟人耳不是简单比对波形PESQ 最核心的设计思路是把“声音信号”变成“人耳听到的感觉”。人耳并不是均匀感知所有频率的对 1kHz 到 4kHz 的中频段最敏感对低频和高频迟钝得多。另外还有掩蔽效应一个强的声音会掩盖旁边弱的声音如果退化信号里混入的噪声恰好被原语音的强分量掩盖掉了人耳根本听不到那在感知域里这项差异就应该被忽略。PESQ 内部会做一组听觉变换先做短时傅里叶变换把声音拆解成时频表示再映射到 Bark 尺度然后计算每个频带的响度密度。这个过程相当于把声音“翻译”成人耳听神经收到的刺激强度模式。接着对参考信号和退化信号各自做这套变换再求差。因为是在感知域做差所以算出来的“距离”天然更接近人的主观感受。这也是为什么 PESQ 比 SNR 强得多。SNR 把静音区一个微弱的底噪算作很大的相对误差但人耳在别人说话的时候对这点底噪基本无感。PESQ 里这种失真会被掩蔽掉对最终分数影响很小这才符合“听起来怎么样”的真实体验。2.2 时间对齐最容易理解错的一环跑 PESQ 时最容易忽略但又影响巨大的环节是时间对齐。被测系统比如 VoIP 网关或网络模拟器会给信号带来延迟。你拿参考信号和经过系统出来的退化信号直接逐帧比较时间错位哪怕几十毫秒感知域里差异都会爆表出来的分数会离谱地低。PESQ 内部其实自带对齐机制它会对两个信号做包络分析和相关计算先粗对齐再精对齐尽量补偿固定时延。但要注意的是它补偿的是整体时延如果被测系统引入了时变时延也就是抖动尤其抖动幅度很大PESQ 的对齐能力就会捉襟见肘。实测下来规整的固定 100 毫秒时延PESQ 自己就能处理得很好但网络模拟器跑出忽大忽小的瞬时抖动分数通常会偏低而且这个偏低不完全代表听感变差更像是对齐阶段“报错”了。所以处理抖动比较大的信号时有两个选择一是在跑 PESQ 前手动做一次粗对齐把两个信号的大致起点拉齐二是改用专门处理时变时延的测试方案比如 POLQA 或者结合抖动缓冲机制再测。2.3 从扰动到MOS分P.862.1映射PESQ 内部算完感知域差异之后会生成一个 raw 分这个分数不太适合直接跟主观试听结果挂钩。ITU-T 后来发布 P.862.1定义了 raw 分到 MOS-LQO 的映射用的是一个逻辑回归函数呈 S 形曲线把分数压到跟主观 MOS 差不多可比的区间。映射之后4.5 分以上基本是透明传输人耳听不出和原始语音的区别4.0 到 4.5 之间属于质量良好可能只有轻微损伤3.0 到 3.5 就是能明显听出失真但仍可接受低于 2.5 基本属于通信质量崩了听感已经很难受了。这是我自己习惯的分段供参考具体阈值没有强制标准但大体趋势是公认的。有一点要提醒PESQ 分数区间上限是 4.5 左右不是 5.0。所以看到 4.5 不用怀疑是不是满分已经是这个尺子的天花板了。做横向对比时同样条件下不同版本的分数才更有意义别纠结绝对数值。3. 实操完整跑一次PESQ测试3.1 工具选型官方代码还是开源实现跑 PESQ 的工具来源主要有两个一是 ITU-T 官方发布的参考代码C 语言实现从 ITU 官网可以下载编译成可执行文件二是各种开源移植和封装比如 Python 的 pypesq、pesq 等库很多都是对官方 C 代码的编译封装接口更友好。如果是做一次性实验、验证概念直接用 Python 封装最省事。但如果是搭自动化回归测试平台需要长期稳定、结果可追溯我更倾向把官方 C 代码编译成命令行工具输入输出都是文件报错也好查。实测中有些开源封装对输入格式的严格程度不一样同一个 WAV 文件这个库能跑那个库可能因为头部信息不规范直接报错这种一致性问题在自动化流程里很头疼。官方参考代码的典型命令行用法是这样的# 窄带模式8000Hz采样率 ./pesq 8000 reference.wav degraded.wav # 宽带模式16000Hz采样率 ./pesq 16000 reference.wav degraded.wav运行结束结果会写在当前目录的 results.txt 里里面包含参考文件、退化文件、raw 分和映射后的 MOS-LQO 分。注意官方代码对文件名比较敏感路径里尽量别带空格和中文不然容易踩奇怪的坑。3.2 测试语音样本准备PESQ 是对语音设计的算法输入必须是语音内容拿纯音乐、纯噪声去跑出来的分数没有意义。测试语音一般选 8 到 15 秒的连续话语太短了统计样本不够分数波动大太长了计算时间变长且容易出现对齐偏移。内容上建议包含不同音节、有静音段落也有连续语音最好模拟真实通话场景。我常用的是 ITU-T P.50 人工嘴录音或者自录的清晰普通话但要保证内容是连续的语义流不是零散的词。采样率要和被测系统匹配窄带系统定 8k宽带系统定 16k。量化位数统一 16bit PCM这是最稳的组合。文件格式 WAV 优先虽然官方代码也支持 raw PCM但得自己保证格式参数别传错。准备参考信号和退化信号时有一条铁律两个信号必须同源只是其中一个经过被测系统处理。拿两段独立录音去跑 PESQ 没有任何意义那测的不是系统损伤是两个语音内容的天然差异。3.3 执行过程与结果解读我习惯的做法是先建立起一套标准的测试语音集固定几段内容录制参考信号后保存好。每次评估一个新系统把参考信号作为输入经过被测系统采集输出再把成对的参考/退化信号丢给 PESQ。比如评估一个语音编码器对音质的影响就直接拿参考语音经过编码器编解码输出接 PESQ评估网络对语音的影响就丢进网络损伤模拟器再采集。跑完会有两个数值需要注意raw 分和 MOS-LQO。平时我们说的是 MOS-LQO对外汇报也用这个raw 分更多是调试时看趋势用因为它的变化敏感度更高有些细小的损伤在映射后变化不明显但 raw 分能看出差异。对比两个版本时多看几个样本的平均分单条样本的随机波动很大最好凑 5 到 10 组语音取平均和标准差一起看。我在实际项目里习惯顺手做个表格把每个样本的 raw 分、映射分都记下来标出最高最低和平均。只报一个平均分其实信息量不够标准差大说明系统不稳定比如时延抖动起伏大或者某段语音被特殊处理过。4. 常见问题与排查技巧实录4.1 参考信号和退化信号不同源这个问题听起来低级但我真见过不止一次。有同事把 A 会议的参考录音和 B 会议的输出录音配对去测PESQ 直接给了 1 分左右他还以为是系统出了问题排查了半天。这类问题其实很好判断PESQ 分数如果低到离谱比如低于 1.5但主观听感并没有完全不可懂大概率是对齐或者同源出了问题。可以先用波形工具把两个文件的波形并排看一下如果语音包络位置都对不上赶紧换配对。还有一种情况是参考和退化信号采样率不同比如参考是 16k 采集的系统输出是 8k 的直接拿给 PESQ 跑会报错或分数失真。务必在进入测试前统一格式。4.2 时延和长度不一致PESQ 对信号长度有要求参考信号和退化信号的时长差异不能太大官方代码一般会截短到两个信号中较短的长度再处理。如果退化信号比参考信号长很多比如网络抖缓冲把音频尾部拉长了几百毫秒最终截断后的结果可能丢掉了部分真实内容分数偏差很大。我的处理办法是在采集退化信号后先做一次静音检测把前导静音和后置静音裁掉再跑 PESQ。这不仅是为了对齐也是为了让 PESQ 自己那套时间对齐发挥更好。信号内部如果有时变延迟比如网络模拟器导致的抖动可以在对比时用固定丢包/固定抖动配置尽量让延迟分布平稳这样 PESQ 的结果才稳定可解释。4.3 采样率、量化位数与文件头官方 C 代码对 WAV 头支持有点老派有些现代工具生成的 WAV 文件头比如带有额外 chunk 信息它不认会导致读文件失败或者采样数据错位。而且 PESQ 对量化位数有要求双声道、24bit、浮点 WAV 这些格式大多数封装不支持。最好在测试链路入口统一加一个音频格式转码步骤一律转成单声道、16bit PCM、WAV采样率按需求 8k 或 16k。看起来多了一步实际能省掉一堆莫名其妙的报错。我在自动化回归脚本里是这么写的ffmpeg -y -i input.wav -ac 1 -ar 16000 -sample_fmt s16 aligned.wav跑 PESQ 之前所有文件先过一遍这个命令格式问题基本绝迹。4.4 PESQ和主观听感对不上的典型场景任何客观模型都有盲区PESQ 也不例外。我遇到最明显的一个情况是某些语音增强算法在安静环境下做了很强的降噪PESQ 分数反而下降了但主观试听时大家觉得听起来更干净了。原因在于降噪算法对噪声的抑制被 PESQ 感知成了信号畸变而人耳对稳态底噪和轻微音乐噪声的容忍度比 PESQ 高。还有一个典型场景是参考信号本身包含一定环境噪声时PESQ 容易把噪声变化也算进失真里。如果你的测试系统是在真实环境录音而不是在理想安静环境使用 PESQ 前要先想清楚噪声要不要算作被测系统的损伤。如果系统本来就是降噪类算法建议结合主观试听和 PESQ 一起看不要只信分数。5. PESQ之后POLQA与评估方案的选型思考5.1 P.863POLQA改进了什么PESQ 发布之后通信技术演进很快从 3G 到 4G/5G从窄带到宽带再到超宽带PESQ 基于 8k 窄带设计的感知模型逐渐不够用了。ITU-T 在 2011 年发布 P.863也就是 POLQA支持从 8k 到 48kHz 采样率能覆盖超宽带语音处理时变延迟的能力也更强对现代编解码器的适应性更好。实际测评中POLQA 在宽带和超宽带的分数与主观感受的相关性确实比 PESQ 好尤其是处理 3GPP EVS、Opus 这类现代编码器时PESQ 的分数经常偏低或区分度不足。如果项目涉及到 VoLTE、高清语音、统一通信这类场景预算和时间允许的话直接上 POLQA 会更省心。5.2 还在用PESQ的场景但这不意味着 PESQ 该被丢掉。很多存量系统仍然是窄带语音比如传统电话网关、旧式 IVR 系统PESQ 对这些场景的适配非常成熟。而且 PESQ 计算量相对小、算法透明、参考代码稳定嵌入式设备或自动化测试环境里跑起来非常省事。一些监管合规或者客户合同里甚至明确指定要用 P.862 做验收这时候 POLQA 反而不合适。所以我的建议是按被测系统的采样率选型。8k 窄带系统的验收和回归测试用 PESQ 没问题16k 以上特别是超宽带系统有条件就上 POLQA。两种工具的结果不能直接换算对比换工具等于换尺子历史数据会断掉要提前评估。5.3 评估语音质量时我的一些习惯用 PESQ 这几年我养成了几个习惯分享给大家参考。第一每次评估先定好“尺子”再动手测试前确定是窄带还是宽带、用 raw 分还是 MOS-LQO 汇报全程保持一致。第二测试语音集固定且足够多样别每次开会临时换语音不然历史数据没法比较。第三PESQ 分数只作为筛选和回归手段最终上线前一定结合主观试听尤其是声音的“自然度”这种指标客观模型很难完全反映。最后再说一个小技巧当你拿 PESQ 做对比测试时尽量让两个版本在完全相同的条件下跑包括同一台机器、同一组语音、同一次采集环境。曾经我有一次对比两个降噪版本A 版本跑出来的分数比 B 高后来发现是 A 版本测试时网络模拟器没开抖动B 版本开了差异根本不是算法优劣纯粹是测试条件不一致。这类低级失误说多了都是泪但把流程规范化之后基本就能避免。本文还有配套的精品资源点击获取