赞
踩
因为前阵子,有需求要将语音转为文本再进行下一步操作。感觉这个技术也不算是什么新需求,但是一搜,都是大厂的api,或者是什么什么软件,由于想要免费的,同时也要嵌入在代码中,所以这些都不能用。、
一筹莫展的时候,突然搜到whisper,这是个openai开源的工具,主打就是语音转文本。试了一下,还是不错的,虽然搜到的大多数介绍都是关于怎么直接命令行使用的,但是也有少量关于api的介绍,结合源码看了一下,还是很容易操作的。
这个项目,从安装开始,这个项目可能是太有名了还是啥,有很些大神进行了扩展和优化,所以直接pip安装的话,需要注意是pip install openai-whisper,直接装whisper不是那个哟。git地址openai-whisperhttps://github.com/openai/whisper使用上,在代码中,import之后,whisper.load_model,传入模型名就可以了,不传的话,默认是small,个人觉得已经挺好的了,会自动下载,自动下载的权重是pt格式的,如果去hf下载的话,好像是bin格式,需要注意。模型名可以在源码中看到,或者是git上好像也有。顺便一提,由于hf需要科技,但是源码中的链接不是hf上的,下载速度还可以。
使用的时候model.transcribe再传入音频文件就可以了。是的,这个项目本身是不支持实时转录的,并且,传入的文件,他是通过ffmpeg来进行处理的,所以使用前需要安装ffmpeg。在使用transcribe方法的时候,还能追加一些参数,比如language,中文传zh或Chinese,如果不传,会自动检测音频前面一部分的主要语言,并且输出该语言。
需要注意的是,这个项目不支持多语言输出,注意,是输出,比如设定为中文,则无论输入音频是啥语言,输出都是中文,但中文是不是翻译的不太确认。这边试过英文,输入一段中文录音,结果输出是全英文,并且翻译后的英文,不是同音乱码啥的。其他参数建议就默认就行了。比如,如果torch检测到cuda可以用,就会自动切换cuda,并且量化fp16,如果是纯cpu,则fp16会报一个提示不可用,自动设为false。如果本机有显卡,但是加载显存不够而需要转cpu的话,则是在load_model方法设置device,但是即便是最大的模型,12G显存应该也是够用的,没仔细看。
这个项目有一些不足,第一,输入空白音频或者特别短的音频的时候,输出的文字是不对的,但是他有个参数名为no_speech_prob,顾名思义就是无人说话的概率;第二,接上一条,no_speech_prob这个值不太准,所以通过这个值进行过滤的时候,有可能会漏掉内容;第三,再接上一条,还是no_speech_prob这个值,这边测试,用小说软件读小说,基本上都认定无人说话,所以这个值莫非是检测是否是真人么,但对于真人录音,同样存在该值变动较大且不准的情况,即对于我的一段录音,总是会漏掉一些内容;第四,输出中文是繁体,有需要的简体的话,要再用zhconv转一下,zhconv.convert(text,'zh-cn');第五,速度快,但还不够快。
由whisper的速度,引发了下一个项目,不够快,经过一番查找,下面这个项目还是不错的
faster-whisperhttps://github.com/guillaumekln/faster-whisperFasterWhsiperGUI 更快更强更好用的 whisper - 哔哩哔哩 (bilibili.com)
这个链接写了一些对于whisper的一些评价,顺便推广了他自己的项目,他的项目似乎就是对faster这个的包装,弄了一个界面。所以我就直接使用faster了。
直接说结论,速度确实提升很大,不过宣称的4倍提升倒是没有测出来,但是两倍提升还是有的。其模型不能和原版模型共用,下载的话,需要去hf下,不过他也提供了将原版模型转为自己可用的模型,但是原版模型也要是hf的版本,所以科技还是少不了。
该项目的主要提升是速度提升很大,但是准确率没下降很多,但是这边测着,略有下降吧,不知道是不是个体差异,非专业和大量测试。
这两个whisper项目,优点是速度快,准确度还不错,缺点是幻听问题和返回是纯文本,没有标点的话,对于短文本还好,如果语句较长,歧义的风险比较大,不过他们都有返回时间戳,自己判断一下,在间隔较大的地方加个逗号也算满足要求。
但是由于我需要做的是语音ai对话,这样的话,如果输入文字有错误的话,ai的回复可能就会很莫名其妙,所以我需要找一个准确度更高的项目,此时强烈推荐funASR项目,由阿里达摩院开源。
funASRhttps://github.com/alibaba-damo-academy/FunASR这个项目有点大,功能有点多,不过教程也是非常多的,简要说明一下,该项目支持三种模式,2pass:实时转录,并且会回头检测输出的文本,自动进行修改和标点添加;online:似乎是实时转录但是不会回头检测,没用过;offline:对全音频检测,就是输出2pass的最终结果,中间过程不输出。后面我用的全都offline模式,简单说一下其中的坑,最关键的是,从项目介绍来看,至少目前还不支持gpu,虽然用的时候好像显存有增加,但是他自己说gpu版还在进行中。
首先,我是git下载源文件再安装的,因为如果pip下载的话,我不知道源文件在哪,而他的快速使用教程里面,需要找到源文件,再去某个目录下,开启服务端,再通过客户端请求转录文本,虽然有点麻烦,但是准确率比前面的高,并且,他自己介绍说,一般的硬件水平下也能支持百路并发,还是比较心动的,毕竟whisper的话,岂不是要我自己写flask来回应请求,效率不敢想。
此时发现,他的python服务端,只能支持一路,要多路并行,需要编译,不知道win能不能编译,反正教程是只写了linux怎么编。
再python环境下,同一段1分多几秒的音频,whisper需要10s左右,large模型,faster需要4s左右,也是large模型,但是内容有缺漏,换成small模型,只需要3s不到,内容反而不缺漏了。funasr用了33s,调用的是源文件中提供的api代码,里面有一些等待参数,都设为非常小的值了,0.0001什么的,这才到33s,如果设大一些,等待更久。查看api代码可知,他的请求方式是将音频循环读取chunk并发给服务端,服务端此时会返回识别内容,所以随着循环的进行,返回的内容会越来越多,越来越准,可以理解2pass模式是怎么工作的了。然后在最后关闭这个连接,此时会发来一个最终结果,这个就是offline的结果。不太能理解为什么不能一次输入全文件,然后直接得到结果。但是问题在于,在调用api的时候,发现,他最终结果经常发来一个空,反而是循环体中返回的内容是可用和正确的。感觉还是主打2pass,至少这个api文件是这样,如果设置为2pass模式的话,能看到每一步的返回,还有内容的修改,挺有意思的,大概是流式输出的意思。
总结,funasr,准确率高,有标点,但是慢,极慢。
事情还没完,在使用funasr之后,既眼馋他的准确,又遗憾他的速度,难道就不能两全么,原本我的目标是放在c++编译上,大不了编译出来一个,按说python转成c++之后,十倍提升应该不是问题才对。
此时仔细研究了下源码文件,发现之前使用的是runtime下的python目录的websocket,而python目录下还有onnx和libtorch,从目录名来看,这个项目貌似支持很多语言,然后仅就python而言,也有多种实现方式。
这边试了下libtorch,其每个文件夹下都有一个readme和demo,比较详细的介绍了怎么用,比如如何安装 torch版,然后怎么转换模型,因为直接下载的模型是pb格式,他需要转成torchscript格式,这一步卡了我好就,因为没有关注到这一点,一直以为是我下载的模型不对,而在modelscope中搜索半天,找不到之后,都准备提issue了,然后再一次看readme的时候,发现开头就写了要装onnx来转一下权重。而且不知道是不是路径问题,转换的时候会重新下载权重到当前目录下然后再转,所以可以提前把默认路径下的权重拷贝到当前目录。
demo中,关于model的加载,有一条是注释了gpu的,但是使用的话,无论传什么音频进去都提示“input wav is silence or noise”,不信邪的我再查看源码,发现这句打印只是在except中,打开注释掉的traceback.format_exc(),会打印真实原因,说是two device,看报错似乎不是我可以解决的,于是还是改为cpu版,此时速度只需要3s左右,准确率很好,但是没有了标点,只有一大段文字。然后下载官方长音频版权重,带vad和punc,输出还是没有标点,最后根据每个字的时间戳,遍历了一遍,总耗时达到4s,再改,用gevent,只需要分析相邻两字的时间即可,此时总耗时大概是3s,行吧,不想折腾了。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。