Podcast transcription the free month is counted in minutes and the work is counted in episodes

Ten pages, two numbers each, and not one subtraction

Here is what each of the ten results publishes. The last column is the question a podcaster is actually holding.

Four of the ten publish a monthly budget in minutes; six quote an episode length in minutes; zero divide the two, and zero state how many episodes a month the budget covers. The one page that already counts in episodes — restream, “one podcast episode for free” — publishes no minutes at all, so it cannot be converted either.

• The two numbers are usually on the same page. kapwing’s “two-hour episode” is in its opening paragraph and its 10-minute free allowance is in the FAQ; podsqueeze’s 60-minute episode is in its opening paragraph and its 30-minute free plan is in the FAQ. Both pages have everything needed to answer the reader, and neither does the sum.
• The spread across the same job is 30×. The smallest published monthly budget is kapwing’s 10 minutes; the largest is otter’s 300. That is 30× for the same task, on the same results page, and the reader has no way to tell which of the two describes their month.
• Only one page states a per-job ceiling. freeonlinetranscribe writes: “The default cap is about one hour per job, set by our processing timeout. That covers the majority of interview and narrative shows. For a two- or three-hour episode, split the file in your audio editor and transcribe each part separately, then concatenate the text.” It is the only page of the ten that says what happens when an episode does not fit — and it is the one that does not charge per minute.

All quotations are from the ten results read on 2026-10-10; all ten returned text, so every count on this page is out of ten. We did not upload an episode to any of them and make no claim about whether their published figures hold in practice.

The speed claims on the same page disagree by 12×, and ours sits between them

If a page does not divide its budget by an episode, the next thing a reader reaches for is speed: how long will I wait. Three pages here tie a length to a time, and they do not agree.

Two of those three are the same domain, and they are a factor of two apart. Otter’s sentence is the only one of the three that states an actual rate, and it is the slowest claim on the page — a one-hour episode would be a one-hour wait. Our own measured rate lands between them, and it is the one that lets you size a job: at 18.1 to 20.5 seconds per minute of audio, a 30-minute episode is 543 to 615 seconds, a 60-minute episode is 1,086 to 1,231 seconds (about 18 to 20.5 minutes), and a two-hour episode is 2,172 to 2,461 seconds (36.2 to 41.0 minutes).

• Our ceiling is per job, not per month, so the answer to “how many episodes” is different here. We cap a job at 30 minutes of audio and 512 MiB. That makes a 60-minute episode two jobs and a two-hour episode four — and each of those jobs is edited separately afterwards.
• Nobody prices the split. freeonlinetranscribe tells you to split a long episode; it does not say that splitting turns one editing pass into two, or that the seam between parts is a place where a sentence can end up half in each file. Ours is a 30-minute cap, so on our side a typical hour-long show is always two files.
• Cache matters most on the short end, which is the opposite of what an episode needs. On our 13-second clip a warm run saved 48.0%; on the 1,610-second recording it saved 11.8%. An episode is long, so it lives in the expensive column.

Timings are read from timing-live-clipquill-com.csv (13 / 60 / 277 / 1,610 s, cold and warm). Per-minute rates are 550.4 ÷ (1,610 ÷ 60) = 20.5 s cold and 485.7 ÷ (1,610 ÷ 60) = 18.1 s warm; the 30-, 60- and 120-minute waits are that measured rate multiplied by the duration and are labelled as arithmetic, not as separate runs. Cache savings are (45.2 − 23.5) ÷ 45.2 and (550.4 − 485.7) ÷ 550.4 from the wall-clock columns.

What an episode weighs, from the longest material we have measured

Our benchmark’s eight short clips are not an episode. The closest thing we have published is the long-form set: three files, measured separately, in edit-load-long-files.csv.

Read the third column against our own ceiling and the collision is visible: the longest single file is 4,508 reference words, which at our measured reference rate of 148.2 words per minute is 30.41 minutes of speech — just over our 30-minute cap. Three files together are 7,385 words, or about 49.8 minutes: roughly one episode, and on our side that is two jobs.

• An episode’s length can be estimated from its word count, and that is a two-way door. At 148.2 words per minute, a 30-minute episode is about 4,446 words and a 60-minute episode about 8,892. If you know roughly how many words your host and guest speak, you know which side of the cap you are on before you upload anything.
• Correcting the text costs more than reading it. On the 7,385 words of the long-form set, the default tier drops 82 words and leaves 133 spots that need a human decision; the small tier drops 45 and leaves 79; our cloud reference drops 111 and leaves 592 — the cloud reference drops the most words of the three, and leaves the most spots to fix by a factor of four. That is a real trade, not a free upgrade, and it is the kind of number an episode-long job makes unavoidable.
• What we have not measured is worth naming. None of these three files is a real podcast episode: there is no music bed, no ad break and no overlap between speakers in our set, and we have not run a file with any of them. We also have not tested a multitrack recording where each speaker arrives on a separate track.

Word counts, dropped-word counts and spot counts are from edit-load-long-files.csv; the 148.2 words per minute reference rate is 229 words ÷ 92.7 s × 60 from wer-by-condition.csv and wer-by-sample.csv. Minutes of speech are our own division and are labelled as arithmetic: 823 ÷ 148.2 = 5.5, 2,054 ÷ 148.2 = 13.9, 4,508 ÷ 148.2 = 30.4, 7,385 ÷ 148.2 = 49.8.

What we measured on, because a percentage without that is not a number

Four of the ten readable pages print an accuracy percentage for podcast transcription. None of them says what it was measured on: across all ten pages the words test set, corpus, validation set, ground truth and sample size occur zero times. Here is our whole set instead.

The set behind those rows is eight clips, 92.7 seconds and 229 reference words — two speakers, one noise type, six of eight clips read aloud. It is not a podcast: there is no music, no advertising read and no overlapping speech in it, so the 34.8% heavy-noise row is the nearest thing we have to a bad remote-guest line, and it is 5.7× the 6.1% clean row on the same model.

All percentages are from wer-by-condition.csv and wer-by-sample.csv. WER is total errors divided by total reference words (weighted), not an average of per-clip percentages; the 229-word total is the scorer count after apostrophe splitting, documented in the repository README.

Questions this page answers

How many podcast episodes can I transcribe for free?

No page ranking for this phrase answers it, because the answer is a division between two numbers the same page publishes and never relates. Four of the ten publish a monthly budget in minutes — kapwing 10, podsqueeze 30, podtyper the first 30 free, otter 300 — and six quote an episode length in minutes, from 10 to 120. Done by hand with each page’s own two figures, kapwing’s free month covers 0.08 of the two-hour episode its page advertises, podsqueeze and podtyper each cover half of a 60-minute episode, and otter covers five. The spread between the smallest and largest published budget is 30×, for the same job.

Does one podcast episode fit inside a free transcription tier?

On three of the four pages that publish a monthly budget, no. kapwing publishes 10 minutes a month while its own page says it handles “a full two-hour episode”. podsqueeze publishes 30 minutes a month and its own page describes “a typical 60-minute podcast episode”. podtyper gives the first 30 minutes free and its own FAQ names “hour-long shows”. Only otter’s 300 minutes a month clears a 60-minute episode. Our own ceiling is 30 minutes of audio per job, so on our side a 60-minute episode is two jobs and a two-hour episode is four.

How long does it take to transcribe a one-hour podcast episode?

The three pages that tie a length to a time disagree by 12×. otter writes “Otter works at the same pace as the audio, so if your podcast is 10 minutes long, it’ll take 10 minutes to transcribe” — 1.0×. podsqueeze writes that a 30-minute podcast transcribes in less than 5 minutes, which is 6×, while a second page on the same domain writes that a typical 60-minute episode finishes in under 5 minutes, which is 12×. Our own measured rate is 18.1 to 20.5 seconds of processing per minute of audio: 1,610 seconds took 485.7 s warm and 550.4 s cold, so a 60-minute episode is 1,086 to 1,231 seconds, about 18 to 20.5 minutes.

What happens when a podcast episode is longer than the limit?

It has to be split, and nobody prices the split. Our own ceiling is 30 minutes of audio per job, so a 60-minute episode is two jobs and a two-hour episode is four, and each job then gets its own editing pass. The only page of the ten that states a per-job ceiling is freeonlinetranscribe, at about one hour, and it says the same thing: for a two- or three-hour episode, “split the file in your audio editor and transcribe each part separately, then concatenate the text”. On our long-form test set of three files totalling 7,385 reference words — about 49.8 minutes of speech at our measured 148.2 words per minute — the longest single file is 4,508 words, or 30.41 minutes, which is just over our own 30-minute cap.

How many words is a podcast transcript?

At our measured reference rate of 148.2 words per minute, a 30-minute episode is about 4,446 words and a 60-minute episode about 8,892. Our long-form test set is the closest thing we have measured: three files of 823, 2,054 and 4,508 reference words, 7,385 in total. Correcting that set at the default tier costs 82 dropped words and 133 spots to fix; the small tier costs 45 and 79; our cloud reference costs 111 and 592. None of the ten ranking pages publishes a word count for the transcript it returns, so there is nothing on the results page to compare ours against.

Where the raw data is

The word counts, editing loads, timings, memory peaks and per-condition error rates on this page come from the same published measurement run as the rest of this site.

• Raw data and the measurement scripts — github.com/supersophia8888-cloud/clipquill-asr-benchmark, including the raw model text behind every number, so the scoring can be redone under different rules.
• Archived copy with a DOI — 10.5281/zenodo.22826968, the concept DOI: that link always resolves to the newest version of this dataset, all versions.
• The same data as a dataset — huggingface.co/datasets/sophia8888/clipquill-asr-benchmark
• How much correcting an episode takes — edit-load-long-files.csv in the repository, three files and 7,385 reference words.
• Cold versus warm, four durations — timing-live-clipquill-com.csv, from 13 s to 1,610 s.
• The word this one sits next to — audio to text, where the same phrase covers three different file shapes.
• Whether a limit written in two units hides which wall you hit — eight pages publish a limit, and only one tells you which one you will hit
• Two different jobs hiding under one phrase — voice to text: a live transcript and a submitted file are two different jobs

Run it on your own episode

The transcriber is on the front page of this site, and it counts in jobs rather than in minutes per month: the caps are 30 minutes of audio and 512 MiB per file, checked before any work starts. That means a 30-minute episode is one job, a 60-minute episode is two, and a two-hour episode is four. Expect the first run to spend about 78.4 MiB on the model download and roughly a gigabyte of RAM, and expect 18–20.5 seconds per minute of audio — a 30-minute episode is about 9 to 10 minutes of waiting after you hand it over.

Transcribe a file