Transcribe long audio: the limits platforms actually enforce

Long audio hits four caps before it hits a price. The caps are the size of one request, the time one request may span, the life of a streaming session, and the tokens a model may return. This page states each provider's numbers as read on 2026-10-28. It then answers the 30-minute speed question with machine math, not a typist ratio.

The four caps fail in four different ways. Two announce themselves loudly with an error code. Two fail quietly, and a quiet failure on a three-hour deposition is the expensive kind. This page names the failure mode next to every number, because that is what you actually debug at midnight. Rates for this platform's own lane never appear as typed numbers here. They render from the platform's model data in the fence further down.

How long 30 minutes of audio takes: the machine answer

Start with the correction, because the question is real and the ranking pages answer a different one. Search for how long it takes to transcribe 30 minutes of audio and the head results time a person. Typist guides land at roughly four hours of work per hour of audio, so 30 minutes of audio costs about two hours of typing. One veteran service puts its range at two to three hours per audio hour. Those numbers are honest for humans. They are the wrong unit for a machine.

The machine unit is real-time factor, written RTF. It is processing seconds divided by audio seconds. An RTF of 0.5 means one hour of audio takes about 30 minutes of processing. An RTF under 1.0 means the machine outruns the recording. The ratio is all that matters for planning. It is the number no typist-ratio page prints.

The platform's Japanese-first speech lane (hayamimi) carries a measured RTF pin of about 0.39, taken 2026-08-29 on a 20.32-second clean English clip. The whisper lane has no published RTF pin yet. The clip ran about 8.0 seconds from audio start to the last final transcript. Run the arithmetic. Thirty minutes of audio at 0.39 is 30 x 0.39. That is about 11.7 minutes of processing, serially, on one request stream. A full hour is about 23.4 minutes. That is the machine answer. It runs roughly ten times faster than the typist figures at the head of the results.

Two qualifiers keep the math honest. First, a 30-minute file does not travel as one request on most lanes, because of the caps in the next section. It arrives as chunks, and chunks can run in parallel. The wall time then approaches the longest chunk times its RTF, not the whole file times its RTF. Split a 30-minute file into eight pieces under a 240-second ceiling and run them at once. The finish line is one chunk of about 4 minutes at 0.39, roughly a minute and a half away. Second, RTF moves with the audio and the load. Dense crosstalk, hard accents, and queued requests push it up. Treat 0.39 as a planning figure. Re-measure on your own recordings. If you would rather own the card than rent the lane, the open weights run far faster than that pin on a 24 GB card. The Whisper break-even guide pins local speed tiers of 0.05 to 0.15 as its working assumptions.

Four caps, four failure modes

A long file meets its first cap at the request boundary. Most providers bound what one call may carry. Some bound bytes, some bound seconds, some bound both. OpenAI accepts files up to 25 MB on the transcription endpoint and tells you to compress or split anything larger (official guide). This platform's lane carries a 25 MiB upload cap. Azure's fast transcription path stops under 500 MB. When you cross a size cap you get a loud refusal, usually a 413, and nothing bills. Loud failures are the good ones.

The second cap is time per request. Some lanes reject long audio even when the bytes fit. Deepgram documents a 2 GB file ceiling and a processing window too. Requests past 10 minutes can return a 504. The window is 20 minutes on their Whisper tier (docs). This platform's effective ceiling sits near 240 seconds per batch request. Gladia caps one pre-recorded request at 135 minutes. A time cap also fails loudly. Sometimes it reads as a timeout rather than a clean refusal.

The third cap is the streaming session, and it is the sneaky one. A batch refusal arrives as an error you can read. A live stream that crosses its session cap just ends. Sometimes there is a close frame, sometimes the socket drops. Google ends a streaming recognition stream at 5 minutes and publishes an official reconnect pattern for anything longer (quotas). Speechmatics lets a session run 48 hours. Both are called streaming. Your client has to treat the session boundary as a scheduled event, not a crash.

The fourth cap is the output cap, and it is the quietest. The transcription models on OpenAI's newer transcribe family return at most 2,000 output tokens per request. OpenAI's model page prints the number, under a Deprecated status the page still carried when read 2026-10-28 (gpt-4o-transcribe). A two-hour file fits the input rules and streams fine. Then the last stretch of text comes back missing. No error, no partial flag. Developer forums have carried threads on this silent truncation through 2025. The fix is the same chunking the size cap forces. That is one reason chunking is a base skill here, not an optimization.

Under all four caps sits a fifth number, and no API removes it. Whisper, the open model family behind most lanes, has a 30-second receptive field (model card). Every long-file path is chunking plus stitching. Sometimes you do the chunking. Sometimes the platform does it out of sight. The card documents the two long-form algorithms plainly. The sequential sliding window is slightly more accurate. Independent chunks stitched at the boundaries are faster for one long file. The card's own comparison puts the cost at up to about 0.5% word error rate.

The limit table, read today

Every number below comes from the provider's own page, read 2026-10-28. Where a number could not be read, the cell says so and carries the check date. A missing number is a fact too: it means the limit lives in an error code you discover in production.

Three readings follow from the table. The spread is enormous. The phrase "supports long audio" means nothing until you know which number. Units differ row to row: bytes here, minutes there, tokens on one model family, and documented absence in three cells. And a limit row says nothing about quality. Community long-file users of the open weights still report repetition loops and invented text at chunk boundaries and during long silence. Limits you can plan around. Accuracy on your audio you have to test.

One of these numbers moved between reads

The limit table above and our earlier long-audio guide disagreed on one row until today. The disagreement is the point. Our long-audio streaming and chunking guide recorded Amazon Transcribe at 4 hours per batch call and 4 hours per streaming connection, read 2026-09-11 from the same FAQ page. Today, 2026-10-28, that FAQ says eight hours on both counts, and the guide now records eight. The number changed between two reads of one page, and neither read caught a release note.

That is not a one-off. The same Google quotas page read today carries its own drift note. Batch requests accept 5 files per request, the page says, down from 15 before, and heading to 1. Gladia's own limits page says the caps "will be gradually lifted" over time. Two directions, same lesson. A limit is a dated observation, not a constant. Re-read the two rows that matter to you on the day an architecture depends on them. Keep the date next to the number in your own notes.

The arithmetic of chunking

Once a cap binds, the work is arithmetic. The arithmetic is short. Which cap binds first depends on your encoding, because size caps are in bytes and audio is in bytes per second. Uncompressed WAV at 16 kHz, 16-bit, mono runs about 1.92 MB per minute. A 25 MB cap therefore binds near 13 minutes of that WAV. The same speech as Ogg Opus near 24 kbps runs about 0.18 MB per minute. The same 25 MB cap then binds past two hours, and the time cap binds first instead. Compress before you split: it often removes half the chunks.

Chunks for one hour of audio, by the binding cap:

How you cut matters as much as how many. Cut on silence, never on a fixed tick. OpenAI's own guide says to avoid mid-sentence splits, because a split there removes context and hurts accuracy. Keep a few seconds of overlap around a boundary you do not trust. Keep the cleaner reading when you merge. One more rule saves an afternoon: timestamps inside a chunk are chunk-relative. Add the chunk's start offset before you merge, or every chunk's word times restart at zero. The runnable version of all this lives in the long-audio streaming and chunking guide. That page carries a python splitter. It converts any input to 16 kHz mono WAV and cuts at silence under the per-request ceiling. This page carries the numbers. That one carries the code.

Boundary quality is the tax on chunking. Honest pages state it. The model card's own comparison puts independent chunks up to about 0.5% worse than the sequential window. Community reports on the open weights add two boundary artifacts. One is repeated text. The other is invented text during silence or steady noise. Plan a boundary review pass when a transcript gets quoted in court or a medical record. Speaker labels are a separate question again. The real-time diarization guide covers who-spoke-when and its own session caps.

The whisper lane here: the contract in numbers

The whisper lane is one of this platform's serving transcription routes as of 2026-10-28. Its request contract is short. The endpoint takes the OpenAI transcription shape: a multipart form with a file part and a model id. The file rides in WAV, FLAC, or Ogg Opus, up to 25 MiB. One batch request carries an effective ceiling near 240 seconds, so longer audio is client-side chunks by design. Unknown form fields get a 400 before any work starts. The language field is optional here and auto-detected when omitted. That is worth knowing, because the platform's Japanese-first speech lane works the other way and needs a working language code. The whisper model page carries the full request contract and the model background.

A first call, complete:

curl -sS $IRONSTRATUM_BASE_URL/v1/audio/transcriptions \
  -H "Authorization: Bearer $IRONSTRATUM_API_KEY" \
  -F file=@meeting.wav \
  -F model=whisper

Three facts about that call. It bills on the audio seconds the transcript reports: the clip's own duration, rounded up to the next whole second, silence inside the clip included. A 9.4-second clip bills as 10. Upload, queueing, and processing wall time never count. The streaming face is the one place silence can go free: its meter sums the final events' durations, so gaps where nobody speaks add nothing there. A refused request bills nothing. A retried chunk bills again. The idempotency header on this route carries no replay semantics. Deduplication in a retry loop is your code. On a 15-chunk hour with flaky wifi, write it with care.

The streaming face of the same endpoint, with stream set to true, answers in server-sent events. Its input is strict: raw PCM or WAV at 16 kHz, 16-bit, mono. Anything else is refused with a 400. A long stream does not ride one session. Sessions end at a 230-second cap with a named stream_time_limit close, just under the roughly 240-second connection close the host confirmed on 2026-10-27. The close is terminal and not retryable, because the same long stream hits the same wall. The engineering is the same reconnect discipline the provider table forces everywhere else. One page owns the streaming session story, including what each event type carries: the streaming session limits guide.

What a long job costs is one multiplication. Rates come from the fence, never from this prose:

cost of a long job  =  H x P_stt

H      =  audio hours in the job, the sum across all chunks
P_stt  =  the per-audio-hour rate off the fence above

One sensitivity line: cost moves pro rata with audio hours and with the rate. The only hidden multiplier in a long job is the retry loop, because every retried chunk meters its audio again. The hard bound is the wallet. This platform meters against a prepaid balance. A key whose balance reaches zero is refused at request time. The worst case of a chunking bug is the balance you loaded. The failure patterns and the guards are their own page: avoid API bill shock.

Where free routes stop

The free end of this search is a real intent. It deserves a straight answer. Free web transcription tools generally cap the upload, the month, or both. The caps sit where long audio begins. The pages we read on 2026-10-28 cap a single upload near half an hour in the common case. Monthly allowances run to a few hours. Tools that advertise no limits lean on queueing, slower models, or export walls. None of that is a knock on them. It is the shape of free: fine for a meeting, wrong for an archive.

The chat-assistant route hits the same wall. A general chat assistant takes file uploads at app limits. Community reports through 2025 describe spotty handling of anything long. The reliable path at that vendor is the plain transcription API. It carries the same 25 MB cap as the table above. Office-suite transcribe tools have their own file ceilings. Those numbers live on support pages, and those pages drift too.

Carry one pattern away. Free routes and chat routes are metered lanes with the caps moved down. They are not a different technology. When a file outgrows them, the choice narrows to two. One is a metered lane like this one. The other is your own card. The Whisper cost per audio hour page works that crossover with dated rate reads on both sides.

Decision rules

Current per-unit rates for every lane sit on the pricing page. To run the chunk arithmetic against a real wallet: sign up. Create a key, load a small balance, and send the longest file you own.

Frequently asked questions

How do I transcribe a long audio file?

Pick your row from the limit table. If the file clears the size and time caps, send it in one request. If it does not, compress it first, then split what remains at silences under the binding cap, and loop one request per chunk. Add each chunk's start offset to its timestamps before merging. Keep a small overlap where a boundary looks risky and keep the cleaner reading. The python client in the long-audio streaming and chunking guide does the silence-aware version of exactly this.

How long does it take to transcribe 30 minutes of audio?

For a human typist, the ranking answers say roughly four times the audio length. That is about two hours. For a machine, the unit is real-time factor: processing time equals audio length times RTF. The platform's Japanese-first speech lane (hayamimi) carries a measured pin of about 0.39, taken 2026-08-29 on a clean 20.32-second English clip; the whisper lane has no published RTF pin yet. Thirty minutes of similar audio is 30 x 0.39, about 11.7 minutes, serially. Run the chunks in parallel. The wall time then drops toward one chunk's processing time. Re-measure on your own audio. RTF moves with content and load.

What is the maximum file size for transcription APIs?

As read on 2026-10-28: OpenAI 25 MB per file. Groq 25 MB on the free tier, 100 MB on the dev tier. This platform 25 MiB with an effective ceiling near 240 seconds per request. Deepgram 2 GB with a 10-minute processing window, 20 on their Whisper tier. Azure fast transcription under 500 MB and under 5 hours, batch 1 GB per file. AssemblyAI 5 GB or 10 hours by URL, 2.2 GB by upload. Amazon Transcribe 8 hours or 2 GB per batch call. ElevenLabs Scribe under 5 GB with no duration cap documented. The units differ, so read the row, not the marketing.

Why did my transcript come back cut off with no error?

Most likely an output cap. The newer OpenAI transcribe models return at most 2,000 output tokens per request. OpenAI's model page prints the number, on a page now marked Deprecated. The cutoff is silent: no error, no partial flag, just a missing tail. Shorter chunks are the treatment. The same symptom on other lanes can be a mid-file timeout. That one announces itself as a 504 instead. Name the failure mode before you change providers. Both are chunking problems.

When should I chunk myself instead of sending the whole file?

Send whole whenever the file clears every cap. It is simpler. There are no boundary artifacts, and the timestamps need no offset math. Chunk when any cap binds. That means size, duration, session length, or output tokens. Silence makes the best cut point, because mid-sentence splits cost accuracy on every documented comparison. Chunk for wall-time speed too. Parallel requests turn an hour of audio into roughly one chunk of processing time.

Does silence in my audio cost money?

Depends which face of the endpoint you use. On the batch lane the meter is the clip's reported duration, rounded up to the next whole second: silence inside the clip bills, because it is part of the clip. Upload, queueing, and processing wall time never bill. On the streaming leg the basis changes: the meter sums the final events' durations, and gaps where nobody speaks add nothing. A refused request bills nothing either way. The vendor contrasts are worth knowing. One row of the table bills the total time the WebSocket stays open, audio or no audio (AssemblyAI streaming docs, read 2026-10-28). Another floors every request at 10 billed seconds, however short the clip (Groq docs, read 2026-10-28). Four meters, four contracts for the same quiet meeting. Read the metering paragraph, not just the rate, before you commit a long-running job.

Rates and metering units for every lane sit on the pricing page. To put a real hour through the chunk arithmetic: sign up. Create a key, load a small wallet, and let the reported duration decide.

Last verified: 2026-10-28