可以说音频相关的东西是语音云使用当中最突出的问题，也是用户问题里面出现频率最高的，我们在这里面花一点时间介绍它。首先它支持的音频格式只支持因特尔PCM的音频包括8开和16开的，其余的音频格式由于在压缩上没有非常好的解决方案，要事前进行转码这个效率不是很高，不是很明显，所以现在的引擎暂时只支持PCM，后面有可能支持其他格式。这个选择压缩算法涵盖了SPEEX和AMR，另外就是压缩等级可选的问题，Speex提供的等级有0到11个，马力范围跨度也是非常大的。面对这些压缩的音频，有的时候用户就讲，我可以调用我自己系统的一些接口，以更有效的方式获取压缩音频，这个时候我能不能直接传进呢？换句话说用户此时写入MC的不是写好的音频，而是已经压缩好的音频，只不过传的时候对音频的压缩常识性东西要有了解。首先是里面帧的问题，压缩帧这个压缩等级是可变的，就是说一个压缩帧的长度是可变的，是不定的。

面对这么大的压缩算法，我们应该选择哪一个，面对这么多的压缩等级又该选择哪一个，根据我们实际的测试结果这个压缩率在10到15的时候压缩率比较好，第二个就是Speex和AMR应该有限选择Speex，因为Speex算法还是比较高的。

我们整个语音云平台整体上来说是参数驱动的，所以设置正确的参数直接就关系到你是否能够成功获取到云与云的服务，在合成里面有两种引擎，一个是属于INTP一个是VIVI，详细可以看我们的稳当。音频格式就是16开的音频格式，因为这个16开音频播出来声音非常清楚。

对于识别和听写来说，你是进行从语音到文字的转换，还是希望在子基础上做搜索，都是ENT这样一个参数指出来的。下面音频编辑码算法这个也是非常重要。还有就是这里写入压缩好的音频的时候，写进去要包含若干个完整的数据帧，如果不小心把一帧从中间截断了，就失去同步了，尽管从概率上过一段时间可以恢复同步，但是对你当前的应用来说是一大损失。后面比较关心是识别结果的格式。

几个主要策略：为了做到快速相应，使处理比较有效和及时，所以我们的音频上面采用了边接受音频，边压缩，边发送，然后再检查，再解析消息，所以这个过程是一步处理的，用户调用结果的时候不会有任何的阻塞的行为。

针对上面的边发送和接受，下面就是在获取结果的时候，每一次调用一般讲话的过程中，如果采用这个方式很快就可以知道当前业务出现问题了，这种两个接口混掉的方式，始终是识别里面最核心的问题，就是用这个接口的难点所在。

开发中常见的问题：刚才提到属于音频的问题，对于合成来讲，很多用户说我拿到这个音频怎么放，不知道怎么放，通用的播放器放不出来，原因就是合成的音频是没有音频头的，音频需要用户自己去写，怎么去写，这个在网上随便搜索一下就可以知道了，他是该写那些数据了，有44个字节，也有50多个字节的，如果用COOL EDIT等软件手动选择音频参数来播放。

第二个就是能获取到语音听写结果但是不全，要解决这个问题主要是在调用QISRAudiowrite时没有正确设置参数audiostatus所致，此参数在写入非最后一个音频数据快时需要进行识别。我今天就讲到这儿。谢谢大家！

【 0条 】 分享按钮