3,第三阶段
第三阶段就是调试。第二阶段结束后说话就有词出来,但都是错的,需要排查定位问题。在线语音识别系统从大的角度可以分两块:模型和代码实现。首先我们需要定位是模型的问题还是代码实现的问题,先从模型排查。在第一阶段时利用thchs30大致搞清楚了在线解码的机制,是用模型tri1调的,当时识别率很差。现在要关注识别率了,把模型换成了tri2b,识别率有所提高。这说明kaldi里的在线解码的代码是没有问题的,识别率差问题出在模型。况且全球这么多人在用kaldi,如果在线解码有问题应该早就fix了。所以我们决定把我们生成的模型文件放进thchs30里来验证模型是否有问题。为了排除从MIC输入的音频数据有噪声等的干扰,先用读文件的方式验证。把我们的模型文件放进去后发现基本识别不正确,这说明模型是有问题的。负责模型的同学去调查,发现用于训练的音源都是8K采样的,但是在线解码用的都是16K采样的,这是我们自己挖的坑,用重采样程序把8K的全部转成16K的,这个坑也就填好了,但是识别率依旧不好。又发现训练集全是英国人的发音,而测试集是我们中国人的发音,有一定口音的,最好用我们中国人自己的发音作为训练集。于是我们自己又录了用于训练的音源,为了加大训练的数据,又请好多其他人录了音源。训练后得到了新的模型,再放到thchs30里面验证,识别率有六七成了,这说明模型的大方向对了,为了提高识别率,模型还需要继续调试。
接下来就要看代码部分是否有问题了。把新生产的模型放进我们自己的系统,并且用从音频文件都数据的方式(我们的系统既可以从MIC采集数据也可以从音频文件读数据,从音频文件读数据是为了debug)来替代从MIC采集到的数据(这样做是为了排除噪声等因素的干扰)来看代码是否有问题。运行下来发现识别率依旧很差,这说明我们的代码也是有问题的。在第二阶段我已经调试过部分代码,确保了在kaldi process thread里从PCM ring buffer里拿到的音频数据是没有问题的。还有两方面需要调试,一是送进MFCC的PCM数据要是OK的,二是我们的在线解码机制要跟kaldi里的在线解码机制完全一样。一很快就调试好了。二是先再深入研究吃透kaldi里的在线解码机制,改正我们与它不一样的地方,经过两三天调试后识别率跟thchs30里的差不多了,这说明我们的代码经过调试后也有一个好的base了,后面就要开始调性能了。
前面是通过从音频文件中读取数据来做在线识别的,数据相对干净些。现在要从MIC读取音频数据做真正在线识别了,试下来后识别率明显偏低,这说明我们的前处理还没完全做好(前面调试时只加了ANS模块)。我把前处理后的音频数据dump出来用CoolEdit听,的确有时候音质不好,于是我又把webRTC中的AGC模块加上去,再次dump出前处理后的音频数据听,多次听后都感觉音质正常。再来运行加了AGC后的从MIC采集音频数据的在线识别,识别率果然有了明显的提升。前处理能做的都做了,要想再提高识别率,就要靠模型发力了。做模型的同学一边请更多的人录音源来训练,一边尝试各种模型,最终用的是tri4b,有了一个相对不错的识别率。由于我们用的是GMM-HMM,如今主流的语音识别中已不再使用,老板就觉得没有必要再调了,后面肯定会用主流的模型的,但是整个嵌入式上的在线语音识别软件代码尤其软件架构和音频采集还是有用的,后面就要基于这些代码做真正的产品。
对语音识别领域的资深人士来说,这个嵌入式在线语音识别系统还很稚嫩。但通过搭这个系统,让我们对语音识别领域有了多一点的感性认识,也有了一个良好的开端,给老板以信心,并且可以继续做下去。这次工程上的事情偏多,后面希望更深入的做下去,累积更多的语音识别领域的经验。搭这个系统没有任何可供参考的资料,纯粹是根据我们以往的经验摸索着搭出来的。做的产品可能不一样,但很多解决问题的思路都是一样的。如果有朋友也搭过嵌入式上的在线语音识别系统,欢迎探讨,搭出一个更好的在线语音识别系统。
3,第三阶段
第三阶段就是调试。第二阶段结束后说话就有词出来,但都是错的,需要排查定位问题。在线语音识别系统从大的角度可以分两块:模型和代码实现。首先我们需要定位是模型的问题还是代码实现的问题,先从模型排查。在第一阶段时利用thchs30大致搞清楚了在线解码的机制,是用模型tri1调的,当时识别率很差。现在要关注识别率了,把模型换成了tri2b,识别率有所提高。这说明kaldi里的在线解码的代码是没有问题的,识别率差问题出在模型。况且全球这么多人在用kaldi,如果在线解码有问题应该早就fix了。所以我们决定把我们生成的模型文件放进thchs30里来验证模型是否有问题。为了排除从MIC输入的音频数据有噪声等的干扰,先用读文件的方式验证。把我们的模型文件放进去后发现基本识别不正确,这说明模型是有问题的。负责模型的同学去调查,发现用于训练的音源都是8K采样的,但是在线解码用的都是16K采样的,这是我们自己挖的坑,用重采样程序把8K的全部转成16K的,这个坑也就填好了,但是识别率依旧不好。又发现训练集全是英国人的发音,而测试集是我们中国人的发音,有一定口音的,最好用我们中国人自己的发音作为训练集。于是我们自己又录了用于训练的音源,为了加大训练的数据,又请好多其他人录了音源。训练后得到了新的模型,再放到thchs30里面验证,识别率有六七成了,这说明模型的大方向对了,为了提高识别率,模型还需要继续调试。
接下来就要看代码部分是否有问题了。把新生产的模型放进我们自己的系统,并且用从音频文件都数据的方式(我们的系统既可以从MIC采集数据也可以从音频文件读数据,从音频文件读数据是为了debug)来替代从MIC采集到的数据(这样做是为了排除噪声等因素的干扰)来看代码是否有问题。运行下来发现识别率依旧很差,这说明我们的代码也是有问题的。在第二阶段我已经调试过部分代码,确保了在kaldi process thread里从PCM ring buffer里拿到的音频数据是没有问题的。还有两方面需要调试,一是送进MFCC的PCM数据要是OK的,二是我们的在线解码机制要跟kaldi里的在线解码机制完全一样。一很快就调试好了。二是先再深入研究吃透kaldi里的在线解码机制,改正我们与它不一样的地方,经过两三天调试后识别率跟thchs30里的差不多了,这说明我们的代码经过调试后也有一个好的base了,后面就要开始调性能了。
前面是通过从音频文件中读取数据来做在线识别的,数据相对干净些。现在要从MIC读取音频数据做真正在线识别了,试下来后识别率明显偏低,这说明我们的前处理还没完全做好(前面调试时只加了ANS模块)。我把前处理后的音频数据dump出来用CoolEdit听,的确有时候音质不好,于是我又把webRTC中的AGC模块加上去,再次dump出前处理后的音频数据听,多次听后都感觉音质正常。再来运行加了AGC后的从MIC采集音频数据的在线识别,识别率果然有了明显的提升。前处理能做的都做了,要想再提高识别率,就要靠模型发力了。做模型的同学一边请更多的人录音源来训练,一边尝试各种模型,最终用的是tri4b,有了一个相对不错的识别率。由于我们用的是GMM-HMM,如今主流的语音识别中已不再使用,老板就觉得没有必要再调了,后面肯定会用主流的模型的,但是整个嵌入式上的在线语音识别软件代码尤其软件架构和音频采集还是有用的,后面就要基于这些代码做真正的产品。
对语音识别领域的资深人士来说,这个嵌入式在线语音识别系统还很稚嫩。但通过搭这个系统,让我们对语音识别领域有了多一点的感性认识,也有了一个良好的开端,给老板以信心,并且可以继续做下去。这次工程上的事情偏多,后面希望更深入的做下去,累积更多的语音识别领域的经验。搭这个系统没有任何可供参考的资料,纯粹是根据我们以往的经验摸索着搭出来的。做的产品可能不一样,但很多解决问题的思路都是一样的。如果有朋友也搭过嵌入式上的在线语音识别系统,欢迎探讨,搭出一个更好的在线语音识别系统。