回复钱塘独钓：

抱歉，我再提醒一下pm

回复nickms：

我发送邮件给voice_feedback@baidu.com已经很长时间了，没有看到任何回复！我的邮箱是:mark.liu@hitinga.com

回复钱塘独钓：

不好意思，这个体验页只是初步的方案，还需要一些工作，暂且不开放。

回复nickms：

最近两天反复体验了，http://yuyin.baidu.com/#try的效果，经过一些分析，看得出，这个体验页面，就是采用的分段传输，已经完全满足识别的要求。这个是否可以开放？

回复nickms：

已经发送了邮件，谢谢支持。

回复钱塘独钓：

您好，需要您发封邮件到voice_feedback@baidu.com，

并在邮件中描述清楚 需求 使用场景 预期调用量等详细信息。

回复钱塘独钓：

新年好，已转。

回复nickms：

新年好，我的邮箱为mark.liu@hitinga.com，非常感谢介绍贵司的PM和我这里取得联系。

回复钱塘独钓：

您好，现在SDK重点主要是在android、ios平台，如果您那块确实对MIPS和ARM的嵌入式平台需求很大，我可以将您的需求转给我们的PM

回复nickms：如果REST-API的升级比较晚一些，是否有针对MIPS和ARM 的嵌入式SDK能够提供？

回复钱塘独钓：

回复nickms：

同样的，感谢团队能够如此认真的回复开发者提出的要求，预祝百度语音能够越来越强大。

要到17年度年中才能够完成升级，真心希望能够在一季度看到团队的升级更新，从技术层面来说，这个功能单方面升级的时间点应该是可控的，我想团队可能是由于整体规划和升级的需要更长的时间。

我们团队，从事过一段时间的ALAEX的开发适配，其采用的分片精度要求为10ms精度，效率确实比较高。当然其架构在H2上，采用了SSL也增加了一些开销，实际上这类开销在这个应用上安全是不敏感的，因为敏感的是业务，而不是语音通道。

因此，我从终端的角度，提一点个人的建议：能够升级至SDK的模式，提高分片精度到20ms，识别效率应该就会非常通畅。

回复钱塘独钓：

您好，感谢您能够如此关注语音识别功能，确实正如您所说，当前的restapi提供的接口相对sdk要简单一些，但也可以让开发者快速的入门、使用语音识别服务，感受到语音识别服务的价值。

而您所提的问题直戳痛点，我们已对这块工作进行排期，希望能够在17年年中之前为大家带来restapi服务的升级。

语音识别服务有很多工作仍需要去完成，我们会不断前行，再次谢谢您对百度语音的支持。

回复nickms：

感谢团队的快速回复，期待通过REST-API的方式能够贵司内部开发出来，对于一些资源有限的小系统，就有可能自主的集成语音语义功能了。

对于第二个问题，我问题可能没有描述清楚：

针对SDK部分，在请求语音识别的时候，是分段上传的，这样在设备端可以做到边录制边上传。我的理解他应该有：开始识别，传输数据->传输数据.......->传输数据，结束传输。由于我本人在multipart的上有一些应用，我看到SDK部分，应用也是采用了multipart功能。

在使用REST-API的方式，上传语音也是采用multipart功能，但是只能一次将语音传输完毕，等待结果；而不能如SDK一样，进行边录制变传输边识别的过程。这样导致了，设备端做语音识别的效率比较低，用户体验不高，难以商用。

综述，希望REST-API能够提供类似于SDK的功能，实际上也只是将REST-API开放到SDK识别的功能即可。提高产品的实用性。

感谢团队的快速回复，期待通过REST-API的方式能够贵司内部开发出来，对于一些资源有限的小系统，就有可能自主的集成语音语义功能了。

对于第二个问题，我问题可能没有描述清楚：

针对SDK部分，在请求语音识别的时候，是分段上传的，这样在设备端可以做到边录制边上传。我的理解他应该有：开始识别，传输数据->传输数据.......->传输数据，结束传输。由于我本人在multipart的上有一些应用，我看到SDK部分，应用也是采用了multipart功能。

在使用REST-API的方式，上传语音也是采用multipart功能，但是只能一次将语音传输完毕，等待结果；而不能如SDK一样，进行边录制变传输边识别的过程。这样导致了，设备端做语音识别的效率比较低，用户体验不高，难以商用。

综述，希望REST-API能够提供类似于SDK的功能，实际上也只是将REST-API开放到SDK识别的功能即可。提高产品的实用性。

回复钱塘独钓：

您好，首先感谢您的宝贵意见，

1.restapi支持语义的方案现在正在内部进行评估；

2.当前方案中，restapi返回结果的方式会与sdk保持一致。