ASR项目实战-前处理

本文深入探讨前处理环节。
首先介绍一些基本的名词，比如

• 文件名后缀
• 文件格式
• 音频格式
• 采样率和位深

预备知识

文件名后缀、文件格式和音频格式

常见的音频文件，比如.wav、.mp3、.m4a、.wma等，这些都代表什么？
仅仅是这类音频文件的后缀而已，不一定和音频文件的编码、音频数据的编码相关。

举例说明：

• 比如.pcm
• 比如.wav，一般保存的是带有wav规范文件头的，PCM格式的音频。
• 比如.mp3，指的是保存Moving Picture Experts Group Audio Layer III格式的音频数据的文件。
• 比如.m4a，和前两个后缀不同，并没有名为m4a的规范，实际指的是保存MPEG-4格式的音频数据的文件。虽然没有以.mp4为结尾，但实际上和.mp4文件遵循了相同的规范，仅仅是由于APPLE的数码产品大热，才让m4a流行起来。而m4a文件存储数据时，可以保存AAC格式编码的音频数据，也可以保存mp3格式编码的音频数据。
• 比如.wma，微软公司出品，在Windows上可用的音频文件。

从上述介绍可知，各种文件的格式，和音频数据自身的格式，可以不同。了解到这一点，很重要。

一些参考资料：

• m4a
• 音频编码
• PCM数据格式
• 常见音频编码格式解析
• 音频 PCM音频编码格式详解
• AAC（高级音频编码）帧格式及编码介绍
• 常见音频编码格式(注：编码格式不同于文件格式

采样率和位深

采样率，即1秒种之内，采集数据的频率。比如：

• 电话录音一般为8K，即1秒钟内采集8000次。
• CD音质为44.1KHZ，即1秒钟内采集441000次。
  显然，采样频率越高，采集到的数据量越大，丢失的信息越少，越接近于原始数据。

位深，即每个采集点，使用多少个二进制位来表达，常见的有：

• 8位，对应1个字节。
• 16位，对应2个字节。
• 24位，对应3个字节。
  显然，位深越大，针对单个采集点的数据，表达的范围越大，越准确。

从抽象的角度看，人的声音，可以理解为信号，而信号可以通过FFT变换，转换为各种波的迭加。理解这一点，很重要。
人的声音，对于大数人而言，发音频率一般在4K以内，基于前述人声可使用信号来表达的理论，使用8K的采样频率，可以满足常见的诉求。

一些参考资料：

• 人声频率范围
• 人声频率表及各频段的处理方式

声道

相关的词汇有环绕立体声、左右声道等。
通常而言，一个收音设备可以产生一个声道的数据。对于高端会议、电影、流行音乐等，一般会有多个收音设备同时采集数据，因此在同一份音频文件中会产生多个声道。
这非常有助于还原现场的音效，给人以身临其境的美妙体验。

前处理的实现

在ASR项目实战-产品分析提到了ASR的前处理过程，包括如下几个环节：

• 多音频格式的支持
• 重采样
• 多声道的处理
• 降噪和去回声

对于上述多音频格式的支持 、重采样的支持 、多声道的支持 ，简单、有效、低成本的方法，可以使用FFmpeg来实现，有很多资料可以查阅。

不过在将FFmpeg应用到产品里时，特别需要关注其License的相关说明，以及如下文档：

• GNU Lesser General Public License, version 2.1
• GNU General Public License, version 2
• Frequently Asked Questions about the GNU Licenses

从而选择恰当的集成方式。

如ASR项目实战-产品分析所介绍，降噪和去回声 一般在收音设备上实现，较少通过软件来实现。主要原因是相关算法比较复杂，导致普通的交付团队会判定投入产出比太低。

对于多声道的处理，这里再多说几句。
分析Google的Speech To Text云服务API的文档，可以发现Google在多声道处理上有独到之处，提供了识别多声道的开关，同时允许指定要处理的声道的数量，代价是每个声道的处理，均要收费。
假如开发者传递的音频里存有多个声道，调用API时：

• 没有开启声道的识别，则只处理第一个声道的音频数据。
• 开启了声道的识别，但只指定了一个声道，则仅处理第一个声道的音频数据。
• 开启了声道的识别，指定了多个声道，则将处理多个声道的音频数据。

对于云服务工程化交付团队而言，多声道的处理，存在一些让人纠结的地方，值得仔细思量，如下：

1. 关于识别的时效性。假如开发者要求识别音频数据中多个声道的数据，那么工程团队首先需要将多个声道的数据抽取出来，保存至不同的音频文件中，接下来的识别有两个选项：
   1. 串行处理。将多个音频文件按照声道的顺序追加在一起，作为一个任务，提交给传递给引擎识别。这时总体的识别时长会变长，可能影响开发者使用API的体验。
   2. 并行处理。将多个音频文件，提交不同的识别任务。对开发者而言，识别的时长和单声道的音频文件类似。但对云服务团队而言，对任务调度、资源管理、结果组装即是一个考验。
2. 关于识别结果的组装。对于接口如何定义，有比较大的挑战。
3. 关于计费。Google的策略是一个声道即收一份钱。这里有一个问题，对于处理失败的音频，是否要收费。
   1. 假如识别失败时不收费，工程交付团队在实施时，需要区分识别成功、失败的场景，并做相应的记录，否则无法满足计费的要求。这个策略会引入一个问题，对于某些恶意人群，可能会反复提交存在问题的音频，导致算法引擎处理失败，这会占用云服务的资源，但却不必付出代价。
   2. 假如识别失败时仍然收费，对于工程交付团队而言，这个策略比较容易实现。唯一的问题在于，需要引导开发者乐意为识别失败的场景付费。