为了账号安全,请及时绑定邮箱和手机立即绑定

微信小程序语音识别服务搭建全过程解析(支持新老接口mp3/silk录音)

silk v3(或新录音接口mp3)录音转olami语音识别和语义处理的api服务(ubuntu16.04服务器上实现)
重要的写在前面

重要事项一:
所有相关更新,我优先更新到我个人博客中,其它地方的文章属于本人或他人转发,不一定及时同步。

微信小程序老录音接口录silk后调用:https://api.happycxz.com/wxapp/silk2asr
微信小程序新录音接口录mp3后调用:https://api.happycxz.com/wxapp/mp32asr

亲测录音文件大小,供参考:录音10秒钟,silk_v3大约是10kB大小,16k单通道48k编码的mp3大约是60kB大小。老接口录音更节约流量。

重要事项二:
目前本文中提到的API已支持微信小程序录音文件格式:silk v3、mp3。
注:微信小程序开发工具上的录音不论是新接口还是老接口,都是webm/base64格式,虽然后辍名是silk(或mp3),但不是真正的silk v3(或mp3)格式的,打开看头部是 data:audio/webm;base64, 开头的。
为了便于调试,2017年9月份时我补逻辑给支持上了,但是:我在2017年11月份发现原有的webm/base格式又不支持了
api服务器端代码没有动过,跟踪查过,目前仅发现在2017年10月份之前用微信小程序开发工具录的文件,还是可以支持的,在10月份之后的文件,就不支持了,具体什么原因只能问老马家的人了。
结论是:调用我本文中提到的两个接口,只能用真机做测试,不能用电脑录音来测试语音识别了。

重要事项三:
想要用我这个API,务必先去cn.olami.ai申请appKey和appSecret,然后将appKey告知我,我加进支持列表方可调用,二者缺一不可。文末有将有调用此文提到的API服务的案例以及源码分享文章链接。

调用案例:“遥知之”智能小秘,欢迎扫码体验:
小程序码小

重要事项四:
欢迎转载本文,没有什么别的要求,请保留:

本文所有源码对应码云链接:https://gitee.com/happycxz/silk2asr
本文所有源码对应github链接:https://github.com/happycxz/silk2asr

为什么做?

前不久刚发布了一个智能生活信息查询的小助手“遥知之”,可惜只能手动输入来玩,这一点体验很不好,因为微信小程序录音是silk格式的,现在主要的语音识别接口都不支持。

在网上搜了下相应的功能,也只有php做的开源代码实现的silk转wav的服务器代码,首先我不熟悉PHP,其次也不知道后期有没有维护,干脆自己做一个tomcat + java版的,权当学习娱乐一下。

怎么做?

准备环境

先需要有一个支持https的服务器,我目前用的服务器是阿里云秒杀的免费最低配置的服务器,预装的ubuntu16.04 LTS版,然后自己捣鼓一下,配置上了https,具体是用 nginx + let's encrypt + tomcat来提供的https的API。这里不详细介绍,感兴趣的自己研究下。

需要一个silk解码器,网上有一牛在2015年年初曾经发贴讨论过这个话题:silk v3 编码的音频怎么转换成 wav 或 mp3 之类的?

而且此牛后面有持续研究,提供了开源的silk_v3_decoder项目,具体见:kn007大牛的silk_v3_decoder

对了,开源项目是github上的,服务器上装个git,这不用额外再说明了吧。

搭建服务步骤

下载silk-v3-decoder

基本就是在服务器上找个目录,把大牛kn007的项目下载下来。

root@alijod:/home/jod/wechat_app# mkdir download
root@alijod:/home/jod/wechat_app# cd download/
root@alijod:/home/jod/wechat_app/download# git clone https://github.com/kn007/silk-v3-decoder.git
Cloning into 'silk-v3-decoder'...
remote: Counting objects: 634, done.
remote: Total 634 (delta 0), reused 0 (delta 0), pack-reused 634
Receiving objects: 100% (634/634), 72.79 MiB | 9.50 MiB/s, done.
Resolving deltas: 100% (352/352), done.
Checking connectivity... done.
root@alijod:/home/jod/wechat_app/download# ll
total 12
drwxr-xr-x 3 root root 4096 Sep 18 10:11 ./
drwxr-xr-x 7 root root 4096 Sep 18 10:11 ../
drwxr-xr-x 5 root root 4096 Sep 18 10:11 silk-v3-decoder/
root@alijod:/home/jod/wechat_app/download# ls silk-v3-decoder/
converter_beta.sh  converter.sh  LICENSE  README.md  silk  windows

看上述目录,其实只用到了silk这个目录,和converter.sh这个脚本。silk目录中的C代码需要gcc编译,converter.sh脚本需要修改一下,后续都会提。

编译silk_v3_decoder

根据https://github.com/kn007/silk-v3-decoder上的README,用上这个工具,需要gcc和ffmpeg,gcc是在编译silk时执行make时用到的(普及一下小白),ffmpeg其实是脚本里要用的,与编译无关。事实是,ffmpeg在整个服务搭建过程确实不是必备的,后文将有针对这个额外说明,只是本人偷懒,暂时不想再深入研究了。

gcc的环境,如果没有安装,自己网搜吧,这里不扯了,直接进入正题:

root@alijod:/home/jod/wechat_app/download# cd silk-v3-decoder/silk/
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder/silk# ll
total 32
drwxr-xr-x 5 root root  4096 Sep 18 10:11 ./
drwxr-xr-x 5 root root  4096 Sep 18 10:11 ../
drwxr-xr-x 2 root root  4096 Sep 18 10:11 interface/
-rw-r--r-- 1 root root  3278 Sep 18 10:11 Makefile
drwxr-xr-x 2 root root 12288 Sep 18 10:11 src/
drwxr-xr-x 2 root root  4096 Sep 18 10:11 test/
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder/silk# make
…………
…………(这里是一大段编译过程日志)
…………
a - src/SKP_Silk_scale_vector.o
gcc -c -Wall -enable-threads -O3   -Iinterface -Isrc -Itest  -o test/Decoder.o test/Decoder.c
test/Decoder.c: In function ‘main’:
test/Decoder.c:187:9: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result [-Wunused-result]
         fread(header_buf, sizeof(char), 1, bitInFile);
         ^
g++  -L./ test/Decoder.o -lSKP_SILK_SDK -o decoder
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder/silk# ls
decoder  interface  libSKP_SILK_SDK.a  Makefile  src  test
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder/silk# 

可以看到,上面编译过程中,最后出现了一个warning,不过没关系,ls查一下,第一个“decoder”就是我们要用的binary啦,有它就证明编译成功了。

测试silk_v3_decoder功能

接下来就要验证一下编出来的这个能不能用了。
根据https://github.com/kn007/silk-v3-decoder上的README,摘下来一段:

sh converter.sh silk_v3_file/input_folder output_format/output_folder flag(format)

比如转换一个文件,使用:

sh converter.sh 33921FF3774A773BB193B6FD4AD7C33E.slk mp3

注意:其中33921FF3774A773BB193B6FD4AD7C33E.slk是要转换的文件,而mp3是最终转换后输出的格式。

参考上面那个例子就好了,脚本参数只有两个,一个是源文件相对或绝对路径,另一个是目标格式。
也就是说上述命令会将33921FF3774A773BB193B6FD4AD7C33E.slk(注意,例子里是slk后辍,你自己在获取微信小程序录音重命名时如果是.silk,别疑惑了,linux环境文件后辍名是没有实际意义的,感兴趣自己网搜,to小白)转码成33921FF3774A773BB193B6FD4AD7C33E.mp3。

没有silk源文件?别急,我准备了个silk_v3录音文件,附带着转出来的mp3一起放在我服务器上了,需要的可以去下载(右击后另存即可,mp3可以在线播放,silk播放不了,直接单击会“403”):
微信小程序原始录音文件:sample.silk
converter.sh脚本转码后的文件:sample.mp3

附上我转码的操作过程:

root@alijod:/home/jod/wechat_app/download/silk-v3-decoder# ll
total 48
drwxr-xr-x 5 root root 4096 Sep 18 10:43 ./
drwxr-xr-x 3 root root 4096 Sep 18 10:11 ../
-rw-r--r-- 1 root root 4131 Sep 18 10:11 converter_beta.sh
-rw-r--r-- 1 root root 3639 Sep 18 10:11 converter.sh
drwxr-xr-x 8 root root 4096 Sep 18 10:11 .git/
-rw-r--r-- 1 root root 1076 Sep 18 10:11 LICENSE
-rw-r--r-- 1 root root 3582 Sep 18 10:11 README.md
-rw-r----- 1 root root 6188 Sep 18 10:43 sample.silk
drwxr-xr-x 5 root root 4096 Sep 18 10:26 silk/
drwxr-xr-x 3 root root 4096 Sep 18 10:11 windows/
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder# 
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder# 
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder# sh converter.sh sample.silk mp3
-e [OK] Convert sample.silk To sample.mp3 Finish.
root@alijod:/home/jod/wechat_app/download/silk-v3-decoder# ll
total 68
drwxr-xr-x 5 root root  4096 Sep 18 10:43 ./
drwxr-xr-x 3 root root  4096 Sep 18 10:11 ../
-rw-r--r-- 1 root root  4131 Sep 18 10:11 converter_beta.sh
-rw-r--r-- 1 root root  3639 Sep 18 10:11 converter.sh
drwxr-xr-x 8 root root  4096 Sep 18 10:11 .git/
-rw-r--r-- 1 root root  1076 Sep 18 10:11 LICENSE
-rw-r--r-- 1 root root  3582 Sep 18 10:11 README.md
-rw-r--r-- 1 root root 17709 Sep 18 10:43 sample.mp3
-rw-r----- 1 root root  6188 Sep 18 10:43 sample.silk
drwxr-xr-x 5 root root  4096 Sep 18 10:26 silk/
drwxr-xr-x 3 root root  4096 Sep 18 10:11 windows/

关于converter.sh脚本

vim打开converter.sh脚本,显示一下行号(vim中输入":set nu"后回车,我为小白操心不少),想要简单使用,其实只需要关注最后面这一段,如果想要深入研究,最好是把脚本完整过程搞懂。

 82 $cur_dir/silk/decoder "$1" "$1.pcm" > /dev/null 2>&1
 83 if [ ! -f "$1.pcm" ]; then
 84         ffmpeg -y -i "$1" "${1%.*}.$2" > /dev/null 2>&1 &
 85         ffmpeg_pid=$!
 86         while kill -0 "$ffmpeg_pid"; do sleep 1; done > /dev/null 2>&1
 87         [ -f "${1%.*}.$2" ]&&echo -e "${GREEN}[OK]${RESET} Convert $1 to ${1%.*}.$2 success, ${YELLOW}but not a silk v3 encoded file.${RESET}"&&exit
 88         echo -e "${YELLOW}[Warning]${RESET} Convert $1 false, maybe not a silk v3 encoded file."&&exit
 89 fi
 90 ##ffmpeg -y -f s16le -ar 24000 -ac 1 -i "$1.pcm" "${1%.*}.$2" > /dev/null 2>&1
 91 ffmpeg -y -f s16le -ar 12000 -ac 2 -i "$1.pcm" -f wav -ar 16000 -ac 1 "${1%.*}.$2" > /dev/null 2>&1
 92 ffmpeg_pid=$!
 93 while kill -0 "$ffmpeg_pid"; do sleep 1; done > /dev/null 2>&1
 94 rm "$1.pcm"
 95 [ ! -f "${1%.*}.$2" ]&&echo -e "${YELLOW}[Warning]${RESET} Convert $1 false, maybe ffmpeg no format handler for $2."&&exit
 96 echo -e "${GREEN}[OK]${RESET} Convert $1 To ${1%.*}.$2 Finish."
 97 exit

其实关键的两行也就是Line 82和Line 90。第82行就是调用我们上文编出来的decoder解码silk_v3文件,第90行是将silk_v3文件解码出来的raw data数据转成相应格式。

这里额外说明一下我跟这两行的几个插曲:

插曲一:speex压缩

我做这个SILK语音识别服务的起初目的是让我的“遥知之”支持语音输入功能,“遥知之”上用的OLAMI接口也有语音识别,而且研究了一下他们的JAVA SDK和在线文档,从在线文档(OLAMI 文档中心->语音识别接口文档->“支持的音频格式”)上看是支持wav格式,另外支持speex压缩。

wav格式文件是很占空间的(相当于PCM原始采样数据未经压缩的,加了一个文件头),如下图所示(可能实际speex压缩的效果会更好一点):
pcm,

如果将数据通过speex压缩,就只需要脚本中的第62行,就不用依赖ffmpeg去转码也可以直接省流量上传到OLAMI语音识别服务器了。这里就是为什么我前面说到,ffmpeg并不是此服务搭建中必备之原因。

如果通过speex会大大降低传输效率,于是期间我有花蛮长时间在研究如何将pcm数据转成speex的,比如怎么调用c代码实现的speex的编码(java下通过JNI调用speex的encoder,研究未果,放弃了这个方案),后来又找了jspeex(java版的speex codec)等等,后面因有另一个省事方案,这里用jspeex的方案就中断未深入研究了,其实应该是行的通的。

有人说olami java sdk里默认是将wav或pcm通过speex压缩传输的,这样一来,我只需要将wav或pcm对接olami java sdk就可以实现“省流量”传输到olami语音识别服务器了。这就是我最终采用的省事方案。

插曲二:采样率不适配

发现通过微信小程序端录音出来的silk v3文件,经过kn007的converter.sh转出来的wav文件,再送到olami语音识别接口,发现识别效果很糟,把wav文件拿出来听听,似乎也正常。

这时候想起来脚本中PCM转wav是按24K转的,转出来的WAV应该是24K的,而olami语音识别端支持的是16K(讯飞还支持8K的),可能是这个采样率不一致导致的识别率差,网搜了一下,还真有前人碰到过相同问题,参见此文文中提到的“误打误撞”那一段:从微信中提取语音文件,并转换成文字的全自动化解决方案 ,他的误打误撞的原理应该是小程序录音就是双通道12K的,然后ffmpeg额外指定一下参数将双通道12K的数据流转成16K的wav。

好了,离不开ffmpeg了,需要它帮着转采样率呀,speex压缩又不负责解决采样率转换的问题。
重要的事说三遍:在原始脚本的基础上,修改一下第90行:
重要的事说三遍:在原始脚本的基础上,修改一下第90行:
重要的事说三遍:在原始脚本的基础上,修改一下第90行:

ffmpeg -y -f s16le -ar 12000 -ac 2 -i "$1.pcm" -f wav -ar 16000 -ac 1 "${1%.*}.$2" > /dev/null 2>&1

插曲三:假silk(或mp3)真webm/base64格式

在使用微信小程序开发工具模拟手机做调试时,录音文件不能被silk和ffmpeg转,vim打开一看,头部是“data:audio/webm;base64,”。

由此引伸出一个现象:微信小程序的录音不全是silk v3(或mp3)格式,其中还有刚刚提到的webm/base64的,好像还有AMR格式的,听kn007大神说还有混淆格式,也就是那种一个文件含多种格式混合的,也不知道为什么会有这种情况。

关于webm/base64格式,kn007的回复是,base64 decoder然后直接ffmpeg转,于是我分两步实现:
第一步:用java代码做base64 decoder,再将文件写到 xxx.webm文件中,这部分简单,可参考微信小程序 录音文件格式silk 坑那样做即可。
第二步:再调用ffmpeg命令直接转码成wav,主要是调用一下下述转码命令转成16K的WAV:

ffmpeg -i "$1" -f wav -ar 16000 -ac 1 "${1%.*}.$2" > /dev/null 2>&1

其中调用ffmpeg命令容易出现失败,原因之一可能会是文件读写权限不足,原因之二可能会是调用ffmpeg后,需要等ffmpeg进程消失,即转码任务完成,才退出。 觉得我个人碰到的问题应该是原因之二导致的,因为我确实是将/usr/bin/ffmpeg设置成了777权限,还是会转失败,将调ffmpeg命令的部分在脚本中实现,并且加上kn007大神converter.sh中那样的等待ffmpeg完成的部分,就搞定了。

为了让脚本更通用,我将上述解决采样率不匹配的问题,修改后的脚本基础上,又添加了对webm格式的单独ffmpeg转码支持(通过判断传入第1个参数的后辍是否是webm来判断是不是直接ffmpeg转码然后exit,简单粗暴并且高效!)大概在脚本的上方添加下面这一段:

SOURCE_FILE_SUFFIX=${1##*.}
echo -e "XXXX SOURCE_FILE_SUFFIX:${SOURCE_FILE_SUFFIX}"
if [[ "${SOURCE_FILE_SUFFIX}" == "webm" || "${SOURCE_FILE_SUFFIX}" == "mp3" ]]; then
        ## if webm, ffmpeg it directly. webm/base64 had been base64 decode on api.happycxz.com already.
        ## if mp3, ffmpeg it directly. mp3 do not need to decode, can be convert to wav directly.
        echo -e "begin to ffmpeg $2 from webm now..."
        ##ffmpeg -i "$1" -f wav -ar 16000 -ac 1 "${1%.*}.$2" > ffmpeg.cxz.log 2>&1
        ffmpeg -i "$1" -f wav -ar 16000 -ac 1 "${1%.*}.$2" > /dev/null 2>&1
        ##ffmpeg -i "$1" -f wav "${1%.*}.$2" > /dev/null 2>&1
        ffmpeg_pid=$!
        while kill -0 "$ffmpeg_pid"; do sleep 1; done > /dev/null 2>&1
        [ ! -f "${1%.*}.$2" ]&&echo -e "${YELLOW}[Warning]${RESET} Convert $1 false, maybe ffmpeg no format handler for $2."&&exit
        echo -e "${GREEN}[OK]${RESET} Convert $1 To ${1%.*}.$2 Finish."
        exit
else
        echo -e "begin to silk decoder flow..."
        ## if not webm, follows default silk decoder road.
fi
(注:以上脚本片断在2017.11.09更新了mp3部分支持,因为小程序录音新接口已经支持mp3格式录音,录音文件直接经ffmpeg转wav即可)

至此,converter_cxz.sh修改结束。

搭建web服务及主要代码说明

前面相当于评估可行性,基本验证了从小程序录音文件 xx.silk 到语音识别API能认的数据或文件格式,这条路走通了,接下来就是堆JAVA代码实现细节部分了。

创建sprinMVC工程

大概的工程目录结构如下:
这里写图片描述

com.happycxz.controller中有两个controller:
第1个,AdditionalController.java是用来查服务器状态和在线更新数据用的,可忽略。
第2个,OlamiController.java是对接微信小程序silk文件上传API接口的,代码如下:

代码参考我博客原文(这里不能超过20000字,所以删减掉了)

利用springMVC的注解,很方便的实现API功能,主要看这个asrUploadFile方法,参数包括request和response之外,还有一个Map结构的p,这个p是用来接收formdata的,即上传录音文件时附带的信息。
我这里强制了必须上传appKey、appSecret以及userId,因为我是直接对接的olami开放平台的接口。

大概的流程是(懒的画流程图了,直接看上面代码,很容易看明白的):

  1. 接收p中上传的appKey、appSecret以及userId这三个必选参数
  2. 接收request中的Parts,获取原始silk格式文件及对应的上传文件名
    这里面其实是包括file和formdata的,这里还掉进一个坑过,想着不需要调用“extractFileName”来拿原始文件名,直接收以请求,随机生成一个文件名保存了得了,事实是,通过“extractFileName”拿文件名,当文件名为""或null时,这时候是formdata,不是文件,强制保存成文件肯定就出问题了(调试时发现有些录音文件里只有一个很短的数字字母组成的字符串,就是这个原因)。
  3. 将文件另取个名字保存到服务器指定目录
    为什么要另存文件名:微信小程序上传的录音文件统一是wx-file.silk,不像小程序开发工具上录音那样文件名随机生成。
  4. 这里有个额外判断第3步中保存的xxx.silk是不是webm/base64格式的,如果是,就直接base64 decoder后保存文件 xxx.webm,然后调用converter_cxz.sh将webm格式的文件转码成xxx.wav的,走完流程或异常都跳过下一步,直接到第6步。如果不是webm/base64格式的,返回false,继续走下一步。
  5. 调用silk_v3_decoder中的脚本(这里是上文提到的修改之后的脚本,我给重命名converter_cxz.sh了)转xxx.wav
  6. 通过原来的silk文件全路径,计算出wav文件全路径
  7. 通过上一步得到的wav文件全路径,以及appKey、appSecret以及userId这三个参数,生成一个SdkEntity实体,调用getSpeechResult接口获取语音识别和语义处理的结果
  8. 组织输出结果返回。

com.happycxz.olami中有四个文件:
第1个,AsrAdditionInfo.java是用来检查https请求中formdata必选的三个参数是否都上传了,是否合法。
这里我额外做了个限制,除了在olami平台上申请的appKey和appSecret之外,appKey还要额外告知我,我在支持列表中加上才可以用,避免被攻击了大家都没法用,没办法,小窝带宽有限。

第2个,OlamiEntityFactory.java是做一个SdkEntity的缓存,如果formdata中上传的userId不一样,这个缓存就没用了:(

第3个,OlamiKeyManager.java是配合第一个文件做appKey限制管理的。

第4个,SdkEntity.java是对接olami接口的部分,主要是从olami java sdk sample代码中拷出来改改的。代码参考我博客原文(这里不能超过20000字,所以删减掉了)

com.happycxz.olami中有两个文件,是使用到的一些util、读配置文件、系统日志等部分。

另外WEB-INFO/lib中加载olami的java sdk,如图:
这里写图片描述

另外,额外附上一张olami-java-client-1.0.1-source.jar中关于默认采用speex压缩的源码部分:
这里写图片描述

怎么用

老接口(录音为silk格式的,通过wx.startRecord录音的)调用:https://api.happycxz.com/wxapp/silk2asr

新接口(录音为mp3格式的,通过wx.getRecorderManager录音的)调用:https://api.happycxz.com/wxapp/mp32asr
(注:如果调用新接口,要求小程序端录音配置成:sampleRate: 16000, numberOfChannels: 1, encodeBitRate: 48000, format: 'mp3')

formdata必选参数(以上两个接口均适用): 参数 是否必选 说明
appKey 从olami.cn上申请的key
appSecret 从olami.cn上申请的secret
userId 用户的唯一标识,比如手机号,或唯一性的ID,或IMEI号之类的

返回数据res.data就是olami开放平台返回结果完全一致,未经修改,具体参考他们在线文档:
olami开放平台的API接口返回数据格式

大概的是 seg字段是语音识别分段结果,asr是语音识别结果,nli是语义或语义处理的结果。小程序的开发工具上没法DEBUG,就没办法截一段例子说明了。

调用案例:“遥知之”智能小秘

小程序码小
欢迎扫码试用。这一版支持语音识别,博客还没来得及更新,稍后我会把相关代码在这个文章“我的微信小程序支持语音识别啦!“遥知之”不再装聋”中分享出来,主要是分享一下微信小程序里如何上传SILK录音部分以及如何解析olami返回的语音识别和语义处理结果的代码。

最后闲话

本文欢迎转载

服务端工程的代码分享:
本文所有源码对应码云链接:https://gitee.com/happycxz/silk2asr
本文所有源码对应github链接:https://github.com/happycxz/silk2asr

如果有不明白的都可以在本博客文章后面留言,也欢迎大家指正文中的理解或文字描述错误或不清楚的部分,我将及时更正,避免带人跳坑。

需要用这个接口的,appKey可以在我的个人博客留言或私信告诉我,我加进我的白名单你才可以用。

点击查看更多内容
5人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
JAVA开发工程师
手记
粉丝
8
获赞与收藏
43

关注作者,订阅最新文章

阅读免费教程

感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消