|
我正在使用REST API与cURL,因为我需要做一些快速而简单的事情,而且我在一个盒子里,我无法开始倾倒垃圾;即一些厚的开发人员SDK.
我开始使用base64编码flac文件并启动speech.syncrecognize.
最终失败了：
{
"error": {
"code": 400,"message": "Request payload size exceeds the limit: 10485760.","status": "INVALID_ARGUMENT"
}
}
好的,你不能在请求中发送31,284,578字节;必须使用云存储.所以,我上传了flac音频文件,然后再使用云存储中的文件重试.那失败了：
{
"error": {
"code": 400,"message": "For audio inputs longer than 1 min,use the 'AsyncRecognize' method.","status": "INVALID_ARGUMENT"
}
}
很棒,speech.syncrecognize不喜欢内容大小;再次尝试使用speech.asyncrecognize.那失败了：
{
"error": {
"code": 400,please use LINEAR16 encoding.",所以speech.asyncrecognize只能做LPCM;以pcm_s16le格式上传文件,然后重试.最后,我得到了一个汉德尔的操作：
{
"name": "9174269756763138681"
}
继续检查,最终完成：
{
"name": "9174269756763138681","done": true,"response": {
"@type": "type.googleapis.com/google.cloud.speech.v1beta1.AsyncRecognizeResponse"
}
}
所以等待,结果现在坐在队列中,没有REST方法来请求结果？有人请告诉我,我已经错过了明显盯着我的人,并且Google没有创建完全没有意义,不完整的REST API.
解决方法
所以这个问题的答案是,不,有可能使用curl来使用Google Cloud Speech API来识别10到15分钟的文件……假设你导航并遵守一套相当紧凑的约束……至少在beta1.
从文档中看不出明显的结果是,应该通过operations.get方法返回结果……如果我的任何尝试实际上返回了除空结果之外的其他内容,那将是显而易见的.
我的文件中的源速率是44,100或48,000 Hz,我将sample_rate设置为源本机速率.但是,与文件相反：
Sample rate in Hertz of the audio data sent in all RecognitionAudio
messages. Valid values are: 8000-48000. 16000 is optimal. For best
results,set the sampling rate of the audio source to 16000 Hz. If
that’s not possible,use the native sample rate of the audio source
(instead of re-sampling).
在重新采样到16,000 Hz后,我开始通过operations.get获得结果.
我认为值得注意的是,相关性并不意味着因果关系.重新采样到16,文件变得非常小.因此,我无法证明它是一个采样率问题,而不仅仅是对超过一定大小的文件的服务阻塞.
值得注意的是,文档中的采样率不一致.似乎gRPC API可能期望sample_rate,并且REST API可能期望sampleRate,根据它们各自的详细定义,在这种情况下,Quickstart可能给出了REST API的错误示例.
（编辑：济南站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
