Web端语音输入探究
为了帮助用户更方便的输入问题，更快得到答案，我们产品正计划推出语音输入的功能。
目前web端的语音输入大多数通过调用Chrome的语音输入API来实现，你只需在input标签中添加x-webkit-speech属性即可。当然也可以添加其他属性，比如lang(语言种类)、onwebkitspeechchange(语音输入事件)、x-webkit-grammar(语音输入语法)等。该方法简单易用，识别率也不错，但可惜仅在Chrome 11以上版本中支持。淘宝，网购，易迅等大多采用这种方法来增强Chrome下的搜索体验。
另一种方案是调用HTML5的Web Speech API来实现，该API提供了很多方法和事件，方便开发者实现更复杂的语音输入功能。Google首页的语音搜索功能就是基于此API实现的。另外Google还提供了一个demo，来演示Web Speech API，试用下你会发现，体验比通过x-webkit-speech实现的好得多。可惜并非W3C标准的API，而仅在Chrome 25以上版本中得到支持。
由于我们的产品依托于游戏内嵌的浏览器，或ie的兼容模式，或webkit内核，而非Chrome，因此以上两种方案都不可用。经过一番调研，最终确定使用wami-recorder作为录音前端，而后端则使用已经相当成熟的微信语音识别技术。
wami-recorder是一个基于JavaScript和Flash的浏览器端录音解决方案，我们可以利用它来收集用户的录音并post到后台生成录音文件，然后传到微信的语音识别server获取识别结果，最后将结果返回给用户。一个语音输入的过程大抵如此，逻辑相当简单，但要做好用户的使用体验，却不太容易。比如用户想“说完话后能自动转换成文字，不需要其他操作“。要达到这个要求，我们必须要先知道用户何时说完话，然后才能提交到后台去做识别。但wami-recorder并没有提供这样的接口，能用得上的只有Wami.getRecordingLevel()这个方法。也就是说，我们只能通过不断监听录音音量，来判断用户是否已经说完了。那么按照经验，“自动完成录音”逻辑大致是这样设计的：
1、用户点击“开始录音“，启动录音程序开始监听，音量为0；
2、音量骤升，大于0，表示用户已开始说话；
3、音量骤降至为0，录音结束，提交录音。
但实际上会发现，上述只是一种理想的情况，录音音量极容易受到环境影响，而且如果麦克风设置的音量较大或开启了增强效果会更明显。那么就不能单纯地把音量0当成开始和结束的标志了，而应该是当前环境的音量；音量升高也不能认为是用户开始说话，有可能是拿耳机发出的声响或是周围环境音量发生的变化，应该在音量大幅升高的时候才可以认为是用户开始说话了；另外，音量骤降，也不一定是话说完了，而有可能是说话变小声或停顿了。总之，诸如此类的情况有很多，单纯根据音量无法完全解决，而且像降噪、去除杂音之类的问题交由后端语音识别程序解决就可以了。前端要做的，就是尽可能过滤掉无效的音频，把有效合法的传到后端去；同时保证用户的使用体验，支持不同音量的麦克风，说完话要尽块得到识别结果，而且要允许有小小的停顿等等。综上所述，改良后逻辑如下：
1、用户点“开始录音”进入录音界面，录音程序开始并监听音量，将获取到第一个音量设为起始音量；
2、若起始音量为0，说明麦克风音量较小，当音量升高至大于0时即认为用户已说话；若起始音量大于0，说明麦克风音量较大，当音量大于10即认为用户已说话(这里取10而没有取起始音量是为了避免起始音量过大的影响)；
3、若用户没有说话，5秒后自动结束录音并退出录音界面，避免提交无效音频及影响用户使用；
4、若用户已说话，且距离上次说话时间超过1秒，即认为说话完毕，程序结束录音并提交到后台识别；
5、若用户已说话，且持续了5秒，为了保证音频大小不超过限制，同时保证响应速度，程序结束录音并提交到后台识别。
PS:上面的相关数值纯属个人偏好，无科学依据。
总的来说，改良后的逻辑比原来完善不少，但也还是有很多缺陷的，毕竟现实情况太复杂了，而且wami-recorder提供的接口又相当有限。长远来看，若Web Speech API能得到广泛支持，应该是个更好的解决方案。
由于某些原因，暂不提供demo~
目前web端的语音输入大多数通过调用Chrome的语音输入API来实现，你只需在input标签中添加x-webkit-speech属性即可。当然也可以添加其他属性，比如lang(语言种类)、onwebkitspeechchange(语音输入事件)、x-webkit-grammar(语音输入语法)等。该方法简单易用，识别率也不错，但可惜仅在Chrome 11以上版本中支持。淘宝，网购，易迅等大多采用这种方法来增强Chrome下的搜索体验。
另一种方案是调用HTML5的Web Speech API来实现，该API提供了很多方法和事件，方便开发者实现更复杂的语音输入功能。Google首页的语音搜索功能就是基于此API实现的。另外Google还提供了一个demo，来演示Web Speech API，试用下你会发现，体验比通过x-webkit-speech实现的好得多。可惜并非W3C标准的API，而仅在Chrome 25以上版本中得到支持。
由于我们的产品依托于游戏内嵌的浏览器，或ie的兼容模式，或webkit内核，而非Chrome，因此以上两种方案都不可用。经过一番调研，最终确定使用wami-recorder作为录音前端，而后端则使用已经相当成熟的微信语音识别技术。
wami-recorder是一个基于JavaScript和Flash的浏览器端录音解决方案，我们可以利用它来收集用户的录音并post到后台生成录音文件，然后传到微信的语音识别server获取识别结果，最后将结果返回给用户。一个语音输入的过程大抵如此，逻辑相当简单，但要做好用户的使用体验，却不太容易。比如用户想“说完话后能自动转换成文字，不需要其他操作“。要达到这个要求，我们必须要先知道用户何时说完话，然后才能提交到后台去做识别。但wami-recorder并没有提供这样的接口，能用得上的只有Wami.getRecordingLevel()这个方法。也就是说，我们只能通过不断监听录音音量，来判断用户是否已经说完了。那么按照经验，“自动完成录音”逻辑大致是这样设计的：
1、用户点击“开始录音“，启动录音程序开始监听，音量为0；
2、音量骤升，大于0，表示用户已开始说话；
3、音量骤降至为0，录音结束，提交录音。
但实际上会发现，上述只是一种理想的情况，录音音量极容易受到环境影响，而且如果麦克风设置的音量较大或开启了增强效果会更明显。那么就不能单纯地把音量0当成开始和结束的标志了，而应该是当前环境的音量；音量升高也不能认为是用户开始说话，有可能是拿耳机发出的声响或是周围环境音量发生的变化，应该在音量大幅升高的时候才可以认为是用户开始说话了；另外，音量骤降，也不一定是话说完了，而有可能是说话变小声或停顿了。总之，诸如此类的情况有很多，单纯根据音量无法完全解决，而且像降噪、去除杂音之类的问题交由后端语音识别程序解决就可以了。前端要做的，就是尽可能过滤掉无效的音频，把有效合法的传到后端去；同时保证用户的使用体验，支持不同音量的麦克风，说完话要尽块得到识别结果，而且要允许有小小的停顿等等。综上所述，改良后逻辑如下：
1、用户点“开始录音”进入录音界面，录音程序开始并监听音量，将获取到第一个音量设为起始音量；
2、若起始音量为0，说明麦克风音量较小，当音量升高至大于0时即认为用户已说话；若起始音量大于0，说明麦克风音量较大，当音量大于10即认为用户已说话(这里取10而没有取起始音量是为了避免起始音量过大的影响)；
3、若用户没有说话，5秒后自动结束录音并退出录音界面，避免提交无效音频及影响用户使用；
4、若用户已说话，且距离上次说话时间超过1秒，即认为说话完毕，程序结束录音并提交到后台识别；
5、若用户已说话，且持续了5秒，为了保证音频大小不超过限制，同时保证响应速度，程序结束录音并提交到后台识别。
PS:上面的相关数值纯属个人偏好，无科学依据。
总的来说，改良后的逻辑比原来完善不少，但也还是有很多缺陷的，毕竟现实情况太复杂了，而且wami-recorder提供的接口又相当有限。长远来看，若Web Speech API能得到广泛支持，应该是个更好的解决方案。
由于某些原因，暂不提供demo~
还没人转发这篇日记
