Talk for an hour, get your text in seconds

01Every engine has a ceiling

The model I was testing on, gpt-4o-mini-transcribe, had a limit on its answer: it could return only so many tokens, the small units a model uses to represent text. Audio could fit within its input limit while the transcript needed more room than its output allowed.

The request could return HTTP 200, the code for success, with part of the speech missing. I covered that hole in the middle in the engine comparison. A successful response was not proof of a complete transcript. Even checking whether the answer had reached its token cap missed some incomplete results.

gpt-transcribe moved the boundary much further out. A recording of 3,599 seconds came back complete; one of 3,600 seconds was refused with a message saying the audio might be corrupted. Re-encoding it did not help. An extra second took the recording from a complete transcript to an error.

Soniox and ElevenLabs passed the hour-long test, and their declared limits sit further out still. I had not tested those ceilings. Changing engines gave a long recording more room; sending small pieces offered a way to stay comfortably below the limits instead of finding the next one during a dictation.

02Every minute adds to the wait

Taking the whole recording was only the first hurdle. In the whole-file approach, transcription still started after I let go. An accepted file could keep me waiting simply because there was more speech to process.

My own dictations showed a roughly linear relationship. On the same engine, for whole-file recordings longer than a minute, each extra minute spoken added about a second and a half of waiting on average. I measured that wait from releasing the key to receiving the raw text, before it was pasted. The engine could handle the recording; finishing it still took longer as the recording grew.

One six-and-a-half-minute dictation in a development build showed how bad the wait could get. The request timed out 46 seconds after release. Another request eventually returned the text, about 86 seconds after I had stopped talking. That was one failure, not the typical delay.

A separate bench test pushed whole files towards an hour. gpt-transcribe took 92 seconds on the longest file; ElevenLabs took 31. These were individual provider-call timings, not the wait through the desktop app, and each length was tested once. The faster engine made a substantial difference, but it still received the whole recording after it was finished.

03Heavy files, few sessions

The audio had to get through my server too. A minute of uncompressed WAV weighed almost two megabytes, so a long dictation became a large upload before transcription could begin. At roughly thirteen minutes, raw audio reached the speech provider's file-size limit. That was another boundary to deal with, separate from the models' limits on audio duration and output text.

I load-tested the server by replaying one real dictation, about five minutes long, from increasing numbers of simulated users. One instance processed about eight requests at once; at fifteen users, 92% of requests failed. Doubling its memory moved the throughput ceiling by exactly zero. The constraints were the amount of request data it could handle per second and the number of requests its workers could process together.

I started by compressing the recording on the Mac, before sending it. Repeating the test with the same speech encoded as AAC, a much smaller file, reached forty simulated users without a failed request and more than quadrupled throughput. I stopped on the test's budget, not on the server: the new ceiling had not been found. Compression was a useful first fix, but the engine still received the whole recording only after I let go.

04Start before I finish

I was sending one whole recording after I stopped talking. Compression made it lighter, but none of its transcription happened while I spoke. Cutting offered a way to use that time: send a finished piece before the rest of the recording exists.

Each piece goes to the engine in an ordinary file request while I record the next one. The client keeps the returned text in recording order. Most transcription can finish before I let go; after release, the app waits for whatever is still outstanding, usually the final piece, then joins the text. The remaining work depends on those outstanding pieces rather than a whole recording that has only just been sent.

05First try: overlap and stitch

My earlier experiments used fixed-length pieces, so a cut could land in the middle of a word. I repeated a little audio on both sides of the cut to give the engine another chance at that speech. This returned two versions of the same passage. Joining them meant finding where the texts agreed and keeping the passage once.

The unfinished matcher searched too far back in the earlier text. Two common words in the wrong place convinced it that it had found the join, and it silently deleted 79 words of real speech, with no error raised. This time the missing words came from my own joining code. Restricting the search to the end of one piece and the beginning of the next repaired it. Across four long Ukrainian dictations, the bounded matcher showed a net word-count difference of four on 1,505 words, with no invented word sequences detected and every join reading coherently. It was a useful result from that tested set.

I also tried having a language model do the joining. Given the whole text, it produced visible duplication at the joins. Restricting it to the joins worked much better, but still deleted three real words and added paid model calls. The bounded algorithm did the job better. I had a workable way to join overlapping text, but every cut still created something to reconcile.

06Silence changes the question

The overlap was there because a fixed-length cut could land in the middle of a word. At a pause between phrases, there is no word to split: the pieces join end to end, in order, with no audio sent twice and nothing to match. My silence measurements showed such pauses are common: almost half the pauses between phrases lasted more than a second.

To hear a pause while I am still talking, the cutter uses the same kind of live detector as the recording indicator, with its own settings. It should call silence only when it is sure: a missed pause just makes a piece a little longer, while a false pause in the middle of a word cuts the word in two.

Cutting has a price of its own: each piece is transcribed without hearing the rest of the recording. I compared the text after cutting and trimming the pauses with the text of the same recordings sent whole, counting changed, added or missing words. There were 1.16 such differences per 100 words on average. Repeating the whole-file request produced 0.28 differences per 100 words. I did not check either transcript against what I actually said, so this comparison cannot tell which version got a word right. Cutting at pauses made the join simple; it did not give the engine back the rest of the recording.

07How long should a piece be

My first rule waited forty seconds, then cut at the next pause. It had no ceiling, so nothing in the rule bounded a piece when a suitable pause failed to arrive. Later replays showed a forty-second start made many more joins with no measured gain, so the search moved to start after a minute, with a two-minute ceiling. These were search limits, not a schedule for cutting at exact intervals. Most short dictations stayed untouched: 88% of the tested archive went to the engine as one piece.

Then I looked at where the cuts actually landed. The typical piece lasted seventy-two seconds, not sixty, so I asked whether the floor could move down until the median cut fell on the minute. The study replayed 1,046 dictations and answered with a price. A forty-eight-second floor produced 44% more joins and 63% more final pieces shorter than fifteen seconds, for about 0.2 seconds less predicted median wait after release. That wait was modelled from the final pieces of recordings over two minutes, not newly measured through the app. That was a bad trade, and the one-minute start stayed.

Moving the floor later was not a clear win either. It reduced joins but increased the modelled worst wait as longer pieces became possible. The study recommended keeping both, with medium confidence. I had wanted smaller pieces, but it persuaded me: in my own use that balance is working well, and I am not planning to change it.

08Hearing a pause while you talk

The cutter has only the audio already recorded. Once a piece passes a minute, it waits for the first pause that begins after that point and lasts a full second. When the second is confirmed, it puts the boundary about halfway into the pause. The decision comes after the boundary, without needing to hear what I will say next.

At two minutes, it stops waiting and looks back over that piece's search window. First it chooses the longest pause of at least half a second. If the gate found none, the trimmer's voice detector gets one look at the recorded audio, looking for a non-speech stretch of at least a fifth of a second in the same window. I added that step after the archive replay produced two hard cuts in 158 cuts. In one recording, the live gate missed an earlier short gap; the voice scan moved the boundary from 119.9 seconds back to 82.1, out of the stretch of speech.

If even that scan finds no suitable boundary, the cutter uses the quietest point in the last ten seconds. That hard cut keeps the piece bounded, but can still divide speech. The gate can miss a real pause: in the unusually long waits I examined, sound above its silence line or a short burst inside a pause often stopped it accepting silence. Waiting longer was not always evidence that I had spoken without stopping.

09Fast, whatever the length

The change shows up where I wanted it: after I let go of the key. The chart plots my hold-to-talk recordings against the wait for raw text. Below a minute, both clouds still climb because nothing has been cut. Beyond a minute, whole-file recordings added about 1.7 seconds of wait per extra minute spoken on average across engines, and about 1.5 seconds on gpt-transcribe alone. Recordings sent in pieces stayed roughly flat over the lengths observed.

10An hour on the bench

My real dictations had reached about ten minutes, so testing an hour meant assembling one. I joined 124 real recordings into just under an hour of audio, with room noise between them, and ran it through the desktop's recording code with gpt-transcribe and a local API. In two raw-text runs, it made 44 pieces. At speaking speed, only a short final piece remained after release; when I fed the audio ten times faster, an earlier piece was still in flight too. Raw text was ready in 0.9-3.2 seconds across the runs, depending on the outstanding pieces. A similarly long file took 92 seconds in the separate whole-file provider test. Most of the piecewise pipeline's work had happened while the recording was still going.

That timing does not certify a complete transcript. The test used an earlier trimmer, and 122 of the 124 clips came back in the text. It has not been repeated on the current build. Both missing clips were the same quiet whisper; one of them the engine loses even untrimmed. The silence-trimming article covers the trimmer's part. These raw-text timings exclude the production network hop and paste. AI formatting of the whole text adds its own wait, covered below.

11What the pieces open up

While I am still speaking, the app already holds text from the pieces that have returned, in order, on my Mac. Today the pieces stay invisible; the user still gets one dictation. Having that text early makes room for a future interface to show progress through a long recording, based on work already finished.

These are ordinary file requests, rather than a realtime transcription session. In my comparison, realtime cost more on Soniox, ElevenLabs and Deepgram, though not on gpt-transcribe; Soniox's realtime mode also bills the whole session, silence included, so trimming pauses would save nothing there. Cutting let me keep the file engines and finish most of their work before release. In my longer dictations, I can keep following the thought, then let go and have the raw text in a few seconds.