ASR项目实战-前处理-526互联

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

预备知识

常见的音频文件，比如.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上可用的音频文件。

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

一些参考资料：

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

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

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

一些参考资料：

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

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

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

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

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

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

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

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

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