休息 – 是否无法使用curl来使用Google Cloud Speech API识别10
我正在使用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" } 解决方法
所以这个问题的答案是,不,有可能使用curl来使用Google Cloud Speech API来识别10到15分钟的文件……假设你导航并遵守一套相当紧凑的约束……至少在beta1.
从文档中看不出明显的结果是,应该通过operations.get方法返回结果……如果我的任何尝试实际上返回了除空结果之外的其他内容,那将是显而易见的. 我的文件中的源速率是44,100或48,000 Hz,我将sample_rate设置为源本机速率.但是,与文件相反:
在重新采样到16,000 Hz后,我开始通过operations.get获得结果. 我认为值得注意的是,相关性并不意味着因果关系.重新采样到16,文件变得非常小.因此,我无法证明它是一个采样率问题,而不仅仅是对超过一定大小的文件的服务阻塞. 值得注意的是,文档中的采样率不一致.似乎gRPC API可能期望sample_rate,并且REST API可能期望sampleRate,根据它们各自的详细定义,在这种情况下,Quickstart可能给出了REST API的错误示例. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |