本文深入探讨前处理环节。
首先介绍一些基本的名词,比如
- 文件名后缀
- 文件格式
- 音频格式
- 采样率和位深
预备知识
文件名后缀、文件格式和音频格式
常见的音频文件,比如.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时:文章来源:https://www.toymoban.com/news/detail-764149.html
- 没有开启声道的识别,则只处理第一个声道的音频数据。
- 开启了声道的识别,但只指定了一个声道,则仅处理第一个声道的音频数据。
- 开启了声道的识别,指定了多个声道,则将处理多个声道的音频数据。
对于云服务工程化交付团队而言,多声道的处理,存在一些让人纠结的地方,值得仔细思量,如下:文章来源地址https://www.toymoban.com/news/detail-764149.html
- 关于识别的时效性。假如开发者要求识别音频数据中多个声道的数据,那么工程团队首先需要将多个声道的数据抽取出来,保存至不同的音频文件中,接下来的识别有两个选项:
- 串行处理。将多个音频文件按照声道的顺序追加在一起,作为一个任务,提交给传递给引擎识别。这时总体的识别时长会变长,可能影响开发者使用API的体验。
- 并行处理。将多个音频文件,提交不同的识别任务。对开发者而言,识别的时长和单声道的音频文件类似。但对云服务团队而言,对任务调度、资源管理、结果组装即是一个考验。
- 关于识别结果的组装。对于接口如何定义,有比较大的挑战。
- 关于计费。Google的策略是一个声道即收一份钱。这里有一个问题,对于处理失败的音频,是否要收费。
- 假如识别失败时不收费,工程交付团队在实施时,需要区分识别成功、失败的场景,并做相应的记录,否则无法满足计费的要求。这个策略会引入一个问题,对于某些恶意人群,可能会反复提交存在问题的音频,导致算法引擎处理失败,这会占用云服务的资源,但却不必付出代价。
- 假如识别失败时仍然收费,对于工程交付团队而言,这个策略比较容易实现。唯一的问题在于,需要引导开发者乐意为识别失败的场景付费。
到了这里,关于ASR项目实战-前处理的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!