分析评估和定位声音质量

/**

    * @author wangdaopo

    * @email 3168270295@qq.com

    */

影响音频质量和稳定性的因素

音质好坏的评价，响度、音高、音色，

测试，你的语音引擎是基本可用的，客观评测软件是RMAA（RightMark Audio Analyzer；比较适合开发者自己去做，在上线前自测的一些方法

频率与音色的听音训练 及 训练音乐听觉

语音通信中提高音质的方法

音频软件开发中的debug方法和工具

 

 

• 影响音频质量和稳定性的因素到底有哪些   实时语音到底有哪些特征？

0.通话中语音信息丢失了，这个对话是根本不能继续下去的

1.网络随机性（丢包 延时 抖动）：都会导致听感滞后或者断续；网络对音频质量的影响是非常直观的，如果承载音频信息的语音包在网络传输的过程中丢失，晚到，或者不均匀的到，就会造成我们常说的丢包，延时和抖动。另外值得一提的是，除了在传输层引起的丢包抖动，最后一公里(Last Mile)的问题（路由器，移动数据网络等）也会引起丢包抖动

实时语音的问题很难去定位    语音卡顿，到底是什么原因？ 问题多源性：你首先想到的肯定是网络，网络会卡顿。 其实还有别的原因会引起卡顿，比如设备CPU负荷很高时，录放音调度有问题，也会导致声音的卡顿。更隐性的问题，比如回声消除，

2.设备 （声学设计，计算能力）：听感体验很大程度受到录放音设备的制约,扬声器之间的耦合很大，或者扬声器的非线性很大，导致你的算法不能很好贯通在上面，导致听感上有一些卡顿、毛刺的问题。

3.物理环境 (密闭环境，噪声, 啸叫等)比如我在一个很吵的环境和你打电话，或者我在很小的房间跟你打电话感觉是不一样的；还有远场拾音，比如做电视应用，必须要在2米以外收音，这个时候麦克风的拾音效果决定了音频听到的体验
 

听音

建议对通话进行录音，这样可以在测试后重听和标注，更好的分析问题。如果测试的引擎不带录音的话，可以在外放的而环境通过外部设备来录制。

一般我们先在较好的网络状态下测试音频的基础质量，然后慢慢增加丢包率来测试一个引擎抗丢包的边界。

 

音频软件开发中的debug方法和工具

1 log

2 最小系统法

做一个软件系统时刚开始是一个最小系统，即缺了任何一个模块，系统不能用。后来加上一个个功能使系统完备。在写代码时我们可以加上一些标志位使这些后加的功能enable或者disable。这有助于后面出现问题时排查。下图是语音通信的软件框图，最小系统是采集播放编解码网络发送接收等，没有这些不能通话。而前处理的一些模块（AEC/ANS/AGC等）则不是最小系统里面的，它们是后来一步步加上去的。假设系统出问题了，我们先disable前处理的诸多模块，形成最小系统，看有没有问题，有说明问题在最小系统里，再继续调查。没有的话先把AEC使能看有没有问题，有说明问题在AEC里，没有说明问题在ANS或者AGC里。如没有问题继续使能ANS看是否有问题，有说明问题在ANS里，没有说明问题在AGC里。经过这几步基本定位问题在哪个模块里，后面再结合其他方法直到找到根本原因。

                                       

音频开发时不管是voice还是music好多问题是音频听下来不对，这时就要用音频特有的debug方法了。

3 dump音频数据

Dump音频数据就是把音频数据dump出来用工具（比如CoolEdit, 后面讲工具时会具体讲）播放，或者看波形，或者看频谱，看是否正确。一般是找几个可能的dump点，进模块前一个dump点, 出模块后一个dump点。如果进模块前dump出来的数据是好的，而出模块后的音频数据是坏的，那么问题就出在这个模块了，再一步步排查，最终找到把音频数据写坏的地方。还是以上面的语音通信软件框图为例，在AEC前设一个dump点，AEC后再设一个dump点，如果AEC前的音频数据是好的，AEC后的音频数据不好了，问题肯定出在AEC里。

                                      

Dump音频数据也有几种不同的方法，在不同的场合用不同的方法。

a）把音频数据写进指定的文件里，问题复现后把这个文件导出来用工具分析。

b）把音频数据放进RTP包里发送到指定的IP地址上，用抓包工具（比如wireshark, 后面讲工具时具体讲）抓到这些包。由于是PCM数据，在wireshark上可以直接听或者看波形。这多用于语音通信场景。

c）有时候有些模块对自己是黑盒的，比如在linux下kernel space的音频驱动对做use space的来说就是黑盒。在use space里调查下来音频数据没问题，但是最终从扬声器或者耳机出来的音频是有问题的，这时可以用一根音频线一头连着出问题的设备的耳机，另一头连着电脑，复现问题，用CoolEdit把出问题时的音频录下来，先听确认问题出在这个黑盒模块里，然后看波形，是否有规律，如果有规律，好查一些，没规律再具体问题具体分析。

4 loopback音频数据

loopback音频数据就是形成回环，从而来排查问题。还是以上面的语音通信软件框图为例，有几种不同层次的loopback，见下图：

                                      

1)    把采集和播放形成loopback，即把采集到的音频数据立刻payback出来，听下来是好的说明音频驱动没问题，不好说明问题在音频驱动里面。

2)    把前处理后的数据和播放形成loopback，即把ANS后的PCM数据直接播放出来，听下来是好的说明前处理没问题，不好说明问题在前处理里面。

3)    把编码和解码形成loopback，即把编码后的码流立刻放进解码器得到pcm数据再playback出来，听下来是好的说明问题出在网络侧，不好说明问题出在编解码里面。

通过上面几个loopback基本上可以定位问题出在哪个模块里，再在这个模块里仔细调查直到找到根本原因。

 

5，工具

上面讲方法时提到了几个工具，如CoolEdit，下面具体讲。

1）CoolEdit / Audition

这应该算是做音频开发的必备工具了。以前叫CoolEdit，后来被Adobe收购重新包装后形成了Audition。我个人还是习惯于用CoolEdit，原因一是用习惯了，二是CoolEdit可以保存成PCM文件，而Audition却不可以，做音频开发的保存成PCM文件最方便。

用CoolEdit可以听音频是否正常，也可以看波形，在出问题时看波形是否有规律，还可以看频谱。同时还可以生成一些特定的音频文件用于去调试。比如调试音频算法时用一个时间相对较长的（> 1秒）的音频文件会很不方便，主要是因为log多，不便于分析。算法通常一帧为10ms或者20ms，需要几帧就可以调试算法了。这时用CoolEdit做一个几十ms的PCM文件给算法调试用。再比如用CoolEdit做一个20HZ到20000HZ的扫频文件作为某个算法或者某个系统的输入，看这个算法或者系统的频响如何。

CoolEdit的具体使用可以看help文件，或者看网上的文章，这里就不详细讲了。

2）Wireshark

Wireshark主要用于语音通信场景，抓网络上的语音包。当然它也可以抓其他类型的包，在做音频开发时就是抓语音相关的RTP/RTCP包了。抓到包后可以看某个具体包的RTP/RTCP属性，比如sequence number/time stamp等，从而去分析定位问题等。Wireshark也可以分析丢包率等，还可以播放codec 为g711的语音包，当然还有其他用途，这里就不一一说了，有需求的可以到网上看具体的文章。

3）mediainfo

Mediainfo主要用于音乐场景，用它可以看到一个音乐文件（例如MP3）的属性，有采样率/声道数/codec类型/码率等。如果在log中看到的打印值和mediainfo中显示的值对不上，说明读取音乐文件属性的代码有问题。

4）GoldWave

GoldWave也主要用于音乐场景，用它来做采样率/codec/码率等的转换。支持的采样率、codec、码率都特别多，对调试有不少帮助。例如某个系统要支持采样率为11025HZ的音乐文件，但是市面上的音乐文件一般为44.1KHZ或者48KHZ的，这就需要专门的工具去做转换，从而得到想要的文件。然后拿这个文件去调试测试看系统是否支持采样率为11025HZ的音乐文件。

 

 

 

• 在音质好坏的评价中，最重要的是这四个方面的对比，把这四点的思路理顺了，在选择或评测时就不至于会无从下手： 

1、音色的“冷”、“暖” 选择。  
2、音场的“空间感”和“定位感”对比。 
3、平衡度的“左右声道音量及分离程度”和“三频量感平衡”对比。 
4、解析力的三频质感和层次感、细节还原能力对比。 
看起来是少，但实际上涉及的面很广，要运用起来还真不简单呢！

 

一、选择音色：暖色调的音色听起来温和闲适（欧洲的产品大多数声音偏暖），适合听古典乐；而冷色调听起来则