DEV Community: Ray Mac

Subtitles Out of Sync? The 4 Causes and How to Fix Each One

Ray Mac — Tue, 13 Oct 2026 03:40:43 +0000

Subtitles go out of sync for one of four reasons, and each needs a different fix. The whole file can be early or late by the same amount (an offset). It can start right and slide further off as the video plays (a frame-rate mismatch). It can be fine until one point and then jump (a different cut of the video). Or the file can be roughly in place while individual lines start late, end late or hang over silence (bad line timing, which is what most auto-generated subtitles suffer from).

You can tell which one you have in about two minutes by checking two lines, one near the start and one near the end. This guide shows how, gives the fix for each case, and then digs into the fourth kind with numbers: we built test audio where we knew the exact moment every sentence started and ended, ran it through Whisper three ways, and measured how far the subtitle timings landed from the speech.

Step 1: find out which kind of out of sync you have

Pick a line near the beginning of the video and a line near the end. For each one, write down two times: when the line is spoken in the video, and the start time the subtitle file gives it. The difference is the offset at that point.

What you see	Offset near the start	Offset near the end	Cause	Fix
Everything is early or late by the same amount	2.0 s late	2.0 s late	Constant offset: a different intro, logo or lead-in	Shift every line by the same amount
Starts in sync, gets worse steadily	0.2 s	2 min 34 s early	Frame-rate drift: subtitles made for a different frame rate	Stretch the timings (frame-rate conversion or two-point sync)
In sync, then suddenly off from one scene onward	0 s	12 s late, starting from one scene	A different cut: a scene, recap or ad break added or removed	Shift only the lines after the jump
On average in place, but lines pop in late, linger, or show during silence	varies by line	varies by line	Bad line timing, typical of auto-generated subtitles	Retime the bad lines, or regenerate with word-level timing

Two checks are enough to tell the first two apart: if both offsets are about equal, it's a constant offset. If the second is much bigger, divide it by how far into the video that line is. A steady ratio of about 4% is the signature of a frame-rate mismatch (more on the numbers below).

Fix 1: the whole file is early or late (constant offset)

This is the most common case and the easiest fix. Common causes: the subtitle file was made for a version with a longer studio logo, a "previously on" recap, or a few seconds of black at the start.

To watch right now, adjust it in the player. VLC has a subtitle delay setting. On Windows and Linux the default hotkeys are G and H, which move subtitles 50 ms earlier or later per press, according to VLC's hotkey list. The Mac build uses different keys, so check Preferences → Hotkeys there. Most other players (mpv, PotPlayer, Plex, Kodi) have a similar subtitle offset setting. The change only lasts for that playback session.

To fix the file for good, shift every timestamp. Two ways:

In the browser: load the file into the free SRT editor, optionally with the video, enter the shift in seconds (negative to move earlier) and apply it to all cues. Play a few lines against the video to confirm, then download. The file stays on your computer.
On the command line, ffmpeg can do it: ffmpeg -itsoffset 2.5 -i in.srt out.srt moves every cue 2.5 s later.

One ffmpeg trap we hit while testing: a negative offset bigger than the first cue's start time gets quietly shortened. On ffmpeg 8.1.1, shifting a file whose first cue starts at 1.0 s by -itsoffset -1.5 moved every cue only 1.0 s earlier, just enough to put the first cue at 0:00. Every later cue ended up 0.5 s late, and ffmpeg printed no warning. Our editor clamps each cue at 0:00 separately instead, so only cues that would start before the video begins get squashed, and every other cue moves by the full amount. If you use ffmpeg for negative shifts, check the second cue, not the first.

Fix 2: subtitles drift further off as the video plays (frame rate)

If the subtitles start in sync and are a few seconds off after half an hour and minutes off by the end, the file was timed against a version of the video that runs at a different speed. The classic case: subtitles made for a 25 fps European (PAL) release played against a 23.976 fps release of the same film. The PAL release runs about 4% faster, so every timestamp is about 4% too small.

Here's how far off that gets, by how long into the video you are:

Subtitles made for	Played on	Off after 10 min	30 min	60 min	90 min
25 fps	23.976 fps	25.6 s	1 min 17 s	2 min 34 s	3 min 51 s
25 fps	24 fps	25.0 s	1 min 15 s	2 min 30 s	3 min 45 s
24 fps	23.976 fps	0.6 s	1.8 s	3.6 s	5.4 s

(Ratio 25 / 23.976 = 1.0427, so a cue at 60:00 belongs at 62:34.) The last row is the sneaky one: 0.1% looks like nothing, but it puts a feature film's last scenes 5 to 7 seconds off.

Shifting can't fix this, because the error grows. You need to stretch the timings:

If you know both frame rates, use a frame-rate conversion. In Subtitle Edit that's Synchronization → Change frame rate. Getting the direction backwards doubles the problem, so test one late line before saving.
If you don't, use two-point sync: tell the tool the correct time of one line near the start and one near the end, and it scales everything in between. Subtitle Edit calls this Point sync. The math is a straight line: new time = a × old time + b, where a and b come from your two corrected lines.

Our SRT editor only shifts; it doesn't stretch. For drift, use a tool with point sync, then load the result into the editor if you want to check it against the video.

Fix 3: in sync, then suddenly off from one point (a different cut)

If the first half is perfect and everything after one scene is late by the same amount, the subtitles came from a different edit: a director's cut, a TV version with a recap, or a recording with an ad break. Find the first line that's wrong, measure its offset, and shift that line and everything after it. Subtitle Edit can shift just selected lines (select from the first bad line to the end). If there are several jumps, repeat for each section.

Fix 4: lines start late, linger, or show during silence (bad line timing)

The first three problems are about the whole file. This one is about individual lines, and it's the one you'll meet in auto-generated subtitles: a line that appears a beat late, stays on screen through a long pause, or shows up during the intro music before anyone speaks.

What counts as "in sync" here? Netflix's subtitle timing guidelines are the strictest common reference. A subtitle should appear on the first frame of the audio, with 1 to 2 frames either way accepted (at 24 fps, a frame is about 42 ms). The out-time should ideally be at least half a second after the audio ends, provided the line doesn't visibly linger. So the target is: appear with the voice, and leave about half a second after it.

We wanted to know how close AI subtitles get to that, and what goes wrong when they miss. So we measured it.

The test: speech with known timings

You can't measure timing errors without knowing the right answer, and nobody knows the exact start of every word in a real recording. So we built one where we did:

We wrote 30 sentences (a short history of a lighthouse) and had four macOS voices read them (US, UK, Australian and Irish English), cut to the exact start and end of the speech.
We joined them with gaps of 0.35 to 1.4 seconds, plus three long pauses of 6, 12 and 25 seconds, the kind you get in interviews and lectures. That gave a 2 min 49 s track where we knew every sentence's start and end to the millisecond.
We made four versions: clean; with 20 seconds of synthetic intro music before the first word; with a music bed under the whole thing; and with pink noise under the whole thing.
We transcribed each version with Whisper (small model, faster-whisper 1.2.1) in three setups:
- Plain Whisper: the library defaults, timing each line from Whisper's segment timestamps. This is what you get from many basic Whisper wrappers.
- Word timestamps: the same, plus word-level timing, with each line starting at its first word and ending at its last.
- Word timestamps + VAD: word timing plus a voice activity detector that skips non-speech before Whisper sees it. These are the settings ScribeToAny's own engine uses in its fast mode.
For every line that starts or ends a sentence, we compared its time with the true time.

The results

Setup	Lines starting within ±0.25 s	Lines ending more than 0.5 s late	Longest a line stayed up over silence	Sentences lost
Plain Whisper	48–89%	83% (86 of 104)	25.0 s	3 (clean version)
Word timestamps	64–72%	0%	5.2 s	0
Word timestamps + VAD	62–90%	0%	1.4 s	0

Ranges cover the four versions (clean, intro music, music bed, noise). Here's what's behind them.

1. Plain Whisper's lines don't end, they wait for the next one. In the clean version, all but one line ended exactly where the next one started. Whisper's segment timestamps run back to back, so a line stays on screen until the next line replaces it. Over normal gaps that means lines end about 0.9 s late (median), on the edge of Netflix's half-second allowance or past it. Over a long pause it's worse: one line, "Next to it is the keeper's logbook from the winter of 1947", was spoken in 4 seconds and then stayed on screen through another 25 seconds of silence. To a viewer, a subtitle hanging over silence looks like the subtitles are out of sync, even though every start time is fine.

2. Plain Whisper lost three sentences after the long pause. In the clean version, the three sentences after the 25-second pause never appeared: the transcript jumped from the line before the pause to the fourth sentence after it. The line after them, "The keeper rowed out twice in a storm", went up 11 seconds early, over the missing ones. Nothing in the output flagged the gap. The same audio with intro music in front kept all three. If a transcript gets out of step after a long silence, check whether lines are missing before you start retiming.

3. Intro music put the first line at 0:00. With 20 seconds of music before the first word, plain Whisper made the first subtitle the single word "The", from 0:00.00 to 0:20.64, and put the rest of the sentence in the next line. So a lone "The" sits on screen for the whole intro. This is the classic "first subtitle is way too early" complaint. With VAD the first line started at 0:20.08, 0.42 s before the voice, because the detector had removed the music before Whisper ran.

4. Word timestamps fix the hanging but end every line early. With word-level timing no line ever hung over a pause for more than a few seconds, and with VAD no more than 1.4 s. But the ends came out early across the board: in every version, all or all but one of the line endings came before the voice stopped, by a median of 0.18 to 0.21 s. Starts were early too, by a median of 0.10 to 0.16 s. We checked this against our ground truth: setting the speech-end point with a stricter loudness threshold moved it by only about 0.03 s, so the early bias is real. Measured against Netflix's target of leaving half a second after the voice ends, word-timed lines leave about 0.7 s too soon.

5. Noise hurts plain Whisper's starts most. Under pink noise, only 48% of plain Whisper's lines started within a quarter-second of the voice, and three were more than a second off. With word timestamps it was 66%, with no line more than 0.72 s off.

What we didn't test: synthetic voices are cleaner and more regular than people, so real recordings will likely do somewhat worse on every setup. This was one model (small; our engine's other modes use larger models, which we didn't test here), English only, 30 sentences, one run per setup. The pattern is what matters here (segment timing hangs over silence, word timing ends early, VAD fixes the intro), not the exact percentages.

What to do with auto-generated subtitles

Check three places before anything else: the first line (is it on screen during the intro?), the line before every long pause (does it hang over the silence?), and the line after it (is anything missing?).
If lines hang over pauses, end each line at its last word. A tool that times from word timestamps will do this for you. If you're stuck with segment-timed lines, retime the ones before long pauses by hand.
Push line ends out a little. Word-timed lines tend to vanish just before the voice stops. Extending each end by about half a second, where the next line leaves room (Netflix wants at least 2 frames between lines), puts them close to the broadcast convention, and it also gives viewers more time to read. Our subtitle reading speed experiment found the same move cut the share of too-fast lines from 68% to 29%.
Strip the intro before transcribing, or use a tool with voice activity detection, if the video opens with music.

How ScribeToAny does it: our engine uses the third setup: word-level timestamps with a voice activity detector tuned to keep quiet speech. That avoids hanging lines, the 0:00 intro line and, in this test, lost sentences. But it also had the early-ending problem: its lines ended about 0.2 s before the voice. So after this test we changed how the engine ends lines. Each line now stays up to half a second past its last word, never into the next line, and any gap left under half a second is closed to 2 frames, following Netflix's rules. Starts don't move. We ran the same word timings through the updated code. Line ends went from a median 0.2 s before the voice to 0.38 to 0.41 s after it, and no lines overlapped. As a side effect, the lines reading faster than 17 characters per second dropped from 14 to 20 of 30 per version to 1 to 4. You can still edit any line's start and end times in the transcript's QC view, or load the exported file into the SRT editor with the video and adjust it there.

How to keep subtitles in sync in the first place

Make subtitles from the exact file you'll publish. Re-export after the final edit. Most offset and cut problems come from subtitling a rough cut.
Note the frame rate of the version the subtitles were made for, and keep it in the file name if you work with several releases.
Check two points, not one. One correct line proves nothing about drift.
Prefer word-timed subtitles for anything with pauses: interviews, lectures, podcasts. If you're generating them, the subtitle generator makes a timed SRT or VTT from your audio or video in about 98 languages.

FAQ

Why are my subtitles a few seconds behind? If they're behind by the same amount all the way through, the file was made for a version with a longer intro. Shift every line earlier by that amount. If they get further behind as the video goes on, it's a frame-rate mismatch and needs stretching instead.

Should subtitles appear before the person speaks? Netflix's rule is on the first frame of audio, with one or two frames of tolerance. In our test, word-timed AI subtitles appeared 0.10 to 0.16 s early (median), a few frames. In our view that matters far less than lines that appear late or stay on screen through a silence.

Can I fix subtitle sync without installing anything? For a constant offset, yes: load the file and the video into the browser-based SRT editor, shift all lines and download. For frame-rate drift you need a tool that can stretch timings, such as Subtitle Edit's point sync.

Out-of-sync subtitles feel like one problem, but it's four, and the two-minute check tells you which one you've got. Offsets need a shift, drift needs a stretch, cuts need a partial shift, and auto-generated subtitles need their line ends looked at, especially around silence. We hadn't expected the silence to matter more than the noise, but in our test it did.

Originally published on the ScribeToAny blog.

Can ChatGPT Transcribe Audio? We Uploaded a Real Recording to Find Out

Ray Mac — Mon, 05 Oct 2026 17:00:16 +0000

Short answer: not from an uploaded file in a normal chat, at least in our test. On 4 October 2026 we uploaded a one-minute MP3 to ChatGPT's free web app and asked for a word-for-word transcript. Both the default mode and Think mode recognised the file and its length, then declined. ChatGPT can turn speech into text in three other ways:

Dictation types what you say into the message box.
Record mode transcribes live audio. It's for paid plans, in the macOS app only.
OpenAI's API transcribes files, but you need to write code.

Here's the test, what each option actually does, and when a dedicated transcription tool is the better fit.

The test: one MP3, one prompt

We used the same recording as in our transcript examples guide. It's a 64-second interview between two people: a podcast host and a baker. We made it for our product tutorial from a written script, with two text-to-speech voices. Because we have the script, any transcript of it can be scored word for word.

We uploaded podcast-bakery-interview.mp3 (about 1 MB) to a new chat and sent this prompt:

Transcribe this audio word for word. Label each speaker (Speaker 1,
Speaker 2) and give a timestamp at the start of each speaker turn.

Default mode (the page reported the model as gpt-5-6) answered after about 8 seconds. It said it could see the file and that it was about a minute long, but that it didn't currently have an audio transcription capability in that chat session. It offered to format a transcript if we supplied one.

Think mode (gpt-5-6-t-mini) worked for 12 seconds. It measured the file precisely as about 1 minute 3.6 seconds; the real length is 63.6 seconds. Then it said it couldn't hear or decode the audio in that environment, and it wouldn't produce a transcript "without risking making up text". Again it offered a template with Speaker 1 and [00:00] placeholders.

Two things are worth noting:

It didn't invent a transcript. That's the right behaviour. A confident fake transcript would have been worse than a refusal.
It could read the file's length but not its words. That suggests the chat could inspect the file's data, but had no speech recognition to apply to it.

What we didn't test: this was the free plan, on the web app, on one day. ChatGPT's features change often and differ by plan. A paid plan or a different app may behave differently, so try your own file before you rely on either answer.

The ways ChatGPT can turn speech into text

ChatGPT isn't one product here. OpenAI offers several speech-to-text routes, and they do different jobs. From OpenAI's own help pages and API documentation:

Option	What it transcribes	Who can use it	Speaker labels	Timestamps
File upload in a chat	Nothing, in our free-plan test	Everyone	n/a	n/a
Dictation (microphone icon)	What you say, typed into the message box for you to edit	ChatGPT users; the help article lists no plan limits	No	No
Record mode	A live recording of a meeting or voice note, then notes. Up to 4 hours per session	Plus, Pro, Business, Enterprise and Edu, in the macOS desktop app only	Yes: generic labels such as "Speaker 1", which you can rename	Not described in the help article
OpenAI API (`gpt-transcribe`, `gpt-4o-transcribe`, `whisper-1` and others)	An audio or video file you send from your own code	Developers with an API account (pay per use)	With `gpt-4o-transcribe-diarize`	With `whisper-1` (word or segment level)

A few details from those docs matter in practice:

Record mode records; it doesn't import. The help article describes pressing Record and transcribing as you talk. It doesn't describe feeding it a file you already have. OpenAI also says it "works best in English today".
The API caps files at 25 MB. It accepts mp3, mp4, mpeg, mpga, m4a, wav and webm. Longer recordings have to be compressed or split.
In the API, timestamps and speaker labels come from different models. Per the docs, timestamps are only available with whisper-1, and speaker labels need the separate diarization model. A subtitle file with both takes more than one call.

When ChatGPT is the right tool, and when it isn't

Use ChatGPT's Record mode if you're on a paid plan, you use a Mac, and the audio is happening now: a meeting, a brainstorm, a voice note. You get a transcript and a summary in the same place.

Use dictation if you just want to talk instead of type.

Use something else if you have a recording already: an interview, a lecture, a podcast episode or a video file. You'll also want something else if you need any of these:

timestamps on every line,
an .srt or .vtt subtitle file,
a language other than English that you need to rely on,
a transcript you can check line by line against the audio before quoting it.

That's what dedicated transcription tools are built for. We ran the same 64-second file through ScribeToAny's engine. It returned the whole transcript with speaker labels and timestamps. 14 of 14 speaker turns were labelled correctly, and 4 of 189 words differed from the script. Two of those were real errors and two were "eighty" written as "80". The full scoring, mistakes included, is in our transcript examples.

The workflow that uses both

ChatGPT is very good at what comes after the transcript: summarising it, pulling out action items, writing chapter titles, drafting show notes. So split the job:

Transcribe the recording with a tool built for it. Try the audio to text or video to text tools. Turn on speaker detection for interviews and meetings.
Check the transcript against the audio, especially names, numbers and anything you'll quote. (See how accurate AI transcription is.)
Paste it into ChatGPT and ask for the summary, action items or chapters. In ScribeToAny, the AI summary & chat button builds a ready-to-paste prompt with your transcript in it. It opens Claude by default, but the prompt works in ChatGPT too. ScribeToAny itself doesn't send your transcript to any AI service.

You get the accuracy and timing of a transcription engine, plus the writing help of a chat assistant, and you can check every step.

So, can ChatGPT transcribe audio? It can transcribe you, live, through dictation and Record mode, and developers can use OpenAI's API. But in our test, dropping an existing recording into a chat didn't produce a transcript. For a file you already have, transcribe it first, then bring the text to ChatGPT. Start with the interview transcription tool if there's more than one voice.

Originally published on the ScribeToAny blog.

What Is an SRT File? The Format, an Example, and the Mistakes That Break It

Ray Mac — Mon, 05 Oct 2026 16:54:01 +0000

An SRT file (.srt, short for SubRip Subtitle) is a plain-text subtitle file. It holds a list of numbered cues. Each cue has a start time, an end time and the words to show on screen between them. Almost every video player, editor and video platform can read one. That's why it's the default answer to "what subtitle file do I need?"

The name comes from SubRip, a free Windows program that pulled subtitles off DVDs and saved them as text. The program is long gone, but its output format became the lingua franca of subtitles. SRT never got a formal specification, though. Every tool reads it its own way, and that's where the trouble starts. Below is the format, a real example, and what happened when we fed 16 slightly broken SRT files to ffmpeg and to our own converter.

What an SRT file looks like

Here are the first three cues of a real file: the subtitles ScribeToAny made for a 64-second interview we use in our tutorial.

1
00:00:00,000 --> 00:00:01,680
Welcome back to Small Shop Stories.

2
00:00:02,160 --> 00:00:05,320
Today I'm talking to Maya, who runs a tiny bakery on the

3
00:00:05,320 --> 00:00:06,320
corner of Mill Street.

Each cue is four parts, always in this order:

A number. The cue's position in the file, counting from 1.
A timing line. The start and end time, separated by --> (space, two hyphens, a greater-than sign, space). The format is hours:minutes:seconds,milliseconds, so 00:00:05,320 is 5.32 seconds.
The text. One or two lines is the norm. Most style guides cap a line at about 42 characters.
A blank line. It marks the end of the cue.

Two details catch people out. The milliseconds come after a comma, not a dot; the dot is WebVTT's habit. And the file should be saved as UTF-8, or accented letters turn into garbage in some players.

What SRT can and can't do

SRT is deliberately simple. That's its strength and its limit.

Basic styling works, mostly. Many players honour , ,  and . Support varies, so don't rely on colour.
Positioning isn't part of the format. Some files put {\an8} at the start of a line to move it to the top of the screen. That's borrowed from the ASS format. Players that don't understand it show it as literal text.
There's no language field. The convention is to put the language in the filename, such as interview.en.srt and interview.es.srt. Media servers and players use that to label the tracks.
Web browsers can't play it. The HTML5 <track> element only accepts WebVTT. We checked in Chrome 152: an SRT file in a <track> failed to load and showed no cues, and the same cues saved as .vtt loaded fine. For web video, convert with SRT to VTT.

For how SRT compares with VTT, TXT, JSON, ASS and the rest, see subtitle and transcript file formats.

We fed 16 broken SRT files to ffmpeg, and to our own converter

With no official spec, "valid SRT" means "whatever the tool you're using accepts". To see what that means in practice, we took the three cues above and broke them in 16 different ways, the kinds of mistakes that come from hand editing, old Windows tools and copy-paste. Then we ran all 17 files (the valid one plus the 16 broken ones) through two readers.

ffmpeg 8.1.1. A huge number of video tools use it under the hood. We converted each file to WebVTT.
ScribeToAny's subtitle converter, the parser behind our free SRT tools.

Here's what happened. "Silent" means the conversion reported success and the output looked fine at a glance. At most, a warning was printed in the log.

What's wrong with the file	ffmpeg 8.1.1	ScribeToAny (before our fix)
Nothing (valid file)	✅	✅
Dot instead of comma (`00:00:01.680`)	✅	✅
Byte-order mark at the start (Windows Notepad)	✅	✅
Windows line endings (CRLF)	✅	✅
Cue numbers out of order or skipped (5, 2, 9)	✅	✅
One-digit hours (`0:00:01,680`)	✅	✅
Extra coordinates after the times (`X1:100 X2:600 …`)	✅ Ignored	✅ Ignored
No cue numbers at all	⚠️ Rejected when ffmpeg guesses the format; read fine when told it's SRT	✅
No spaces around the arrow (`-->`)	⚠️ Same as above	✅
Short arrow (`->`)	❌ Nothing read	❌ Nothing read
Two-digit milliseconds (`,68`)	❌ Silent: read as 68 ms instead of 680, so times moved by up to 0.6 s	✅ Read as 680 ms
End time before start time	⚠️ Silent: cue shrunk to zero length, so it never shows	⚠️ Kept as is; flagged by the editor's quality check
Overlapping cues	Kept as is	Kept as is
`<i>` / `<b>` tags	✅ Kept	✅ Kept
`<font color>` tag	Colour dropped	✅ Kept
`{\an8}` position tag	Tag removed	❌ Shown as text
No blank lines between cues	✅ Three cues	❌ Merged into one cue
Saved as Latin-1 / Windows-1252 ("café")	❌ Silent: that cue dropped	❌ Garbled ("caf�")

What the test shows

The dangerous failures are the silent ones. A file that won't open gets noticed. A file that opens with one cue missing, or with its timings shifted, ships. The two-digit-millisecond case is the nastiest: ffmpeg read ,68 as 68 milliseconds rather than 680, so that time moved 0.6 seconds, and nothing warned about it. Always write three digits: ,680 for 680 ms, ,068 for 68 ms.

Being "lenient" isn't the same as being right. ffmpeg rescued the file with no blank lines, but dropped the Latin-1 cue with only a log warning. Our converter read the Latin-1 cue, but showed the accents as garbage. Neither stopped with an error.

Three of these broke our own tool. Files with no blank lines between cues collapsed into a single cue. {\an8} tags showed up as text in the converted file. Legacy-encoded files came out garbled. We fixed all three the same day. Our parser now finds cues by their timing lines instead of by blank lines. It removes ASS position tags. And it detects the file's encoding (UTF-8, UTF-16 or Windows-1252) instead of assuming UTF-8. We added each case to our regression checks so they stay fixed.

What we didn't test: this was one ffmpeg build and one converter, with small synthetic files. Players such as VLC, editing apps and platforms like YouTube each have their own parser, and may behave differently on the same file.

How to check and fix an SRT file

If a platform rejects your SRT, or the subtitles drift, open the file in a plain-text editor and go down this list:

Encoding. Re-save it as UTF-8. This one fix clears up most garbled accents.
Timing lines. Each one should look exactly like 00:00:05,320 --> 00:00:06,320: two digits for hours, minutes and seconds, three for milliseconds, a comma, and --> with spaces.
Blank lines. There must be one empty line between cues and none inside a cue.
Numbers. Number the cues 1, 2, 3… in order. Most readers don't care, but some strict validators do.
Times that make sense. Each end time must come after its start time. Ideally, each cue ends before the next one starts.
Tags. Remove {\an8}-style tags unless you know the destination player supports them. Keep  for italics.

Faster: load the file into the SRT editor. It runs in your browser, so the file isn't uploaded anywhere. It reads every variation above except the short arrow, and its quality check flags cues that end before they start, overlap, or go by too fast to read. Then save a clean copy. (Too-fast cues are their own topic: see subtitle reading speed.)

How to make an SRT file

From a video or audio file: upload it to the subtitle generator. ScribeToAny transcribes it in about 98 languages and exports a timed .srt.
From a script you already have: text to SRT turns plain text into timed cues.
From another subtitle format: convert with VTT to SRT or ASS to SRT.
By hand: any plain-text editor works. Follow the four-part pattern above and save as UTF-8 with the .srt extension.

An SRT file is the simplest thing in video: numbered cues, a timestamp pair and a line of text. The trouble is that without a standard, every tool fills the gaps differently, often without saying so. Keep your files strictly to the pattern (three-digit milliseconds, blank lines, UTF-8) and they'll read the same everywhere. When one doesn't, check it in the SRT editor before it ships.

Originally published on the ScribeToAny blog.

Transcript Examples: Timestamps, Speaker Labels and Formatting, From a Real AI Transcript

Ray Mac — Sun, 04 Oct 2026 09:13:34 +0000

Most transcript examples online show one tidy, hand-typed sample. That doesn't help when your transcript came out of an audio-to-text engine and looks nothing like it. This guide works the other way round. It takes one real machine transcript and shows it in every common layout: the raw output, speaker-labelled dialogue, three timestamp styles, editing timecode and a video transcript. It also counts what the AI got wrong.

The recording behind every example

All the examples use the same 64-second, two-person interview. A podcast host talks to Maya, who runs a small bakery. We made it for our product tutorial from a written script, with two text-to-speech voices. The people are invented. For some of Maya's answers we sped her voice up by 32%, so the recording has a fast talker in it as well.

Because we wrote the script, we know exactly what was said. That's what lets us score the transcript below instead of eyeballing it. We ran the file through ScribeToAny with the language on auto-detect, the Accurate mode and Detect speakers set to two. Everything in the code blocks below is that output, mistakes included. We only changed the layout, never the words.

Example 1: a raw audio-to-text transcript

This is what you get when you copy the transcript with speakers and timestamps switched on. Here are the first ten of its 30 segments:

SPEAKER_00 (0:00) Welcome back to Small Shop Stories.
SPEAKER_00 (0:02) Today I'm talking to Maya, who runs a tiny bakery on the
SPEAKER_00 (0:05) corner of Mill Street.
SPEAKER_01 (0:07) Thanks for having me.
SPEAKER_01 (0:08) It's really small, just two ovens and a counter.
SPEAKER_00 (0:12) So how does a normal day start for you?
SPEAKER_01 (0:15) Honestly, it starts at four in the morning.
SPEAKER_01 (0:17) I switch the ovens on, mix the sourdough, shape the loaves,
SPEAKER_01 (0:19) and by six there's already a queue
SPEAKER_01 (0:21) outside the door.

And this is how the same transcript looks in the ScribeToAny editor, where each timestamp replays that moment of the audio:

Two things stand out.

The speakers have no names. The engine tells voices apart, but it doesn't know who anyone is. SPEAKER_00 is just "the first voice it heard." Working out who spoke when is called speaker diarization. Putting names on the voices is your job.
Segments are not sentences. The recording has 14 speaker turns, but the transcript has 30 segments. They're short, between 0.5 and 3.2 seconds (half are under 1.5 seconds), and 9 of the 30 stop in the middle of a sentence: "…a tiny bakery on the" / "corner of Mill Street." Segments are cut to fit on screen as subtitles, not to read well as a document. That suits an SRT file. For reading, you'll want Example 2.

What the AI got right, and what it got wrong

Against the script, the transcript scored like this:

Check	Result
Words in the script	189
Words that differ from the script	4
Real recognition errors	2: "Four in the morning" came out as "For in the morning", and "the one thing you'd tell" as "you tell"
Style differences, not errors	2: "eighty" was written as "80", twice
Speaker turns labelled correctly	14 of 14, including the sped-up answers
Segments that end mid-sentence	9 of 30

Scored strictly, that's a 2.1% word error rate. If you count "80" as a correct way to write "eighty", it's 1.1%. Don't read too much into this. It's one minute of clean synthetic speech, with no background noise and nobody talking over anyone else. Real recordings do worse, sometimes much worse. See how accurate AI transcription really is. What the test does show is the kind of mistake to look for. Homophones like "for" and "four" sound identical, so only the context gives them away. Small words like "you'd" are easy to miss on a quick read. And style choices, such as digits versus words, are made for you by the engine.

Example 2: a speaker-labelled transcript (dialogue format)

This is the layout most people mean by "transcript". Each speaker turn is one paragraph, and each paragraph starts with a speaker label. To get it from the raw output we did three things:

Merged each run of segments from the same speaker into one turn.
Renamed SPEAKER_00 to HOST and SPEAKER_01 to MAYA.
Kept one timestamp per turn: the start of its first segment.

[00:00:00] HOST: Welcome back to Small Shop Stories. Today I'm talking to
Maya, who runs a tiny bakery on the corner of Mill Street.

[00:00:07] MAYA: Thanks for having me. It's really small, just two ovens and
a counter.

[00:00:12] HOST: So how does a normal day start for you?

[00:00:15] MAYA: Honestly, it starts at four in the morning. I switch the
ovens on, mix the sourdough, shape the loaves, and by six there's already a
queue outside the door.

[00:00:22] HOST: For in the morning, every single day?

[00:00:25] MAYA: Six days a week. Sunday is for sleeping and for testing new
recipes.

[00:00:30] HOST: What sells out first?

[00:00:33] MAYA: The cardamom buns. We bake about 80 and they're usually
gone before nine.

The words are exactly what the engine wrote, including "For in the morning", which you would correct before using it. Only the line breaks and labels changed. The 30 fragments become 14 readable turns.

Speaker labels in a transcription: which style to use

There's no single standard. What matters is choosing one style and using it the whole way through. Common choices:

Label style	Looks like	Use it when
Generic	`Speaker 1:` `Speaker 2:`	You don't know the names, or don't need them
Full name	`MAYA:` or `Maya Patel:`	Podcasts, panels, published interviews
Role	`Interviewer:` `Participant:`	Research and HR interviews, where roles matter more than names
Anonymised code	`I:` `P1:` `P2:`	Qualitative research that must not identify participants
Q and A	`Q:` `A:`	Two people, strictly question then answer

A few rules hold for all of them. Use the full label the first time someone speaks if you'll shorten it later. Never reuse a label for two people. When you can't tell who's talking, write [unclear speaker] instead of guessing. In research, the anonymised code is the privacy measure. Keep the key that maps P1 to a real person separate from the transcripts. For a full research workflow, see how to transcribe research interviews.

Example 3: timestamping a transcription, three styles

Timestamps answer the question where in the recording is this? How many you need depends on what you'll do with the transcript.

Per segment. One time for every line, as in Example 1. It's the densest style. It's good for checking the transcript against the audio line by line, and it's what subtitle files need. As a document, it's too busy to read.

Per speaker turn. One time at the start of each turn, as in Example 2. This is the usual choice for interviews, meetings and podcasts. When you want to quote someone, you can still find the exact moment.

At fixed intervals. A marker every 30 seconds, every minute or every five minutes, dropped into continuous text. This suits long, mostly one-speaker recordings such as lectures and sermons. Here's our interview with a marker every 30 seconds:

[00:00:00] HOST: Welcome back to Small Shop Stories. Today I'm talking to
Maya, who runs a tiny bakery on the corner of Mill Street. MAYA: Thanks for
having me. It's really small, just two ovens and a counter. HOST: So how
does a normal day start for you? MAYA: Honestly, it starts at four in the
morning. […] HOST: For in the morning, every single day? MAYA: Six days a
week. Sunday is for sleeping and for testing new recipes.

[00:00:30] HOST: What sells out first? MAYA: The cardamom buns. […]

Two practical notes. A transcript timestamp points to the start of the words it's attached to, so seeking there plays them from the beginning. And [00:00:30] (hours:minutes:seconds) is clearer than [0:30] once a recording runs past an hour. Choose the long form if there's any chance it will.

Example 4: timecode, from transcript to subtitles and video editing

"Timecode" means the same moment written to a different precision. Here's the start of Maya's first line, which the engine placed at 7.27 seconds, in each format you're likely to meet:

Where it's used	Format	The 7.27-second mark
Transcript, reading	`HH:MM:SS`	`00:00:07`
SRT subtitles	`HH:MM:SS,mmm` (comma)	`00:00:07,270`
WebVTT subtitles	`HH:MM:SS.mmm` (dot)	`00:00:07.270`
Video editor, 25 fps	`HH:MM:SS:FF` (frames)	`00:00:07:06`
Video editor, 30 fps	`HH:MM:SS:FF` (frames)	`00:00:07:08`

The first three count milliseconds. The last two count frames, and that's where hand-made conversions go wrong. At 25 frames per second, 0.27 seconds is frame 6 (0.27 × 25 = 6.75, rounded down). At 30 fps, it's frame 8. Editors working at 29.97 fps often use drop-frame timecode, written with a semicolon before the frames. It skips some frame numbers so that the clock stays in step with real time: the frame after 00:00:59;29 is 00:01:00;02. If the timecode is for an editor, ask which frame rate they're using. Don't assume.

Here are the same opening seconds as an SRT file:

1
00:00:00,000 --> 00:00:01,680
[SPEAKER_00] Welcome back to Small Shop Stories.

2
00:00:02,160 --> 00:00:05,320
[SPEAKER_00] Today I'm talking to Maya, who runs a tiny bakery on the

3
00:00:05,320 --> 00:00:06,320
[SPEAKER_00] corner of Mill Street.

Note the comma before the milliseconds. That's SRT. WebVTT uses a dot. For the full format reference, see subtitle and transcript file formats.

Example 5: a video transcript

An audio transcript records what was said. A video transcript should also record what was shown, whenever the picture carries meaning the words don't. Think of a title card, a chart, or a click the narrator doesn't describe. The W3C accessibility guidelines call this a descriptive transcript. It's what a deaf-blind user reads on a braille display, and it's what search engines and AI tools can quote, because they can't watch the video.

Here are the first 15 seconds of our own product tutorial. The narration comes from its subtitle file. We wrote the bracketed notes from the video's frames.

[00:00:00] [Title card: "How to use ScribeToAny. Transcript · subtitles ·
translation, step by step", over the dimmed homepage]

NARRATOR: Here's how to use ScribeToAny, step by step: from a recording to a
transcript, subtitles and a translation.

[00:00:05] [The homepage. Headline: "Turn any audio or video into text, then
into 134+ languages"]

[00:00:08] NARRATOR: Go to scribetoany.com and click "Start transcribing
free".

[00:00:13] [The "Create an account" form, with name, email and password
fields. The cursor rests on "Sign in with Google".]

NARRATOR: Sign up with Google, or with your email.

How to write the descriptions:

Describe only what matters for understanding. "The cursor rests on 'Sign in with Google'" helps. "The background is dark grey" doesn't.
Copy on-screen text word for word, in quotes. Viewers may search for it.
Mark sounds that carry meaning: [music], [laughter], [phone rings]. This is also what turns subtitles into captions. See captions vs. subtitles.

Speech recognition only hears the soundtrack. In a video transcript the narration can be automatic, but the bracketed descriptions are always written by a person.

Verbatim vs. clean verbatim

How faithfully should a transcript keep "um", false starts and repeats? There are two standard answers:

Verbatim keeps everything: fillers, stutters, false starts, [pause] marks. Use it for legal and evidence work, and for research where how something was said matters.
Clean verbatim removes the noise but keeps the meaning and the speaker's own words. It's the default for interviews, podcasts, meetings and anything you'll publish.

Our test recording can't show the difference, because text-to-speech voices don't hesitate. So here's a made-up line for illustration:

Verbatim:        So, um, I— I switch the, uh, the ovens on at, like, four.
Clean verbatim:  So I switch the ovens on at four.

Whisper-family engines, ours included, tend to write something close to clean verbatim. Many fillers and false starts never reach the text. If you need true verbatim, plan to add them back by hand while listening.

Style decisions the AI makes for you

Look again at "We bake about 80". The script said "eighty", and the engine chose digits. That's not a mistake, but it is a style decision, and you'll find a lot of them in an AI transcript:

Numbers: digits or words ("80" or "eighty"), and times ("four in the morning" or "4 a.m.").
Punctuation: where sentences end, which affects how quotes read.
Spelling: US or UK English ("color" or "colour"), and how names and brands are written.

No rule is right everywhere. Publications and research teams each have their own style guides. What matters is consistency: decide once, then fix the exceptions with find-and-replace. Don't fix them one by one as you go.

How to get these formats from your own recording

Upload the audio or video to the audio-to-text or video-to-text tool. For more than one voice, open the extra settings and tick Detect speakers.
Check the transcript against the audio. Clicking a timestamp replays that moment, and clicking a line lets you fix a word. That's how you'd catch "For in the morning" and correct it to "Four".
Copy or export with speakers and timestamps on or off. Use TXT, DOCX or PDF to read, SRT or VTT for subtitles, and TSV, CSV or JSON for analysis.
In your document, replace SPEAKER_00 and SPEAKER_01 with real names or codes, and merge the short segments into turns where you want the dialogue layout from Example 2.

A transcript is the same timed words laid out for different jobs. You can play it back segment by segment, read it as dialogue, scan it by timestamp, cut video to it, or read it as text in place of the video. Start from the raw output, choose the layout your reader needs, and check the small words. Try it on your own recording with the interview transcription tool.

Originally published on the ScribeToAny blog.

Transcription Pricing Compared (2026): ScribeToAny vs Otter, Rev, Sonix and HappyScribe

Ray Mac — Sun, 27 Sep 2026 14:42:27 +0000

Transcription tools love to advertise a monthly price, but the monthly price
tells you very little. What matters is how many hours of audio that price
covers, and whether the plan lets you upload the files you actually have.
Two tools at the same $20 can differ tenfold in what you get.

So instead of comparing sticker prices, this post works out what a real
workload costs on five tools: Otter.ai, Rev, Sonix, HappyScribe and
ScribeToAny (ours — we'll be upfront about where the others are the better
choice). Every number comes from each vendor's public pricing page, checked on
September 23, 2026; links are at the end. Prices change, so treat this as a
snapshot and check the vendor's page before you buy.

One scoping note: this is about transcribing recorded files — interviews,
lectures, podcasts, videos. Live meeting bots are a different job, covered
under "When another tool is the better choice" below.

Cost per hour of audio

Each row is the cheapest plan that includes file uploads, divided by the hours
of transcription it includes each month.

Tool and plan	Price	Included per month	Cost per hour
ScribeToAny Plus	$10/mo · $88/yr	25 h (1,500 min)	$0.40 · $0.29 yearly
ScribeToAny Pro	$20/mo · $120/yr	50 h (3,000 min)	$0.40 · $0.20 yearly
Rev Essentials	$29.99/mo · $305.90/yr	83 h (5,000 min)	$0.36 · $0.31 yearly
Otter.ai Pro	$16.99/mo · $99.96/yr	20 h (1,200 min), max 10 file imports	$0.85 · $0.42 yearly
HappyScribe Pro	€29/mo · €228/yr	10 h (600 min)	€2.90 · €1.90 yearly
HappyScribe Basic	€17/mo · €102/yr	2 h (120 min)	€8.50 · €4.25 yearly
Sonix Core	$25/mo · $275/yr	5 h	$5.00 · $4.58 yearly
Sonix pay-as-you-go	$10 per hour	—	$10.00

Two things stand out. Per hour, Rev Essentials is slightly cheaper than
ScribeToAny on monthly billing ($0.36 vs $0.40; on yearly billing ScribeToAny
is cheaper) — but it starts at $29.99 and covers English and Spanish only;
you need Rev Pro ($59.99/mo) for its 37+ languages. And Otter's 1,200
minutes are capped at 10 imported files a month on Pro, so if your work is
uploading recordings rather than recording meetings, the file cap runs out long
before the minutes do.

What a real month costs

Cost per hour hides the jumps between plans, so here are two concrete
workloads, priced on monthly billing (yearly in brackets).

10 hours of recordings a month

Ten one-hour interviews, or twenty 30-minute lectures.

Tool	Plan you'd need	Monthly cost
ScribeToAny	Plus (1,500 min)	$10 ($7.33)
Otter.ai	Pro — fits only if it's ≤ 10 files	$16.99 ($8.33)
Rev	Essentials	$29.99 ($25.49)
HappyScribe	Pro (600 min)	€29 (€19)
Sonix	Core 5 h + 5 h at $10/h	$75

30 hours of recordings a month

A research project, a weekly podcast back catalogue, or a course's lectures.

Tool	Plan you'd need	Monthly cost
ScribeToAny	Pro (3,000 min)	$20 ($10)
Rev	Essentials (5,000 min)	$29.99 ($25.49)
Otter.ai	Business — Pro stops at 1,200 min and 10 files	$30 ($19.99)
HappyScribe	Business (6,000 min)	€89 (€59)
Sonix	Pro (40 h)	$80 ($73.33)

At 30 hours, the gap with Sonix and HappyScribe is several-fold. Rev and Otter
Business come closest, at roughly $20–30 a month against ScribeToAny's $10–20 —
and Otter Business is a per-user plan built for meetings rather than file
uploads.

Free plans: what you can actually do before paying

Tool	Free allowance	Longest file	Exports on free
ScribeToAny	100 min every month, 2 files/day	30 min	All 8: TXT, SRT, VTT, TSV, CSV, JSON, PDF, DOCX
Otter.ai	300 min/month, but 3 file imports in total	30 min	TXT, MP3
Rev	45 min/month, English only	not listed	not listed
HappyScribe	10-minute one-time trial	45 min	TXT, SRT
Sonix	30-minute one-time trial	not listed	not listed

ScribeToAny's free plan is smaller than Otter's on paper, but it renews every
month, has no lifetime import cap, and includes speaker labels and every export
format — so you can test your real files, in the format you need, before paying
anything. No credit card is required.

Limits that change the math

File length. ScribeToAny paid plans take files up to 3 hours (5 GB). Otter Pro stops at 90 minutes per conversation and HappyScribe Basic at 90 minutes per file; long recordings would need splitting there.
Languages. ScribeToAny transcribes about 98 languages on every plan, free included, and can transcribe non-English audio straight into English. Otter supports 6 languages; Rev Essentials 2 (37+ on Pro); Sonix 54+; HappyScribe 150+ (60+ on its free trial).
Parallel work. ScribeToAny paid plans transcribe 6 files at once, with no daily upload limit.
Translation. Finished ScribeToAny transcripts can be translated into 134+ languages for free (via Google Translate), keeping the original subtitle timings.

When another tool is the better choice

Cheaper isn't better if the tool doesn't do the job. Pick one of the others if:

You need live meeting notes. Otter joins Zoom, Teams and Google Meet and transcribes in real time. ScribeToAny transcribes recordings you upload; it doesn't join calls.
You need human-verified transcripts. Rev offers human transcription at $1.99/min with 99%+ accuracy, and legal transcript formats — useful for court and compliance work. ScribeToAny is machine transcription only; see how accurate AI transcription really is for what to expect.
You need a rare language or professional subtitling. HappyScribe covers 150+ languages, exports 15+ formats and sells human subtitling.
You're a team that lives in a shared workspace. Sonix is built around multi-seat workspaces and AI analysis of transcripts.
You transcribe 80+ hours a month. Rev's larger allowances (5,000 minutes on Essentials, 10,000 on Pro) fit very high volumes; ScribeToAny Pro tops out at 3,000 minutes a month.

The short version

If your work is uploading recordings — interviews, lectures, podcasts,
videos — and you transcribe somewhere between a few hours and 50 hours a
month, ScribeToAny is the lowest-cost way to do it among these five: $10 a
month covers 25 hours, $20 covers 50, with 3-hour files, ~98 languages and
every export format. You can try it on your own files with the
free plan, no card needed.

Sources

Prices and limits as published on each vendor's pricing page on September 23,

EUR prices are shown as published, not converted. Yearly cost per hour divides the yearly price by 12 months of included time.

Otter.ai — otter.ai/pricing
Rev — rev.com/pricing
Sonix — sonix.ai/pricing
HappyScribe — happyscribe.com/pricing
ScribeToAny — scribetoany.com/pricing

Otter.ai, Rev, Sonix and HappyScribe are trademarks of their respective owners.
This comparison is independent and not endorsed by any of them. Spotted a
number that's changed? Tell us and we'll update it.

Originally published on the ScribeToAny blog.

Subtitle Reading Speed (CPS): The Limits, and Why AI Subtitles Break Them

Ray Mac — Sat, 26 Sep 2026 04:35:58 +0000

A subtitle can be perfectly accurate and still fail. If a line leaves the
screen before the viewer has finished reading it, the viewer has missed it.
Reading speed, measured in characters per second (CPS), is how
subtitlers catch that before anyone watches the video.

This post covers the limits the big style guides use and how to convert
between CPS and words per minute. It then runs a small experiment on
machine-made subtitles. The finding surprised us: most "too fast" subtitles
from AI transcription aren't too wordy. They're timed too tightly, and you
can fix most of them without deleting a single word.

What CPS measures

CPS is the number of characters in a subtitle divided by how long it stays on
screen:

CPS = characters in the cue ÷ seconds on screen

A 42-character line shown for 2 seconds runs at 21 CPS. The same line shown for
2.5 seconds runs at 16.8 CPS.

Two details change the result, so check them before you compare numbers
between tools:

What counts as a character. We count every character the eye reads, including spaces and punctuation, and leave out only the line break between two rows. Some tools skip spaces or punctuation. Their numbers come out lower for the same subtitle.
Which duration counts. The time on screen is the cue's end time minus its start time. It is not how long the person took to say the words. That difference is the whole story of the experiment below.

The limits in the major style guides

Guideline	Reading speed	Line length	Lines	Duration
Netflix, English (adult)	up to 20 CPS	42 characters	2 max	5/6 s to 7 s
Netflix, English (children's)	up to 17 CPS	42 characters	2 max	5/6 s to 7 s
Netflix, Simplified Chinese (adult)	up to 9 CPS	16 characters	2 max	5/6 s to 7 s
Netflix, Japanese	up to 4 CPS	13 full-width characters	2 max	5/6 s to 7 s
BBC	160–180 words per minute	about 68% of a 16:9 frame width	2 (3 if nothing important is covered)	about 0.3 s per word minimum

A few things stand out:

Chinese and Japanese limits are far lower, because each character carries much more meaning than a Latin letter. A Latin-script limit would never flag anything in Chinese text. You need a separate threshold for each script.
The maximum is not a target. Netflix drops to 17 CPS for children's programs, and the BBC's 160–180 words per minute works out to about 14–16 CPS (see below). Aiming below the ceiling leaves room for viewers who read slowly or are reading in a second language.
Minimum duration matters as much as the speed limit. Netflix's 5/6 of a second (20 frames at 24 fps) exists because a flash of text is hard to catch even when it is short.

Converting words per minute to CPS

Speech and subtitle guidelines often use words per minute (WPM). To convert
between the two, you need the average characters per word, including the space
after each word.

In the English sample we measured below (447 words, 2,413 characters), that
came to 5.4 characters per word. So, for English:

Words per minute	≈ CPS
140	12.6
160	14.4
180	16.2
200	18.0
220	19.8

So the BBC's 160–180 WPM works out to about 14–16 CPS in our counting,
noticeably below Netflix's 20 CPS adult ceiling. Audiobooks are commonly
recommended at 150–160 WPM; the explainer voice in our test below ran at 189. A
word-for-word subtitle of a fast talker can therefore break a 17 CPS limit on
text alone. But as the experiment shows, text is usually not the main cause.

An experiment: where AI subtitles break the limit

The audio. We used the English voiceover from our own product video: 2
minutes 48 seconds, 447 words, one clear synthetic voice with natural pauses
between sentences. The words take up 142 seconds of that time, and within those
seconds the voice runs at 189 WPM (17.0 CPS). That's a brisk but normal
explainer-video pace.

The subtitles. We transcribed it with Whisper (the open-source base
model, run locally). We then cut the result into subtitle cues with the same
splitting rules ScribeToAny's engine uses for exported SRT files:

at most 84 characters per cue (two lines of 42);
at most 7 seconds per cue;
break at the end of a sentence first, then at a clause.

Each cue starts at its first word and ends at its last word.

The check. We counted every cue against 17 and 20 CPS, the two Netflix
English limits, and flagged cues shorter than 5/6 of a second. We then applied
two standard fixes, one at a time.

Step	Cues	Median CPS	Over 17 CPS	Over 20 CPS	Shorter than 5/6 s
A. Cues timed to the words	69	19.3	47 (68%)	29 (42%)	17
B. + end extended into the following pause	69	15.5	20 (29%)	9 (13%)	9
C. + short neighbours merged	41	15.5	10 (24%)	3 (7%)	1

What the numbers say

Timed to the words, two thirds of the cues were "too fast." Yet the audio
averages exactly 17.0 CPS while someone is talking. The average cue was not
too wordy. Cues that start and end exactly with the speech leave no reading
time, and the short ones suffer most. For example:

"Need more?" was on screen for 0.36 s, which works out to 27.8 CPS.
"Fix it right there." lasted 0.6 s, which works out to 31.7 CPS.

Using the pauses fixed more than half of the failures. For step B, each
cue's end time moves forward into the silence before the next line starts. We
left an 80 ms gap (about 2 frames at 25 fps) and capped each cue at 7 seconds.
That alone took the cues over 17 CPS from 47 to 20, without changing a word.

Merging short neighbours fixed most of the rest. For step C, a cue that
was still too fast merged with the next one when the result stayed within 84
characters and 7 seconds. We only merged where the combined text ended at
punctuation, so no subtitle ends mid-phrase.

A 0.44-second "Turn on" fragment rejoined the rest of its sentence, "detect speakers, and every line gets a speaker label." The merged cue runs at 15.7 CPS.
Cues over 20 CPS fell to 3 of 41.

What's left is a small editing job. To bring every remaining cue to 17 CPS,
you would need to cut 40 characters out of 2,399, about 1.7% of the text.
To reach 20 CPS, you would cut 5 characters. That is where a human makes
choices: dropping a filler word, or shortening "Then take it out in the format
you need" to "Then export it."

The caveats. This is one recording, with one voice, and with clean pauses
between sentences. A real conversation has fewer pauses, overlapping speakers
and faster bursts, so steps B and C buy less there and condensing matters
more. But the ordering holds in general: fix the timing before you cut
words.

Fixing a fast subtitle, in order

Extend the end time into silence. If the next line doesn't start immediately, let the current cue stay on screen longer. Keep a small gap of about 2 frames before the next cue, so the viewer can see that the subtitle changed.
Respect the minimum duration. Nothing should flash on screen for less than about 5/6 of a second, even a one-word "Yes."
Merge short neighbours. Two quick lines from the same speaker often read better as one two-line subtitle. Stay within your line and duration limits, and don't merge across a change of speaker.
Only then, condense. Remove fillers ("you know," "basically"), false starts and repeated words. Keep the meaning, names and numbers. For a verbatim or legal transcript you wouldn't do this, but subtitles are a reading aid, not a record.
Break lines in sensible places. When a subtitle needs two lines, break after punctuation, or before a conjunction or preposition. Netflix's style guide asks you not to split an article from its noun or a first name from a last name. It also prefers a bottom-heavy shape, with the longer line underneath.

Chinese, Japanese and Korean

For these scripts, character counts behave differently:

Netflix's Simplified Chinese guide allows 9 CPS and 16 characters a line.
Its Japanese guide allows 4 CPS and 13 full-width characters.

A Latin 17 CPS threshold would pass almost any Chinese subtitle, however
cramped. Choose the threshold by the script on screen, not by the source
language. An English translation of a Chinese video is checked as English.

Checking reading speed in ScribeToAny

ScribeToAny's transcript editor has a QC mode on every plan, free
included. Turn on Reading-speed & line checks and each cue shows the
following:

its CPS, amber when it gets close to your limit and red when it goes over;
the character count of each line, with lines over the limit flagged;
whether a cue is under 5/6 of a second or over 7 seconds, or too close to the previous cue.

The defaults are the conservative ones:

17 CPS and 42 characters a line for Latin scripts;
9 CPS and 16 characters for Chinese, Japanese and Korean, picked automatically from the text on screen.

You can change both numbers, for example to 20 CPS for Netflix-style adult
English. You can edit start and end times directly, split a cue or merge it
with the next one, and roll back to an earlier version. Then export SRT or VTT
with the same timings.

To be clear about what it doesn't do: QC mode flags problems. It doesn't
retime cues for you. Steps 1 to 4 above are still your call. That's
deliberate. A tool that silently stretches or rewrites subtitles makes
decisions only a person watching the video can make.

If you only need to adjust an existing SRT file, the free
SRT editor runs in your browser without an account. It
doesn't show reading-speed checks.

Related:

Sources

Netflix, English (USA) Timed Text Style Guide: 42 characters a line, up to 20 CPS for adult programs and 17 for children's, and line-break rules.
Netflix, Timed Text Style Guide: General Requirements: 5/6-second minimum, 7-second maximum, 2 lines.
Netflix, Chinese (Simplified) Timed Text Style Guide and Japanese Timed Text Style Guide.
Wikipedia, Words per minute: 150–160 WPM recommended for audiobooks.
BBC, Subtitle Guidelines: 160–180 words per minute, line width and line count.
Experiment: our own measurement on September 24, 2026, as described above. The cue-splitting rules are the ones our transcription engine uses. Our production service runs larger Whisper models than the base model used here, which mainly affects word accuracy rather than timing.

Originally published on the ScribeToAny blog.

How We Optimized ScribeToAny: From 3.5s Cloudflare Cold Starts to a 95+ Lighthouse Score

Ray Mac — Tue, 08 Sep 2026 04:59:18 +0000

ScribeToAny is a full-stack audio and video transcription platform built on React 19 and deployed to Cloudflare Workers at the edge. Heavy GPU workloads (Whisper transcription, diarization, translation) run asynchronously on Modal, while our web application, authentication, database queries, and SSR are powered by Cloudflare Workers.

While our GPU pipeline was fast and asynchronous, our front-end performance audit delivered a harsh wake-up call: real-world user monitoring (Cloudflare Observatory) showed our 75th-percentile TTFB was 3,128 ms — with over 57% of hits rated "poor". Direct curl tests hitting cold edge nodes clocked TTFB between 3.4s and 3.6s for the homepage and SEO tool pages.

Yet, Cloudflare's internal Worker metrics showed a median CPU wall time of just 5 ms.

How could a Worker that finishes its work in 5 milliseconds take 3.5 seconds to return a response?

Here is the complete engineering breakdown of how we diagnosed the cold-start bottleneck, implemented zero-staleness edge HTML caching, decoupled our client bundles, slashed mobile hydration TBT, and took ScribeToAny to a 95+ Lighthouse performance score.

1. The Paradox: Why 5ms CPU Took 3.5s TTFB

Cloudflare Worker CPU metrics only record active handler execution. They do not account for isolate creation, bundle downloading, and V8 script compilation.

When we inspected our deployment pipeline, two factors collided:

An 11MB Worker Bundle: Because ScribeToAny includes rich SEO tool routes (over 80 audio/video conversion and transcription tools), markdown renderers, and format converter utilities, the bundled worker script reached ~11MB.
Low Baseline Traffic Density (~0.1 req/s): With sparse initial traffic, Cloudflare edge PoPs frequently evict idle V8 isolates.

Almost every new visitor — especially organic search traffic arriving from Google — hit a brand-new, cold isolate. Before running our 5ms SSR handler, V8 had to load and compile an 11MB JavaScript payload. The result was a 3-second cold-start penalty on first visit, completely undermining the user experience and SEO ranking potential.

Furthermore, on mobile devices, initial Lighthouse runs flagged heavy Total Blocking Time (TBT): third-party authentication scripts and oversized vendor chunks were monopolizing the main thread during hydration.

We solved this through a systematic four-layer optimization strategy.

2. Layer 1: Edge HTML Caching with Zero-Staleness Build Invalidation

Cloudflare Workers do not automatically cache dynamic SSR responses. Every incoming GET request was hitting our Worker, forcing a cold-start compilation.

Because our marketing pages, blog, and SEO tools are public and identical for anonymous visitors of the same URL, we implemented edge-level HTML caching directly in src/server.ts using the Workers Cache API (caches.default).

Strict Isolation & Bypass Rules

Edge caching dynamic web apps requires strict safety boundaries:

Session isolation: If the incoming request has a better-auth.session_token cookie, cache reading and writing are completely bypassed. Logged-in users always receive fresh, personalized SSR.
Strict allowlist: Caching is restricted strictly to anonymous public pages (/, /pricing, /about, /changelog, /tools/*, /blog/*, and legal pages). Dynamic routes (/dashboard, /api/*, /settings) are never cached.
Cache write condition: Only responses with HTTP status 200, Content-Type: text/html, and no Set-Cookie header are stored.

// src/server.ts (abridged)
const canCache =
  request.method === 'GET' &&
  !hasSessionCookie(request) &&
  isCacheablePath(deLocalizeUrl(new URL(request.url)).pathname);

const cache = (caches as unknown as { default: Cache }).default;
const cacheKey = canCache ? edgeCacheKey(request) : request;

if (canCache) {
  const hit = await cache.match(cacheKey);
  if (hit) {
    const headers = new Headers(hit.headers);
    headers.set('X-Edge-Cache', 'HIT');
    return new Response(hit.body, { status: hit.status, headers });
  }
}

Solving the Stale Content Problem

The biggest danger of caches.default on Cloudflare Workers is that a new Worker deployment does not purge the cache. With a standard URL key, publishing a new blog post or fixing a bug would leave stale HTML served to users for days.

We solved this by injecting a compile-time build identifier into the cache key:

// vite.config.ts
export default defineConfig({
  define: {
    __EDGE_BUILD_ID__: JSON.stringify(Date.now().toString(36)),
  },
  // ...
});

In src/server.ts, we construct an internal cache key request tagged with __EDGE_BUILD_ID__:

function edgeCacheKey(request: Request): Request {
  const url = new URL(request.url);
  url.searchParams.set('__ev', __EDGE_BUILD_ID__);
  return new Request(url.toString(), request);
}

This internal query parameter is only passed to cache.match and cache.put; it is never exposed to the client or upstream origin.

When a new version deploys, __EDGE_BUILD_ID__ changes. Old cache entries become instantly unreachable and expire naturally on their TTL, while the new release begins populating immediately. We can safely set s-maxage=86400 (24h) and stale-while-revalidate=604800 (7 days) without ever worrying about stale HTML after a release.

Result: Edge cache hits now return in under 45 milliseconds directly from the nearest Cloudflare edge PoP, completely bypassing Worker isolate cold starts.

3. Layer 2: Main Bundle Decoupling & Vendor Splitting

Serving HTML quickly is only half the battle; if the browser has to parse hundreds of kilobytes of unoptimized JavaScript before becoming interactive, the experience still stumbles.

Decoupling Global Configs

Our site configuration (src/config/website.ts) originally bundled metadata, navigation menus, multilingual pricing matrices, and 84 tool route names into one giant object. Because the root layout imported websiteConfig, every visitor downloaded definitions for 84 tools they hadn't visited.

We extracted tool metadata into src/config/navbar-tool-names.ts and pricing calculations into src/config/price-plans.ts, ensuring tool pages only load their own definitions on demand.

Vite Manual Chunks

By default, Vite bundled React, TanStack Query, and Zod into monolithic client bundles. In vite.config.ts, we configured explicit vendor chunks:

// vite.config.ts
build: {
  rollupOptions: {
    output: {
      manualChunks(id) {
        if (id.includes('@tabler/icons-react')) return 'vendor-icons';
        if (
          id.includes('node_modules/react/') ||
          id.includes('node_modules/react-dom/') ||
          id.includes('node_modules/scheduler/')
        ) return 'vendor-react';
        if (
          id.includes('node_modules/@tanstack/react-query') ||
          id.includes('node_modules/@tanstack/query-core')
        ) return 'vendor-query';
        if (id.includes('node_modules/zod/')) return 'vendor-zod';
      },
    },
  },
}

This isolates shared dependencies, improving long-term browser caching across route transitions and preventing small code changes from invalidating vendor libraries.

Scoping Global Providers

In src/routes/__root.tsx, Radix TooltipProvider originally wrapped the entire application tree. This forced React to initialize tooltip context on every public landing page even though tooltips were only used inside the logged-in dashboard and transcription editor. We removed TooltipProvider from the root route and scoped it exclusively to the editor and dashboard components.

Similarly, we extracted prose.css from the global styles.css. Markdown typography styling is now loaded strictly on blog, legal, and documentation routes, eliminating unused CSS overhead on marketing pages.

4. Layer 3: Offscreen Lazy-Loading & Slashing Hydration TBT

On mobile devices, client-side hydration was choking the CPU. When a browser downloads a page, hydrating every single DOM node on a long marketing page blocks user taps and scrolls (high Total Blocking Time).

Synchronous Above-the-Fold, Lazy Below-the-Fold

In src/components/blocks/homepage.tsx, we split the landing page into two categories:

Above-the-Fold (Synchronous): HeroSection, TrustStrip, and WhisperTechSection are imported synchronously. They render immediately during SSR and hydrate on frame 1 for instant First Contentful Paint (FCP).
Below-the-Fold (Lazy Loaded): FeaturesSection, Features2Section, StatsSection, CallToActionSection, PricingSection, FaqSection, and NewsletterCard are wrapped in React.lazy() and Suspense.

To prevent Cumulative Layout Shift (CLS) when these components resolve, each Suspense boundary has an explicit minimum-height skeleton fallback matching the component's rendered height:

// src/components/blocks/homepage.tsx
export function HomePage() {
  return (
    <div className="flex flex-col">
      <HeroSection />
      <TrustStrip />
      <WhisperTechSection />
      <Suspense fallback={<div className="min-h-[650px]" />}>
        <FeaturesSection />
      </Suspense>
      <Suspense fallback={<div className="min-h-[550px]" />}>
        <Features2Section />
      </Suspense>
      <Suspense fallback={<div className="min-h-[300px]" />}>
        <CallToActionSection />
      </Suspense>
      {/* ... */}
    </div>
  );
}

This guaranteed 0.00 CLS while cutting the initial hydration JavaScript payload by over 40%.

Deferring Google One Tap to Idle

One of the largest contributors to mobile Total Blocking Time was Google One Tap (authClient.oneTap()). Previously, the Google Identity Services script executed during initial React hydration, spinning up iframe bridges and network checks while the user was trying to interact with the hero section.

We moved Google One Tap out of the critical rendering path by wrapping it in requestIdleCallback (with an 8-second fallback timeout) and attaching one-time event listeners to user interactions (pointerdown, touchstart, scroll):

// src/routes/__root.tsx (abridged)
useEffect(() => {
  if (!isOneTapEnabled || isPending || session) return;

  let executed = false;
  const trigger = () => {
    if (executed) return;
    executed = true;
    cleanup();
    void authClient.oneTap();
  };

  const interactionEvents = ['pointerdown', 'touchstart', 'scroll'] as const;
  for (const evt of interactionEvents) {
    window.addEventListener(evt, trigger, { once: true, passive: true });
  }

  if (typeof window.requestIdleCallback === 'function') {
    window.requestIdleCallback(trigger, { timeout: 8000 });
  } else {
    setTimeout(trigger, 7000);
  }
  // ...
}, [isPending, session]);

The result: zero main-thread interference during initial paint.

5. Layer 4: LCP & Accessibility Polish

With TTFB and hydration fixed, we addressed visual rendering timing and audit metrics:

Critical CSS Preloading: Added <link rel="preload" as="style" href={appCss} /> in src/routes/__root.tsx to eliminate stylesheet render blocking.
Hero H1 Animation Delay Removal: In src/components/blocks/hero.tsx, our primary H1 heading previously had a subtle entrance fade-in animation delay. Removing the delay allowed Lighthouse to record Largest Contentful Paint (LCP) the instant the first paint completed.
Accessibility & Contrast: Fixed aria-orientation="horizontal" on button toggle groups, added descriptive aria-label tags, and increased primary button color contrast to meet WCAG AA standards.
Descriptive Anchor Text: Replaced ambiguous "Learn more" link texts with descriptive link destinations ("Security →"), satisfying Lighthouse SEO crawlability checks.

6. The Results: Lighthouse 95+ & Core Web Vitals

After deploying these four layers, we ran Google PageSpeed Insights on scribetoany.com.

Desktop Performance: 95 / 100

On desktop devices, our score surged to 95 Performance, 100 Accessibility, 96 Best Practices, and 100 SEO, with a 3/3 score on Agentic Browsing audits.

Metric	Score / Value	Status
Performance	95	🟢 Excellent
Accessibility	100	🟢 Perfect
Best Practices	96	🟢 Excellent
SEO	100	🟢 Perfect
Agentic Browsing	3 / 3	🟢 Passed
Cumulative Layout Shift (CLS)	0.00	🟢 Zero Shift

Mobile Performance: 78 / 100

On simulated mobile networks with aggressive 4G throttling and restricted mobile CPU profiles, our performance jumped to 78 Performance, alongside flawless 100 Accessibility and 100 SEO scores:

Metric	Before Optimization	After Optimization
P75 Edge TTFB	~3,128 ms (57% Poor)	< 50 ms (Edge HIT)
Cold Worker TTFB	~3,500 ms	Bypassed for all anon visitors
Desktop Performance	~68	95 🟢
Mobile Performance	~42	78 🟡
Cumulative Layout Shift	0.03	0.00 🟢
Accessibility	92	100 🟢
SEO	90	100 🟢

Key Lessons for Full-Stack Edge Applications

Building on Cloudflare Workers and a modern full-stack React framework gives you unprecedented global reach, but edge runtimes operate under different rules than traditional Node servers:

Beware the "Fast Handler, Slow Isolate" trap: If your Worker takes 5ms of CPU time but bundle size is 10MB+, your users are waiting on V8 compilation, not code execution.
Edge Cache is mandatory for SSR: You don't need a static site generator (SSG) to get static speeds. Using Cloudflare's caches.default with build-ID key invalidation gives you static speed with all the flexibility of SSR.
Guard your cache keys with build tags: Never deploy edge caches without an automated invalidation strategy. Folding compile-time hashes into internal cache keys guarantees zero-downtime freshness.
Hydrate lazily, paint immediately: Render above-the-fold components synchronously, defer offscreen blocks with explicit height skeletons, and push heavy third-party scripts (like Google Identity Services) to requestIdleCallback.

Speed is a feature. By aligning our edge architecture with browser execution priorities, ScribeToAny now delivers an instantaneous experience to users worldwide.

Running Whisper on Modal from Cloudflare Workers

Ray Mac — Thu, 03 Sep 2026 05:32:39 +0000

A Cloudflare Worker can't run a multi-minute GPU job, and it can't open the gRPC connection Modal's Python SDK uses to spawn() one. Two hard "no"s — and yet the transcription in ScribeToAny runs on Modal GPUs while the whole web app runs on Workers. The trick is to stop treating Modal as an SDK and start treating it as an HTTP endpoint you fire-and-forget, with the GPU box calling back over a signed webhook. Here's the whole design, with the edges that actually bit.

The web app runs entirely on Cloudflare Workers; Whisper (plus an optional translation pass) runs on GPUs on Modal. Getting two runtimes with opposite shapes to cooperate was the most interesting part of the build — because the obvious way is impossible on Workers.

The constraint

A Worker is not a server. It wakes up on a request, gets a small CPU budget, and is expected to return quickly. It has no long-lived process to babysit a job that takes minutes, and it can't open the gRPC connection Modal's Python SDK uses to call Function.spawn(). Two non-starters, same conclusion:

You cannot run the transcription in the Worker. A ten-minute podcast is not a request-scoped workload.
You cannot even use Modal's normal client to start the job. There's no gRPC, no Python, no persistent socket.

The naive version — "await the transcription and return the transcript" — dies on the first point. So the design has to be asynchronous from the very first line, and the Worker's entire job shrinks to a handful of sub-second HTTP calls.

The shape of the answer

Treat Modal not as an SDK but as an HTTP endpoint. Modal lets you expose a web endpoint that, when hit, spawns the real GPU function and returns immediately. So the flow becomes:

The browser uploads the media straight to R2 (never through the Worker).
The Worker presigns a read URL, writes a queued job row, and fires one POST at Modal's web endpoint. Modal acks with a call id and starts the GPU work in the background.
When the engine finishes (or fails, or just wants to report progress), it POSTs back to a webhook on the Worker, signed with a shared secret.
The frontend polls the job row and lights up when it flips to done.

The Worker only ever does three quick things: presign, spawn, apply-callback. None of them wait on a GPU. That's the whole trick — and the rest of the work is making it survive the real world, where webhooks get lost and callbacks arrive twice.

Uploading without touching the Worker

Media never streams through the Worker — that would blow the CPU budget and buy nothing. The browser gets a presigned R2 PUT and uploads directly. We issue it intent-first: a pending row is written before the URL is signed, so an upload that's abandoned mid-flight still leaves a trace we can sweep later.

// createUploadUrl (server function) — abridged
await db.insert(userFiles).values({ id, userId, r2Key, status: 'pending' /* … */ });
const uploadUrl = await presignR2Url(r2Key, 'PUT', PRESIGN_PUT_TTL);
return { fileId: id, uploadUrl };

After the PUT succeeds the client calls finalizeUpload, which flips pending → uploaded and corrects the size from R2's HEAD (never trust a client-reported byte count). Rows that never reach uploaded are garbage-collected by a cron sweep — more on that below.

Firing the job

transcribeFile is where the async handoff happens. It checks quota, presigns a GET so the engine can read the audio back out of R2, inserts a queued job behind an atomic concurrency guard, and spawns:

const audioUrl = await presignR2Url(file.r2Key, 'GET', PRESIGN_GET_TTL);
// … insert the queued job row (atomic guard) …
await spawnTranscription({ jobId, audioUrl, /* mode, language, targetLang … */ });
return { jobId, status: 'queued' };

The spawn itself is deliberately dumb: one fetch, and it resolves the moment Modal accepts the job — not when transcription finishes.

const res = await fetch(MODAL_TRANSCRIBE_URL, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    // Modal Proxy Auth — token id/secret, not sent in the body
    'Modal-Key': MODAL_KEY,
    'Modal-Secret': MODAL_SECRET,
  },
  body: JSON.stringify({
    job_id: jobId,
    callback_url: `${APP_URL}/api/transcripts/webhook`,
    audio_url: audioUrl,
    model_size, beam_size, language,
    target_lang: targetLang, // null ⇒ no translation leg at all
  }),
});
if (!res.ok) throw new Error(`Failed to start transcription (${res.status})`);

Two things worth calling out. The callback URL is handed to the engine in the request, so the engine never has to know our topology. And the signing secret is pre-shared (a Modal secret that equals our MODAL_WEBHOOK_SECRET) — it is never put in a request body in either direction.

The callback: verify, then apply idempotently

Everything interesting now happens in the webhook. First, authenticate it. The engine signs the raw body with HMAC-SHA256 and sends the hex digest in X-Webhook-Signature. On Workers there's no Node crypto, so this is WebCrypto, and the comparison is timing-safe:

export async function verifyWebhookSignature(rawBody: string, signature: string | null) {
  if (!secret || !signature) return false;
  const key = await crypto.subtle.importKey(
    'raw', new TextEncoder().encode(secret),
    { name: 'HMAC', hash: 'SHA-256' }, false, ['sign'],
  );
  const sig = await crypto.subtle.sign('HMAC', key, new TextEncoder().encode(rawBody));
  const expected = [...new Uint8Array(sig)].map((b) => b.toString(16).padStart(2, '0')).join('');
  return timingSafeEqual(expected, signature.trim().replace(/^sha256=/, '').toLowerCase());
}

You have to hash the raw bytes, not a re-serialized object — JSON.parse then JSON.stringify will reorder keys and change whitespace, and your signature will never match. So the handler reads await request.text() and verifies before it parses.

Then apply the result. The single most important property here is idempotency, because a webhook you don't 200 fast enough gets retried, and a retried callback must not double-apply. The rule is one line: once a job is terminal, ignore repeats.

if (job.status === 'done' || job.status === 'failed') {
  return { ok: true, applied: false }; // already terminal — no-op
}

The HTTP status codes are chosen to steer the engine's retry behaviour:

Situation	Response	Why
Bad/missing signature	`401`	Reject outright
Unknown `job_id`	`200`	Ack so the engine stops retrying a job we'll never have
Applied (or already terminal)	`200`	Success
Our own DB threw	`500`	Ask the engine to retry — the callback was valid, we just fumbled it

That third row is the subtle one. An unknown job isn't an error to bubble up; it's a dead letter, and the kindest thing you can do is acknowledge it so the sender gives up.

The sharp edges

The happy path above is maybe a third of the code. The rest is everything that goes wrong when one side of an async contract can vanish.

Lost webhooks. If the engine crashes, or the callback is dropped, the job sits in transcribing forever. So a cron job reconciles: any job that's been quiet past a timeout is marked failed, and the same tick sweeps orphaned R2 uploads that never finalized. Workers cron triggers are perfect for this — it's the backstop that makes the optimistic async path safe to rely on.

Never kill a healthy job by accident. We also have a liveness probe that can ask Modal whether a call is still running. It returns a deliberately three-valued answer — running, a terminal state, or null meaning "don't know" (probe not configured, request failed, unparseable). Callers must treat null as no information and leave the job alone. Collapsing "I couldn't reach the probe" into "the job is dead" would have the reconciler executing healthy jobs the moment the probe has a bad minute.

Segments live in R2, not the database. A terminal callback does not ship the transcript inline. The engine writes segments to R2 as {job_id}.tsv; the done webhook carries only metadata (language, duration, cost, timing). The app reads the TSV on demand and generates SRT/VTT/TXT/PDF from it. Keeping thousands of cue rows out of D1 keeps the callback small and the job table narrow.

Two clocks in one job. Add the optional translation pass and a single job now finishes two things at different times. The transcript can be done while the translation is still running. So the translation update is applied before the terminal-state early-return — otherwise a translation ping arriving after the transcript finished would hit the "already terminal, no-op" branch and the translation row would be stuck at queued forever. Two independent legs, one job row, and the order of those two checks is load-bearing.

Why this is actually a good fit

It's tempting to read all this as fighting the platform. It isn't. Once the transcription is off the Worker, everything the Worker does keep is exactly what the Workers model is good at: short, stateless, I/O-bound HTTP handlers with a cron backstop and a durable store (D1 + R2) holding the state between them. The GPU box does GPU work; the edge does edge work; a signed webhook and an idempotent apply are the seam.

The constraint that looked fatal — "you can't run the job here" — turned out to be the thing that produced a clean design. The Worker never blocks, the job survives a dropped callback, and a retried webhook is a no-op. That's the whole system.

ScribeToAny is built on TanStack Start + React on Cloudflare Workers (D1 + R2), with the transcription engine on Modal. Originally posted on the ScribeToAny blog.