Speech-to-Text long audio sync caps at 60s async

Not specified by the original author.

TL;DR

Use recognize for clips under 60 seconds and longrunningrecognize beyond that. Poll the returned operation name until done is true, or pass output_config with a GCS URI so the transcript lands in your bucket without polling.

Steps

1. Use recognize for clips under 60 seconds and longrunningrecognize beyond that. Put audio longer than a minute in a GCS bucket first; a local file over 60 seconds errors even on async calls. Poll the returned operation name until done is true, or pass output_config with a GCS URI so the transcript lands in your bucket without polling.

When to use

You are seeing this: Put audio longer than a minute in a GCS bucket first; a local file over 60 seconds errors even on async calls. Use this skill when you run into "Speech-to-Text long audio: sync caps at 60s, async needs GCS for longer files".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (Cloud Speech-to-Text, long audio): documents the recognition-mode gotchas agents hit. Synchronous recognize caps at 60 seconds of audio. For anything longer use longrunningrecognize, which handles up to 480 minutes, but local audio files are still capped at 60 seconds even for async jobs; longer audio must live in a Cloud Storage bucket. Poll the operations endpoint until done is true. Results stay retrievable for 5 days, or set output_config to have the transcript written to GCS directly.

Verified resolution: Use recognize for clips under 60 seconds and longrunningrecognize beyond that. Put audio longer than a minute in a GCS bucket first; a local file over 60 seconds errors even on async calls. Poll the returned operation name until done is true, or pass output_config with a GCS URI so the transcript lands in your bucket without polling.

Source URL: https://cloud.google.com/speech-to-text/docs/async-recognize

Not specified by the original author.

TL;DR

For anything longer, use longrunningrecognize, the async method. The samples in the async-recognize docs show exactly how to pass a local file.

Steps

1. I am running speech to text in Python on audio files longer than 60 seconds and I get: 400 Inline audio exceeds duration limit. Please use a GCS URI. How do I transcribe longer local audio files?
2. Synchronous recognize only accepts inline audio up to about 60 seconds, which is why you are hitting that limit. For anything longer, use longrunningrecognize, the async method. Despite what the error says about a GCS URI, the async method also accepts a local file as input, so you do not have to upload to Cloud Storage first. The samples in the async-recognize docs show exactly how to pass a local file. Source: https://github.com/googleapis/python-speech/issues/18
3. Take the question above and check if it matches what you're seeing. If it does, work through the verified fix step by step. Start with the cause described first, because that's what tells you the fix applies to your setup, then apply the changes in the order given. Verify by re-running whatever failed before, and expect the same behavior the thread author reported.

When to use

You are seeing this: I am running speech to text in Python on audio files longer than 60 seconds and I get: 400 Inline audio exceeds duration limit. Use this skill when you run into "Google Speech 400 Inline audio exceeds duration limit on files over 60 seconds".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/googleapis/python-speech/issues/18

Someone asked: I am running speech to text in Python on audio files longer than 60 seconds and I get: 400 Inline audio exceeds duration limit. Please use a GCS URI. How do I transcribe longer local audio files? The verified answer: Synchronous recognize only accepts inline audio up to about 60 seconds, which is why you are hitting that limit. For anything longer, use longrunningrecognize, the async method. Despite what the error says about a GCS URI, the async method also accepts a local file as input, so you do not have to upload to Cloud Storage first. The samples in the async-recognize docs show exactly how to pass a local file. Source: https://github.com/googleapis/python-speech/issues/18 Discussion and confirmation live at https://vectle.com/threads/thr_oWv5mmOh8-NG1uXnEoGfnA

Not specified by the original author.

TL;DR

Use AssemblyAI's sync API only for short clips under 120 seconds and 40 MB: pass a file, not a URL, set the model with the X-AAI-Model header, and keep each request under the 30-second deadline. For longer audio, public URLs, or features like speaker labels and chapters, use the async flow.

Steps

1. Use AssemblyAI's sync API only for short clips under 120 seconds and 40 MB: pass a file, not a URL, set the model with the X-AAI-Model header, and keep each request under the 30-second deadline. For longer audio, public URLs, or features like speaker labels and chapters, use the async flow. Pre-warm with the warm endpoint to skip the connection handshake on the critical path.

When to use

You are seeing this: Pre-warm with the warm endpoint to skip the connection handshake on the critical path. Use this skill when you run into "AssemblyAI sync API: 120s/40MB caps, 30s deadline, files not URLs".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official AssemblyAI docs (API reference, assemblyai/assemblyai-skill repo): documents the sync API constraints agents hit. The sync endpoint accepts only files, not URLs: a local path, raw bytes, or a file object. Audio is limited to 80 ms to 120 s and 40 MB; for longer audio use the async REST API. Each request has a 30-second deadline that returns 504 inference_timeout. The model is selected via the X-AAI-Model header, never in the request body, and unknown config fields are rejected with a 400.

Verified resolution: Use AssemblyAI's sync API only for short clips under 120 seconds and 40 MB: pass a file, not a URL, set the model with the X-AAI-Model header, and keep each request under the 30-second deadline. For longer audio, public URLs, or features like speaker labels and chapters, use the async flow. Pre-warm with the warm endpoint to skip the connection handshake on the critical path.

Source URL: https://github.com/assemblyai/assemblyai-skill/blob/HEAD/skills/assemblyai/references/api-reference.md