简介：mos-pesq.zip是一份面向音频开发与语音质量评测人员的完整PESQ工具包，提供基于ITU-T P.862标准的感知语音质量评估实现。它通过命令行可对PCM音频文件进行MOS打分，适用于验证编解码算法对语音质量的影响，尤其适合在嵌入式或实时通信项目中快速定位音质损耗。包内共12个文件，以C语言源码为主：5个.c源文件实现核心算法与主程序，3个.h头文件定义接口，配合Makefile可一键编译生成可执行文件；另含shell测试脚本、README说明文档以及一个内含测试音频的zip数据包，整体约207KB，轻量易部署。目前已有963人学习过该资源。使用者能获得从源码编译到命令行运行的全套指引，通过对比原始语音与带噪语音的PESQ分值，可量化评估PCM编解码前后的语音质量，为音频链路质量的调优提供客观依据。1. 这个压缩包到底装了什么，为什么 MOS 评测都绕不开它做语音质量评测的人，电脑里几乎都会躺着一个叫mos-pesq.zip的压缩包。它可能来自同事的网盘分享，可能是某次项目交付的附件，也可能是你从某个技术论坛里捞到的资源。这个文件名指向一个明确的用途：用 PESQ 算法给语音质量打分，输出一个可量化的 MOS 值，用来判断你的编解码器、网络传输、降噪算法到底有没有把声音搞坏。很多人第一次拿到这个压缩包，解压之后对着里面的可执行文件、源码目录和一大堆.wav文件发懵，不知道先跑哪个命令、参数怎么填、结果怎么看。这篇笔记就沿着「是什么 → 怎么跑 → 参数怎么设 → 坑在哪 → 怎么批量用」这条线，把mos-pesq.zip里的东西讲透。无论你是做音频算法的开发者、通信设备的测试工程师，还是刚入门语音质量评测的学生，照着这篇文章能把一条 PESQ 评测流程从零跑通，并且能看懂每一个分数背后的意义。PESQ 本质上是 ITU-T P.862 标准定义的一种客观语音质量评估算法。它通过比较一个原始参考信号和一个经过传输链路后受损的退化信号，计算出一个分数，范围通常在 1.0 到 4.5 之间（理论极限是 -0.5 到 4.5，实际语音场景很少跌到 1.0 以下）。分数越接近 4.5，说明退化信号跟原始信号越接近，传输链路对语音的损伤越小。这个算法在 VoIP 音质评测、编解码器质量对比、降噪算法效果验证里是事实上的标配，所以mos-pesq.zip里装的无非是 PESQ 算法的现成实现，外加配套的脚本和样例文件。接下来我们把它的结构、原理和用法一层层拆开。2. 从 MOS 到 PESQ：先搞懂分数是怎么算出来的2.1 MOS 的主观出身与客观替代MOS（Mean Opinion Score，平均意见分）最初是个纯粹的主观指标。评测机构找一批听音人，让他们听一段经过被测系统的语音，然后按 1 到 5 分打分：5 分是“完美，听不出任何损伤”，4 分是“能察觉损伤但不影响理解”，3 分是“有明显损伤，需要集中注意力才能听懂”，2 分是“几乎听不懂”，1 分是“完全不可用”。把所有听音人的打分取平均，就是这段语音的 MOS 分。主观评测的问题显而易见：费时费力费钱，而且结果不可复现。今天找 A 组人打分和明天找 B 组人打分，结果可能差出 0.5 分，同一组人换个环境重听一遍也会波动。工程上需要的是一个确定性的、可自动化的替代指标，于是 PESQ 这类客观评估算法应运而生。PESQ 的思想是：既然人耳对语音的感知可以通过心理声学模型近似模拟，那就把参考信号和退化信号都映射到一个“内部表示”空间，在这个空间里计算两者的差异，再映射回 MOS 尺度。理解这一点很重要，因为 PESQ 输出的分数虽然有 MOS 之名，但它更适合叫 MOS-LQO（Listening Quality Objective，客观听音质量分）。它不是真的找了一群人来打分，而是用一个数学模型去“猜”这些人会打多少分。在实际使用中，PESQ 分数和主观 MOS 分大体趋势一致，但在边缘场景（极端丢包、强背景噪声、非线性失真）下会有偏差，这一点在后面讲避坑时要反复提到。2.2 PESQ 的核心计算流程：时频映射与扰动密度PESQ 的计算流程可以拆成几个阶段，理解它有助于你判断“这个分数可不可信”以及“分数异常时问题出在哪”。电平对齐与时间对齐：PESQ 第一步会对参考信号和退化信号做增益补偿，消除音量差异带来的影响。同时它会用互相关方法估算两个信号之间的时延，把退化信号的时间轴对齐到参考信号上。这一步非常关键，因为如果信号没对齐，后面算出来的差异会非常大，分数会极其难看。听觉变换：把对齐后的两个信号分别通过一个模拟人耳频率响应的滤波器组，转换到 Bark 域（一种模仿人耳听觉特性的频率尺度）。每个频带上的信号再经过响度变换，映射成“响度谱”。这个响度谱模拟的是人耳对各个频率成分的感知强度，单位是 sone。扰动密度计算：在响度谱上逐帧计算参考信号和退化信号的差异，得到扰动密度（disturbance density）。扰动密度分为正值（退化信号比参考信号能量大，比如新增了噪声）和负值（退化信号比参考信号能量小，比如丢帧导致语音缺失）。PESQ 会对正负扰动分别做不对称处理，因为人耳对不同类型损伤的敏感度不一样——对新增噪声的容忍度比对丢帧的容忍度略高。聚合映射：把所有帧的扰动密度聚合，先按频带和帧做时间-频率平均，再映射到 PESQ 得分（原始分），最后通过一个逻辑函数转换成 MOS-LQO 分数。这个流程决定了 PESQ 的一个本质特性：它是一个全参考（full-reference）算法，必须同时有原始参考音频和退化音频才能评测。如果你的场景里拿不到干净参考信号（比如实时网络流里的任意一段语音），PESQ 就不适用，需要换无参考（non-intrusive）算法，这是后话。2.3mos-pesq.zip里可能装了什么：代码、二进制、脚本与样例虽然不同渠道拿到的mos-pesq.zip内容细节会不一样，但常见的包内结构有很强的规律性。解压之后你应该先看一下根目录，确认里面有没有可执行文件（Linux 下通常叫pesq或pesq.exe，Windows 下可能带.exe后缀），有没有src源码目录，有没有Makefile或编译脚本，有没有存着.wav样例文件的audio或samples目录，以及有没有说明文档（README、doc目录）。包内结构不固定，取决于打包的人用的是哪个版本、什么平台：有的包只放编译好的可执行文件加几个样例音频，有的包把完整源码也塞进去了，方便你在目标平台上重新编译。我这里说一句经验之谈：拿到压缩包先别急着跑，先把包内文件列一遍。用unzip -l mos-pesq.zip就能在不解压的情况下看清单，判断里面是二进制发行包还是源码包。如果看到Makefile和一堆.c/.m文件，说明你要走编译这条路；如果看到现成的pesq可执行文件，那就直接授权加运行，能省不少事。3. 用 mos-pesq.zip 在本地跑通一条最小评测流程3.1 解压与文件清单核对拿到mos-pesq.zip，第一步自然是解压。假设你把它放在了~/mos目录下，在 Linux 环境里执行：mkdir -p ~/mos && cd ~/mos unzip mos-pesq.zip -d mos-pesq cd mos-pesq ls -la命令解释：unzip mos-pesq.zip -d mos-pesq解压到mos-pesq目录里，不直接解压到当前目录是为了避免压缩包内部文件结构凌乱时污染现有目录。ls -la看全部文件，包括隐藏文件和权限位。如果ls列出的文件里有一个绿色（可执行）的pesq，说明包里带现成二进制；如果只看到.c、.h、Makefile，你就需要编译。参数说明：-d指定解压目标目录，目录不存在时会自动创建；ls -la里的-a显示隐藏文件，-l查看权限和大小。这步的核心目的是确认你到底拿到的是哪种包，决定后续流程。3.2 Linux 下现成二进制直接跑：第一条命令与第一个分数如果解压后有可执行的pesq文件，在终端里先给它加执行权限，然后看一眼它的帮助信息：chmod +x pesq ./pesq命令解释：chmod +x pesq给pesq添加执行权限，因为通过unzip解压出来的文件通常不带可执行位。如果包里的二进制是在别的 Linux 发行版上编译的，还可能遇到动态链接库不匹配的问题，这时直接运行./pesq会报error while loading shared libraries，后面讲排毒时会处理。运行之后通常会打印一段帮助文字，告诉你用法。不同版本的 PESQ 程序用法略有差异，但主流形式有两种：# 形式一：参数带采样率 ./pesq +8000 ref.wav deg.wav # 形式二：不指定采样率，自动识别 ./pesq ref.wav deg.wav这里+8000表示窄带 8kHz 采样率。为什么采样率这个参数这么重要？因为 PESQ 的算法模型是按两个采样率体系设计的：8kHz 对应窄带语音（频率范围 300-3400Hz，就是传统电话线路的带宽），16kHz 对应宽带语音（频率到 7kHz，对应现代 VoIP 和高清语音）。选错采样率不会报错，但分数会失真，因为算法内部滤波器的频率响应是按目标采样率设计的。执行后会看到类似这样的输出：PESQ Score (MOS-LQO) : 3.214 Raw MOS : 3.412第一行是最终分数，第二行是中间计算值。发布评测报告、对比算法性能时，看 MOS-LQO，不看 Raw MOS。3.3 源码包编译：Makefile 与依赖检查如果mos-pesq.zip里装的是源码，那就需要先编译。PESQ 官方参考实现是用 C 语言写的，标准情况下只需要一个 C 编译器和 make 工具，不需要第三方库。编译步骤通常非常简单：cd ~/mos/mos-pesq make如果make成功，会在当前目录生成pesq可执行文件。如果失败，最常见的报错是gcc: command not found，说明系统没装编译器。Debian/Ubuntu 系列执行sudo apt-get install build-essential，CentOS/RHEL 系列执行sudo yum install gcc make。装完再跑make。make的细节：它会读取Makefile里的规则，调用gcc编译源码目录下的多个.c文件，生成目标文件后再链接成pesq。你不需要理解每一个编译选项，只需要知道如果编译过程中出现error:开头的行，基本都是源码本身对环境的要求没满足，或者编译器版本太旧。这个项目年代比较早，有些代码拿到新的 GCC 环境会遇到隐式声明之类的编译告警，甚至有报错。我的建议：编译报错先查是不是-lm没链接（数学库），在 Makefile 的链接行末尾加上-lm再试，这是老 C 项目最常见的编译翻车点。3.4 准备一对测试音频：参考与退化跑第一条 PESQ 命令之前，需要一对文件：一个是干净参考信号，一个是待测退化信号。样例目录里通常自带一对示例，你可以先跑样例熟悉流程。假如样例文件不完整或者你想用自己的音频，记住三个硬性要求：WAV 格式、PCM 编码、位深 16bit 或 32bit。PESQ 参考实现对输入格式有限制，不是任何 WAV 都能跑。如果是 8kHz 窄带评测，音频必须是 8kHz 采样率、16bit 线性 PCM 的单声道 WAV；如果是 16kHz 宽带评测，音频必须是 16kHz 采样率、16bit 线性 PCM。用 ffmpeg 转换的时候，命令如下：ffmpeg -i input.mp3 -ar 8000 -ac 1 -sample_fmt s16 ref.wav ffmpeg -i degraded.mp3 -ar 8000 -ac 1 -sample_fmt s16 deg.wav命令解释：-ar 8000重采样到 8kHz，-ac 1转成单声道，-sample_fmt s16强制输出 16bit 有符号整数 PCM。为什么强制这些参数？因为 PESQ 对波形做逐样本对比，输入格式不统一会造成程序拒绝处理或静默跑出错误结果。关于参考信号和退化信号的对应关系，在生成退化信号之前就要想清楚：参考信号是“端到端链路输入”，退化信号是“你从链路另一头采集到的输出”。如果你在做编解码器评测，参考信号是编码器输入的原始音频，退化信号是解码器输出的音频；如果你在做网络丢包模拟评测，参考信号是发送端的原始音频，退化信号是丢包补偿后的接收端音频。两者的内容必须同源同内容，只是经过了被测系统的处理，时延和损伤是允许存在的。跑完第一条命令后，你还要知道一个关键点：PESQ 参考实现处理音频文件时对时长有内部限制。一般 8 到 20 秒的语音片段是最稳的，太短（少于 3 秒）会导致统计意义不足，分数忽高忽低；太长（超过 60 秒）可能导致程序内部内存溢出或处理时间过长，某些老实现甚至会直接崩溃。所以做评测前把音频截取成 10 秒左右的片段是标准操作。4. 参数与边界：采样率、响度、时长与分数解读4.1 采样率参数是整个评测流程最容易被忽略的玄学PESQ 有两种运行模式，按采样率区分，这个参数直接影响算法内部的滤波器组设计和扰动计算方式。如果你用的是+8000参数，程序会把输入音频按 8kHz 处理，但不会做重采样——它默认你的音频就是 8kHz，输入 16kHz 的音频不会自动降采样，而是当成 8kHz 音频直接解析，后果是频谱上原本 4-7kHz 的能量被错误映射，分数失真。目前主流的mos-pesq包已经能做到pesq ref.wav deg.wav这种不指定采样率的用法，程序会读取 WAV 头里的采样率字段自行决定模式。但老版本的程序必须手动指定模式。怎么判断你手里的包支持哪种用法？解压后直接不带参数运行./pesq，看帮助文本：usage: pesq +8000 ref deg说明要手填模式；usage: pesq ref deg说明自动识别。16kHz 宽带的评测，程序参数在某些版本里写作+16000。这里有一个从业者们常踩的坑：8kHz 模式下给 16kHz 音频，或者 16kHz 模式下给 8kHz 音频，程序不报错，分数看起来也正常，但和主观听感差得很远。这属于那种“错得很安静”的故障，比报错更危险。4.2 输入文件格式约束：位深、编码、头信息PESQ 对输入 WAV 文件的要求可以列成一张表，建议贴在工位旁边对照：项目窄带模式宽带模式采样率8000 Hz16000 Hz位深16 bit PCM16 bit PCM声道数单声道（1 ch）单声道（1 ch）编码PCM（无压缩）PCM（无压缩）文件头WAV / WaveWAV / Wave不符合要求的文件在运行时会出现两种典型表现：一种是程序直接报Unsupported format或Error: unknown format，告诉你文件头解析不了；另一种是程序正常执行、正常输出分数，但分数意义不明——比如你把一个 48kHz 的音频喂进去，程序只读取前 8k 个采样点对应的秒数，导致实际评测的只是音频的一小段，分数完全没代表性。处理非标准文件的方法比较固定：通过 ffmpeg 或 sox 统一转格式。前面已经给了 ffmpeg 的转换命令，思路是重采样、转单声道、指定位深，一气呵成。日常评测流程里我习惯先做一个preprocess.sh脚本，把所有待测音频统一转成程序要求的格式，再进入评测环节，避免手动转换漏掉某些文件。4.3 读对、读懂分数：MOS-LQO 与置信区间PESQ 程序输出的 MOS-LQO 是一个点估计值，它没有给你置信区间。实际工作中同一个退化音频你可能要评测多次，用不同参考片段，或多次重放采集退化信号，最后看到的分数是一个分布。我一般会跑至少 3 到 5 个不同的语音片段（比如男女声各两段，内容不同），把 MOS-LQO 分数取平均，才作为这一组对比条件的最终结果。分数解读还要结合具体场景。做编解码器对比时，MOS-LQO 在 4.0 以上算良好，3.5 到 4.0 是普通，3.5 以下用户容易感知到明显音质损伤。但这是经验值，不同测试语音集的结果不能直接比较——这就是为什么 PESQ 评测报告里必须写清楚用了哪些测试音频、什么采样率、什么对比条件。同一套算法在用男声朗读新闻的片段里得 4.2，在吵闹背景下的女声片段里得 3.1，两个分数离散度很大，只报一个平均值反而掩盖了问题。5. 避坑与排查：PESQ 评测里最常见的 4 个翻车现场5.1 分数高得离谱（4.3 以上），但听感明显有问题现象：退化信号里明明有可感知的底噪或失真，人耳打分大概 3 分左右，PESQ 却给出 4.3 以上。原因：最常见的是参考信号和退化信号没对齐好，程序自动对齐功能失效后，把信号里的某一段和参考信号的另一段匹配上了。还有一种可能：你拿错了参考信号，退化信号的波形既然和参考信号同源，程序算不出差异，分数自然虚高。第三种可能：参考信号本身已经带了损伤，程序对比的是“退化信号”和“本来就有点脏的参考”，两者差异小，分高。解决：停下手里的活，先检查测试音频的原始素材。用 Audacity 或 Python 脚本把参考信号和退化信号的波形叠在一起看，确认内容对齐、幅度近似。同时确认参考信号是链路输入端的干净原始信号，不是从链路中间某个节点偷录的二次信号。5.2 采样率不符，程序直接退出现象：运行./pesq +8000 ref.wav deg.wav时程序报Error: sample frequency is not matching，或者更隐晦的File has not the expected format。原因：mos-pesq里的程序实现往往同时支持 8kHz 和 16kHz 两套内部模型，但它在处理之前会检查 WAV 文件头里的采样率字段。如果你指定+8000，而 WAV 文件里写的是 16000，程序判断模式与文件不一致，直接拒绝执行。解决：确认评测目标：窄带评测就统一把音频转成 8000 Hz，宽带评测就转成 16000 Hz。用 ffmpeg 批量转换后再执行。不要试图用+8000去评测一个 16kHz 的音频文件，那没有任何意义。5.3 程序正常跑完，但一段音频的分数比另一段低了 1.5 分以上现象：同一个退化信号，用不同参考片段评测，分数离散度极大。原因：某一段参考片段的起始位置和退化信号有几百毫秒的静音前缀，PESQ 做时间对齐时把这部分静音当成了时延的一部分，对齐偏差拉到 300-500ms 后，语音内容根本对不上，出了个极低分。还有一个常见原因是片段内容本身太短，评测窗口不足半秒有效语音，扰动统计没有意义。解决：处理音频时统一做首尾静音切除，保证参考和退化信号从第一个有效语音帧开始，内容完全一一对应。如果需要在长录音中截取片段，保持参考和退化信号的截取起始点一致。做完静音处理后重新跑一遍，看分数是否回到合理区间。5.4 波形幅度差异大，分数不合格现象：退化信号听起来只是比参考信号音量大了一些，或者音量小了一些，PESQ 分数掉到 2 分以下。原因：PESQ 的电平对齐模块会尝试做增益补偿，但这个能力是有限度的。如果链路里增益差超过约 30dB，或者出现了削波失真（数字削波会产生大量非线性谐波），对齐失效，分数被严重拉低。人耳对纯音量大小变化不敏感，但 PESQ 对幅度异常会很敏感。解决：评测流程里加一个响度归一化步骤，用ffmpeg loudnorm或先测有效值再统一乘一个增益系数，把参考信号和退化信号的平均响度对齐到大致相同的水平。注意不要对退化信号做任何动态范围压缩，那会改变它本身的损伤特征，评测结果就不再反映真实链路了。这里我个人的习惯是退化信号只做幅度缩放，不做 EQ 和动态处理。5.5 多平台移植：Windows 与 Linux 的路径与换行符坑现象：在 Windows 上解压mos-pesq.zip，双击想运行的.exe有执行权限，但运行时报缺少某个.dll或直接闪退；而在 Linux 上解压，脚本里的换行符变成了\r，导致$'\r': command not found。原因：mos-pesq.zip里的可执行文件是针对特定平台编译的，Windows 和 Linux 的二进制不通用。配套的.sh脚本或Makefile如果在 Windows 下用记事本编辑过再传回 Linux，行尾的 CRLF 会让 bash 和 make 解析出错。解决：Windows 上先看包里有没有.exe或.bat文件，没有就说明这个包只支持 Linux，需要换成对应平台版本；Linux 上如果出现command not found但文件名明明存在，先执行sed -i 's/\r$//' 脚本名.sh去掉 CRLF 再跑。这里多说一句，这只是文本编码层面的问题，和任何网络连接工具无关，属于纯粹的文件格式兼容问题。6. 批量评测与回归门禁：把一条命令变成一套自动化流程单条./pesq跑通只是起点，实际工程里的需求永远是批量：你要评测 10 组编解码器参数、20 条网络损伤条件、5 种降噪算法，每组条件对应几十个语音片段。手动一条条跑不现实，也违背了 PESQ 的自动化初衷。我一般会把它组织成一个带目录参数和结果归档脚本的批处理流程。下面给你一个可以直接抄走的 Python 脚本框架：import os import subprocess import csv ref_dir = "refs" # 参考信号目录 deg_dir = "degs" # 退化信号目录，子目录名代表测试条件 output_csv = "pesq_results.csv" pesq_bin = "./pesq" conditions = [d for d in os.listdir(deg_dir) if os.path.isdir(os.path.join(deg_dir, d))] with open(output_csv, "w", newline="") as f: writer = csv.writer(f) writer.writerow(["condition", "ref_file", "deg_file", "mos_lqo"]) for cond in conditions: deg_files = [f for f in os.listdir(os.path.join(deg_dir, cond)) if f.endswith(".wav")] for deg_file in sorted(deg_files): ref_file = deg_file # 假设参考文件和退化文件同文件名 ref_path = os.path.join(ref_dir, ref_file) deg_path = os.path.join(deg_dir, cond, deg_file) if not os.path.exists(ref_path): print(f"[跳过] 缺少参考文件: {ref_file}") continue result = subprocess.run([pesq_bin, "+8000", ref_path, deg_path], capture_output=True, text=True) # 从输出中解析 MOS-LQO 分数 for line in result.stdout.splitlines(): if "MOS-LQO" in line: score = line.split(":")[-1].strip() writer.writerow([cond, ref_file, deg_file, score]) print(f"{cond} / {deg_file} -> {score}")脚本逻辑说明：先遍历degs目录下的所有子目录，每个子目录名代表一种测试条件（比如codec_a_24kbps、loss_5%），对这个子目录里的每一个 WAV 文件，在refs目录下找同名参考文件，构造命令行调用pesq，解析输出里的MOS-LQO分数，写进 CSV。用subprocess.run而不是os.system是为了能稳定捕获命令输出，解析分数时有更好的容错性。参数说明：deg_dir下的子目录结构是这个脚本约定的，参考文件名和退化文件名必须一致，因为脚本用同一个文件名去两处找文件。如果你的文件命名习惯不同，可以改成遍历时记录下标或者读取一个映射表，核心逻辑不变。capture_output=True会把程序的标准输出捕获到内存里，我们在里面搜MOS-LQO这一行取分数。程序出错了怎么办？cust输出为空，脚本不会崩，CSV 里这一行不会写，后续检查 CSV 时哪些条件缺行就一目了然。这种设计比中途抛异常更符合批量评测的容错需求。有了这个脚本，评测结果就变成一张 CSV 表。我习惯在表上加一个汇总步骤：每个条件取所有片段分数的平均值和标准差，平均值横向对比不同条件的音质差距，标准差反映分数稳定性。这并不是算完就完——把结果贴到一个简单的对比表里，做算法调优和回归验证时能一眼看出哪个改动是有效的，哪个改动只是玄学波动。我现在做编解码器优化时，会把每次改动后的评测 CSV 归档成带时间戳的文件，防止“这次结果比上次高 0.2 分”这种结论没有可追溯的数据支撑。说一个我自己的教训：早期做评测时偷懒只跑一个 8 秒片段就得结论，某次调整算法参数后，这一个片段的分数提高到 4.2，我就以为改动有效，结果换了一个片段重测，分数反而跌了 0.3。从那以后我再也不敢拿单个片段的分说事了，批处理脚本和至少 5 个片段的平均值成了我的习惯底线。PESQ 是一个稳定的算法，但语音内容本身是多变的，评测流程的稳定性比单次分数的变化更能说明问题。希望这篇从解压到批处理的笔记能帮到你，让你手里的mos-pesq.zip真正成为评测流程里可信赖的标尺，而不是一个跑完就忘的黑匣子。本文还有配套的精品资源，点击获取
简介：mos-pesq.zip是一份面向音频开发与语音质量评测人员的完整PESQ工具包，提供基于ITU-T P.862标准的感知语音质量评估实现。它通过命令行可对PCM音频文件进行MOS打分，适用于验证编解码算法对语音质量的影响，尤其适合在嵌入式或实时通信项目中快速定位音质损耗。包内共12个文件，以C语言源码为主：5个.c源文件实现核心算法与主程序，3个.h头文件定义接口，配合Makefile可一键编译生成可执行文件；另含shell测试脚本、README说明文档以及一个内含测试音频的zip数据包，整体约207KB，轻量易部署。目前已有963人学习过该资源。使用者能获得从源码编译到命令行运行的全套指引，通过对比原始语音与带噪语音的PESQ分值，可量化评估PCM编解码前后的语音质量，为音频链路质量的调优提供客观依据。1. 这个压缩包到底装了什么，为什么 MOS 评测都绕不开它做语音质量评测的人，电脑里几乎都会躺着一个叫mos-pesq.zip的压缩包。它可能来自同事的网盘分享，可能是某次项目交付的附件，也可能是你从某个技术论坛里捞到的资源。这个文件名指向一个明确的用途：用 PESQ 算法给语音质量打分，输出一个可量化的 MOS 值，用来判断你的编解码器、网络传输、降噪算法到底有没有把声音搞坏。很多人第一次拿到这个压缩包，解压之后对着里面的可执行文件、源码目录和一大堆.wav文件发懵，不知道先跑哪个命令、参数怎么填、结果怎么看。这篇笔记就沿着「是什么 → 怎么跑 → 参数怎么设 → 坑在哪 → 怎么批量用」这条线，把mos-pesq.zip里的东西讲透。无论你是做音频算法的开发者、通信设备的测试工程师，还是刚入门语音质量评测的学生，照着这篇文章能把一条 PESQ 评测流程从零跑通，并且能看懂每一个分数背后的意义。PESQ 本质上是 ITU-T P.862 标准定义的一种客观语音质量评估算法。它通过比较一个原始参考信号和一个经过传输链路后受损的退化信号，计算出一个分数，范围通常在 1.0 到 4.5 之间（理论极限是 -0.5 到 4.5，实际语音场景很少跌到 1.0 以下）。分数越接近 4.5，说明退化信号跟原始信号越接近，传输链路对语音的损伤越小。这个算法在 VoIP 音质评测、编解码器质量对比、降噪算法效果验证里是事实上的标配，所以mos-pesq.zip里装的无非是 PESQ 算法的现成实现，外加配套的脚本和样例文件。接下来我们把它的结构、原理和用法一层层拆开。2. 从 MOS 到 PESQ：先搞懂分数是怎么算出来的2.1 MOS 的主观出身与客观替代MOS（Mean Opinion Score，平均意见分）最初是个纯粹的主观指标。评测机构找一批听音人，让他们听一段经过被测系统的语音，然后按 1 到 5 分打分：5 分是“完美，听不出任何损伤”，4 分是“能察觉损伤但不影响理解”，3 分是“有明显损伤，需要集中注意力才能听懂”，2 分是“几乎听不懂”，1 分是“完全不可用”。把所有听音人的打分取平均，就是这段语音的 MOS 分。主观评测的问题显而易见：费时费力费钱，而且结果不可复现。今天找 A 组人打分和明天找 B 组人打分，结果可能差出 0.5 分，同一组人换个环境重听一遍也会波动。工程上需要的是一个确定性的、可自动化的替代指标，于是 PESQ 这类客观评估算法应运而生。PESQ 的思想是：既然人耳对语音的感知可以通过心理声学模型近似模拟，那就把参考信号和退化信号都映射到一个“内部表示”空间，在这个空间里计算两者的差异，再映射回 MOS 尺度。理解这一点很重要，因为 PESQ 输出的分数虽然有 MOS 之名，但它更适合叫 MOS-LQO（Listening Quality Objective，客观听音质量分）。它不是真的找了一群人来打分，而是用一个数学模型去“猜”这些人会打多少分。在实际使用中，PESQ 分数和主观 MOS 分大体趋势一致，但在边缘场景（极端丢包、强背景噪声、非线性失真）下会有偏差，这一点在后面讲避坑时要反复提到。2.2 PESQ 的核心计算流程：时频映射与扰动密度PESQ 的计算流程可以拆成几个阶段，理解它有助于你判断“这个分数可不可信”以及“分数异常时问题出在哪”。电平对齐与时间对齐：PESQ 第一步会对参考信号和退化信号做增益补偿，消除音量差异带来的影响。同时它会用互相关方法估算两个信号之间的时延，把退化信号的时间轴对齐到参考信号上。这一步非常关键，因为如果信号没对齐，后面算出来的差异会非常大，分数会极其难看。听觉变换：把对齐后的两个信号分别通过一个模拟人耳频率响应的滤波器组，转换到 Bark 域（一种模仿人耳听觉特性的频率尺度）。每个频带上的信号再经过响度变换，映射成“响度谱”。这个响度谱模拟的是人耳对各个频率成分的感知强度，单位是 sone。扰动密度计算：在响度谱上逐帧计算参考信号和退化信号的差异，得到扰动密度（disturbance density）。扰动密度分为正值（退化信号比参考信号能量大，比如新增了噪声）和负值（退化信号比参考信号能量小，比如丢帧导致语音缺失）。PESQ 会对正负扰动分别做不对称处理，因为人耳对不同类型损伤的敏感度不一样——对新增噪声的容忍度比对丢帧的容忍度略高。聚合映射：把所有帧的扰动密度聚合，先按频带和帧做时间-频率平均，再映射到 PESQ 得分（原始分），最后通过一个逻辑函数转换成 MOS-LQO 分数。这个流程决定了 PESQ 的一个本质特性：它是一个全参考（full-reference）算法，必须同时有原始参考音频和退化音频才能评测。如果你的场景里拿不到干净参考信号（比如实时网络流里的任意一段语音），PESQ 就不适用，需要换无参考（non-intrusive）算法，这是后话。2.3mos-pesq.zip里可能装了什么：代码、二进制、脚本与样例虽然不同渠道拿到的mos-pesq.zip内容细节会不一样，但常见的包内结构有很强的规律性。解压之后你应该先看一下根目录，确认里面有没有可执行文件（Linux 下通常叫pesq或pesq.exe，Windows 下可能带.exe后缀），有没有src源码目录，有没有Makefile或编译脚本，有没有存着.wav样例文件的audio或samples目录，以及有没有说明文档（README、doc目录）。包内结构不固定，取决于打包的人用的是哪个版本、什么平台：有的包只放编译好的可执行文件加几个样例音频，有的包把完整源码也塞进去了，方便你在目标平台上重新编译。我这里说一句经验之谈：拿到压缩包先别急着跑，先把包内文件列一遍。用unzip -l mos-pesq.zip就能在不解压的情况下看清单，判断里面是二进制发行包还是源码包。如果看到Makefile和一堆.c/.m文件，说明你要走编译这条路；如果看到现成的pesq可执行文件，那就直接授权加运行，能省不少事。3. 用 mos-pesq.zip 在本地跑通一条最小评测流程3.1 解压与文件清单核对拿到mos-pesq.zip，第一步自然是解压。假设你把它放在了~/mos目录下，在 Linux 环境里执行：mkdir -p ~/mos && cd ~/mos unzip mos-pesq.zip -d mos-pesq cd mos-pesq ls -la命令解释：unzip mos-pesq.zip -d mos-pesq解压到mos-pesq目录里，不直接解压到当前目录是为了避免压缩包内部文件结构凌乱时污染现有目录。ls -la看全部文件，包括隐藏文件和权限位。如果ls列出的文件里有一个绿色（可执行）的pesq，说明包里带现成二进制；如果只看到.c、.h、Makefile，你就需要编译。参数说明：-d指定解压目标目录，目录不存在时会自动创建；ls -la里的-a显示隐藏文件，-l查看权限和大小。这步的核心目的是确认你到底拿到的是哪种包，决定后续流程。3.2 Linux 下现成二进制直接跑：第一条命令与第一个分数如果解压后有可执行的pesq文件，在终端里先给它加执行权限，然后看一眼它的帮助信息：chmod +x pesq ./pesq命令解释：chmod +x pesq给pesq添加执行权限，因为通过unzip解压出来的文件通常不带可执行位。如果包里的二进制是在别的 Linux 发行版上编译的，还可能遇到动态链接库不匹配的问题，这时直接运行./pesq会报error while loading shared libraries，后面讲排毒时会处理。运行之后通常会打印一段帮助文字，告诉你用法。不同版本的 PESQ 程序用法略有差异，但主流形式有两种：# 形式一：参数带采样率 ./pesq +8000 ref.wav deg.wav # 形式二：不指定采样率，自动识别 ./pesq ref.wav deg.wav这里+8000表示窄带 8kHz 采样率。为什么采样率这个参数这么重要？因为 PESQ 的算法模型是按两个采样率体系设计的：8kHz 对应窄带语音（频率范围 300-3400Hz，就是传统电话线路的带宽），16kHz 对应宽带语音（频率到 7kHz，对应现代 VoIP 和高清语音）。选错采样率不会报错，但分数会失真，因为算法内部滤波器的频率响应是按目标采样率设计的。执行后会看到类似这样的输出：PESQ Score (MOS-LQO) : 3.214 Raw MOS : 3.412第一行是最终分数，第二行是中间计算值。发布评测报告、对比算法性能时，看 MOS-LQO，不看 Raw MOS。3.3 源码包编译：Makefile 与依赖检查如果mos-pesq.zip里装的是源码，那就需要先编译。PESQ 官方参考实现是用 C 语言写的，标准情况下只需要一个 C 编译器和 make 工具，不需要第三方库。编译步骤通常非常简单：cd ~/mos/mos-pesq make如果make成功，会在当前目录生成pesq可执行文件。如果失败，最常见的报错是gcc: command not found，说明系统没装编译器。Debian/Ubuntu 系列执行sudo apt-get install build-essential，CentOS/RHEL 系列执行sudo yum install gcc make。装完再跑make。make的细节：它会读取Makefile里的规则，调用gcc编译源码目录下的多个.c文件，生成目标文件后再链接成pesq。你不需要理解每一个编译选项，只需要知道如果编译过程中出现error:开头的行，基本都是源码本身对环境的要求没满足，或者编译器版本太旧。这个项目年代比较早，有些代码拿到新的 GCC 环境会遇到隐式声明之类的编译告警，甚至有报错。我的建议：编译报错先查是不是-lm没链接（数学库），在 Makefile 的链接行末尾加上-lm再试，这是老 C 项目最常见的编译翻车点。3.4 准备一对测试音频：参考与退化跑第一条 PESQ 命令之前，需要一对文件：一个是干净参考信号，一个是待测退化信号。样例目录里通常自带一对示例，你可以先跑样例熟悉流程。假如样例文件不完整或者你想用自己的音频，记住三个硬性要求：WAV 格式、PCM 编码、位深 16bit 或 32bit。PESQ 参考实现对输入格式有限制，不是任何 WAV 都能跑。如果是 8kHz 窄带评测，音频必须是 8kHz 采样率、16bit 线性 PCM 的单声道 WAV；如果是 16kHz 宽带评测，音频必须是 16kHz 采样率、16bit 线性 PCM。用 ffmpeg 转换的时候，命令如下：ffmpeg -i input.mp3 -ar 8000 -ac 1 -sample_fmt s16 ref.wav ffmpeg -i degraded.mp3 -ar 8000 -ac 1 -sample_fmt s16 deg.wav命令解释：-ar 8000重采样到 8kHz，-ac 1转成单声道，-sample_fmt s16强制输出 16bit 有符号整数 PCM。为什么强制这些参数？因为 PESQ 对波形做逐样本对比，输入格式不统一会造成程序拒绝处理或静默跑出错误结果。关于参考信号和退化信号的对应关系，在生成退化信号之前就要想清楚：参考信号是“端到端链路输入”，退化信号是“你从链路另一头采集到的输出”。如果你在做编解码器评测，参考信号是编码器输入的原始音频，退化信号是解码器输出的音频；如果你在做网络丢包模拟评测，参考信号是发送端的原始音频，退化信号是丢包补偿后的接收端音频。两者的内容必须同源同内容，只是经过了被测系统的处理，时延和损伤是允许存在的。跑完第一条命令后，你还要知道一个关键点：PESQ 参考实现处理音频文件时对时长有内部限制。一般 8 到 20 秒的语音片段是最稳的，太短（少于 3 秒）会导致统计意义不足，分数忽高忽低；太长（超过 60 秒）可能导致程序内部内存溢出或处理时间过长，某些老实现甚至会直接崩溃。所以做评测前把音频截取成 10 秒左右的片段是标准操作。4. 参数与边界：采样率、响度、时长与分数解读4.1 采样率参数是整个评测流程最容易被忽略的玄学PESQ 有两种运行模式，按采样率区分，这个参数直接影响算法内部的滤波器组设计和扰动计算方式。如果你用的是+8000参数，程序会把输入音频按 8kHz 处理，但不会做重采样——它默认你的音频就是 8kHz，输入 16kHz 的音频不会自动降采样，而是当成 8kHz 音频直接解析，后果是频谱上原本 4-7kHz 的能量被错误映射，分数失真。目前主流的mos-pesq包已经能做到pesq ref.wav deg.wav这种不指定采样率的用法，程序会读取 WAV 头里的采样率字段自行决定模式。但老版本的程序必须手动指定模式。怎么判断你手里的包支持哪种用法？解压后直接不带参数运行./pesq，看帮助文本：usage: pesq +8000 ref deg说明要手填模式；usage: pesq ref deg说明自动识别。16kHz 宽带的评测，程序参数在某些版本里写作+16000。这里有一个从业者们常踩的坑：8kHz 模式下给 16kHz 音频，或者 16kHz 模式下给 8kHz 音频，程序不报错，分数看起来也正常，但和主观听感差得很远。这属于那种“错得很安静”的故障，比报错更危险。4.2 输入文件格式约束：位深、编码、头信息PESQ 对输入 WAV 文件的要求可以列成一张表，建议贴在工位旁边对照：项目窄带模式宽带模式采样率8000 Hz16000 Hz位深16 bit PCM16 bit PCM声道数单声道（1 ch）单声道（1 ch）编码PCM（无压缩）PCM（无压缩）文件头WAV / WaveWAV / Wave不符合要求的文件在运行时会出现两种典型表现：一种是程序直接报Unsupported format或Error: unknown format，告诉你文件头解析不了；另一种是程序正常执行、正常输出分数，但分数意义不明——比如你把一个 48kHz 的音频喂进去，程序只读取前 8k 个采样点对应的秒数，导致实际评测的只是音频的一小段，分数完全没代表性。处理非标准文件的方法比较固定：通过 ffmpeg 或 sox 统一转格式。前面已经给了 ffmpeg 的转换命令，思路是重采样、转单声道、指定位深，一气呵成。日常评测流程里我习惯先做一个preprocess.sh脚本，把所有待测音频统一转成程序要求的格式，再进入评测环节，避免手动转换漏掉某些文件。4.3 读对、读懂分数：MOS-LQO 与置信区间PESQ 程序输出的 MOS-LQO 是一个点估计值，它没有给你置信区间。实际工作中同一个退化音频你可能要评测多次，用不同参考片段，或多次重放采集退化信号，最后看到的分数是一个分布。我一般会跑至少 3 到 5 个不同的语音片段（比如男女声各两段，内容不同），把 MOS-LQO 分数取平均，才作为这一组对比条件的最终结果。分数解读还要结合具体场景。做编解码器对比时，MOS-LQO 在 4.0 以上算良好，3.5 到 4.0 是普通，3.5 以下用户容易感知到明显音质损伤。但这是经验值，不同测试语音集的结果不能直接比较——这就是为什么 PESQ 评测报告里必须写清楚用了哪些测试音频、什么采样率、什么对比条件。同一套算法在用男声朗读新闻的片段里得 4.2，在吵闹背景下的女声片段里得 3.1，两个分数离散度很大，只报一个平均值反而掩盖了问题。5. 避坑与排查：PESQ 评测里最常见的 4 个翻车现场5.1 分数高得离谱（4.3 以上），但听感明显有问题现象：退化信号里明明有可感知的底噪或失真，人耳打分大概 3 分左右，PESQ 却给出 4.3 以上。原因：最常见的是参考信号和退化信号没对齐好，程序自动对齐功能失效后，把信号里的某一段和参考信号的另一段匹配上了。还有一种可能：你拿错了参考信号，退化信号的波形既然和参考信号同源，程序算不出差异，分数自然虚高。第三种可能：参考信号本身已经带了损伤，程序对比的是“退化信号”和“本来就有点脏的参考”，两者差异小，分高。解决：停下手里的活，先检查测试音频的原始素材。用 Audacity 或 Python 脚本把参考信号和退化信号的波形叠在一起看，确认内容对齐、幅度近似。同时确认参考信号是链路输入端的干净原始信号，不是从链路中间某个节点偷录的二次信号。5.2 采样率不符，程序直接退出现象：运行./pesq +8000 ref.wav deg.wav时程序报Error: sample frequency is not matching，或者更隐晦的File has not the expected format。原因：mos-pesq里的程序实现往往同时支持 8kHz 和 16kHz 两套内部模型，但它在处理之前会检查 WAV 文件头里的采样率字段。如果你指定+8000，而 WAV 文件里写的是 16000，程序判断模式与文件不一致，直接拒绝执行。解决：确认评测目标：窄带评测就统一把音频转成 8000 Hz，宽带评测就转成 16000 Hz。用 ffmpeg 批量转换后再执行。不要试图用+8000去评测一个 16kHz 的音频文件，那没有任何意义。5.3 程序正常跑完，但一段音频的分数比另一段低了 1.5 分以上现象：同一个退化信号，用不同参考片段评测，分数离散度极大。原因：某一段参考片段的起始位置和退化信号有几百毫秒的静音前缀，PESQ 做时间对齐时把这部分静音当成了时延的一部分，对齐偏差拉到 300-500ms 后，语音内容根本对不上，出了个极低分。还有一个常见原因是片段内容本身太短，评测窗口不足半秒有效语音，扰动统计没有意义。解决：处理音频时统一做首尾静音切除，保证参考和退化信号从第一个有效语音帧开始，内容完全一一对应。如果需要在长录音中截取片段，保持参考和退化信号的截取起始点一致。做完静音处理后重新跑一遍，看分数是否回到合理区间。5.4 波形幅度差异大，分数不合格现象：退化信号听起来只是比参考信号音量大了一些，或者音量小了一些，PESQ 分数掉到 2 分以下。原因：PESQ 的电平对齐模块会尝试做增益补偿，但这个能力是有限度的。如果链路里增益差超过约 30dB，或者出现了削波失真（数字削波会产生大量非线性谐波），对齐失效，分数被严重拉低。人耳对纯音量大小变化不敏感，但 PESQ 对幅度异常会很敏感。解决：评测流程里加一个响度归一化步骤，用ffmpeg loudnorm或先测有效值再统一乘一个增益系数，把参考信号和退化信号的平均响度对齐到大致相同的水平。注意不要对退化信号做任何动态范围压缩，那会改变它本身的损伤特征，评测结果就不再反映真实链路了。这里我个人的习惯是退化信号只做幅度缩放，不做 EQ 和动态处理。5.5 多平台移植：Windows 与 Linux 的路径与换行符坑现象：在 Windows 上解压mos-pesq.zip，双击想运行的.exe有执行权限，但运行时报缺少某个.dll或直接闪退；而在 Linux 上解压，脚本里的换行符变成了\r，导致$'\r': command not found。原因：mos-pesq.zip里的可执行文件是针对特定平台编译的，Windows 和 Linux 的二进制不通用。配套的.sh脚本或Makefile如果在 Windows 下用记事本编辑过再传回 Linux，行尾的 CRLF 会让 bash 和 make 解析出错。解决：Windows 上先看包里有没有.exe或.bat文件，没有就说明这个包只支持 Linux，需要换成对应平台版本；Linux 上如果出现command not found但文件名明明存在，先执行sed -i 's/\r$//' 脚本名.sh去掉 CRLF 再跑。这里多说一句，这只是文本编码层面的问题，和任何网络连接工具无关，属于纯粹的文件格式兼容问题。6. 批量评测与回归门禁：把一条命令变成一套自动化流程单条./pesq跑通只是起点，实际工程里的需求永远是批量：你要评测 10 组编解码器参数、20 条网络损伤条件、5 种降噪算法，每组条件对应几十个语音片段。手动一条条跑不现实，也违背了 PESQ 的自动化初衷。我一般会把它组织成一个带目录参数和结果归档脚本的批处理流程。下面给你一个可以直接抄走的 Python 脚本框架：import os import subprocess import csv ref_dir = "refs" # 参考信号目录 deg_dir = "degs" # 退化信号目录，子目录名代表测试条件 output_csv = "pesq_results.csv" pesq_bin = "./pesq" conditions = [d for d in os.listdir(deg_dir) if os.path.isdir(os.path.join(deg_dir, d))] with open(output_csv, "w", newline="") as f: writer = csv.writer(f) writer.writerow(["condition", "ref_file", "deg_file", "mos_lqo"]) for cond in conditions: deg_files = [f for f in os.listdir(os.path.join(deg_dir, cond)) if f.endswith(".wav")] for deg_file in sorted(deg_files): ref_file = deg_file # 假设参考文件和退化文件同文件名 ref_path = os.path.join(ref_dir, ref_file) deg_path = os.path.join(deg_dir, cond, deg_file) if not os.path.exists(ref_path): print(f"[跳过] 缺少参考文件: {ref_file}") continue result = subprocess.run([pesq_bin, "+8000", ref_path, deg_path], capture_output=True, text=True) # 从输出中解析 MOS-LQO 分数 for line in result.stdout.splitlines(): if "MOS-LQO" in line: score = line.split(":")[-1].strip() writer.writerow([cond, ref_file, deg_file, score]) print(f"{cond} / {deg_file} -> {score}")脚本逻辑说明：先遍历degs目录下的所有子目录，每个子目录名代表一种测试条件（比如codec_a_24kbps、loss_5%），对这个子目录里的每一个 WAV 文件，在refs目录下找同名参考文件，构造命令行调用pesq，解析输出里的MOS-LQO分数，写进 CSV。用subprocess.run而不是os.system是为了能稳定捕获命令输出，解析分数时有更好的容错性。参数说明：deg_dir下的子目录结构是这个脚本约定的，参考文件名和退化文件名必须一致，因为脚本用同一个文件名去两处找文件。如果你的文件命名习惯不同，可以改成遍历时记录下标或者读取一个映射表，核心逻辑不变。capture_output=True会把程序的标准输出捕获到内存里，我们在里面搜MOS-LQO这一行取分数。程序出错了怎么办？cust输出为空，脚本不会崩，CSV 里这一行不会写，后续检查 CSV 时哪些条件缺行就一目了然。这种设计比中途抛异常更符合批量评测的容错需求。有了这个脚本，评测结果就变成一张 CSV 表。我习惯在表上加一个汇总步骤：每个条件取所有片段分数的平均值和标准差，平均值横向对比不同条件的音质差距，标准差反映分数稳定性。这并不是算完就完——把结果贴到一个简单的对比表里，做算法调优和回归验证时能一眼看出哪个改动是有效的，哪个改动只是玄学波动。我现在做编解码器优化时，会把每次改动后的评测 CSV 归档成带时间戳的文件，防止“这次结果比上次高 0.2 分”这种结论没有可追溯的数据支撑。说一个我自己的教训：早期做评测时偷懒只跑一个 8 秒片段就得结论，某次调整算法参数后，这一个片段的分数提高到 4.2，我就以为改动有效，结果换了一个片段重测，分数反而跌了 0.3。从那以后我再也不敢拿单个片段的分说事了，批处理脚本和至少 5 个片段的平均值成了我的习惯底线。PESQ 是一个稳定的算法，但语音内容本身是多变的，评测流程的稳定性比单次分数的变化更能说明问题。希望这篇从解压到批处理的笔记能帮到你，让你手里的mos-pesq.zip真正成为评测流程里可信赖的标尺，而不是一个跑完就忘的黑匣子。本文还有配套的精品资源，点击获取