ASR项目实战-前处理

115 views

上接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上可用的音频文件。

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

一些参考资料:

采样率和位深

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

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

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

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

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

一些参考资料:

声道

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

前处理的实现

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

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

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

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

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

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

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

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

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

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


若非注明,均为原创,欢迎转载,转载请注明来源:ASR项目实战-前处理

关于 JackieAtHome

基层程序员,八年之后重新启航

此条目发表在 工作总结, 笔记 分类目录,贴了 , 标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Protected with IP Blacklist CloudIP Blacklist Cloud