◆Two files, 3.9 times apart, one subtitle
◆◆A converter label describes the file, not the subtitle. We took one 38.811-second recording and built it eight ways. The 48 kHz 16-bit WAV master and a FLAC made from the same samples produced identical TXT, identical SRT and identical VTT — SHA-256 prefixes 1e2657ba, 8f677e06 and f5564935 — while the two files sit 3.9× apart: 3,725,838 bytes against 955,272.
◆The subtitles are not merely similar. They are the same 895 bytes, the same 13 cues, the same 16 wrapped lines, the same 68.85 bytes per cue. A page that ranks for flac to text because FLAC is “lossless” is right about the audio and silent about the only output you get to keep.
- ◆◆Same result, 3.9× the bytes. WAV 3,725,838 B and FLAC 955,272 B → one SRT, 895 B.
- ◆◆Same cue count, all eight builds. 13 cues from the 3,725,838-byte master down to the 149,820-byte MP4.
- ◆◆What the file costs, per second of audio. WAV 96,002 bytes; MP3 16 kHz 3,014 bytes; SRT 23 to 24 bytes.
- ◆◆Repeatable, not a lucky run. The MP3 and the FLAC were run a second time and both reproduced all three files with the same SHA-256.
Searches taken 2026-11-01, one page of results per phrase, on seven phrases. Nothing here is a traffic estimate: the volumes below were supplied to us and are printed as given.
Questions this page gets asked
What is an audio to SRT file?
◆Numbered blocks, each with a start time, an end time and the words spoken in between, built from the speech in a recording. In our export the blocks come from the recogniser's cue list, so the file carries the shape of the speech and not of anything you set: 13 cues and 16 wrapped lines out of 38.811 seconds, in an 895-byte SRT.
Does converting a WAV to FLAC change the SRT?
No — the two SRT files were identical byte for byte (SHA-256 1e2657ba), and so were the VTT and the TXT, while the FLAC is 3.9× smaller than the WAV.
What happens if the video already has subtitles in it?
◆Nothing changes. A soft SRT track, text burned into the picture, and both at once each produced the identical 902-byte SRT (SHA-256 6730ad87). We transcribe the audio stream; we do not read an existing track and we never look at the picture.
Can I get SRT from an MP4 or an MP3?
◆Yes, the same button for both — an MP4 is opened as an audio source and the picture is not read. The subtitles came back the same shape either way: 13 cues, 3 of them wrapped to two lines, longest line 38 to 40 display-width units, none over the budget of 42.
How big is the SRT file compared with the audio?
◆895 bytes against 3,725,838 for the WAV master — a factor of 4,163 — and 1,067 for the FLAC, 167 for the MP4, 131 for the MP3. About 68.85 bytes per cue and 23 to 24 bytes per second of audio.
Does the cue count change with the format?
◆Not here: 13 cues in every one of the eight builds. Cue count follows where the recogniser broke the speech, so it moved by zero while the words inside those cues moved by ten.
Eight builds, and what each one did to the file
Everything below comes from this site's own export, captured on a real browser against the live page on 2026-11-01, one file per page load. The SRT and VTT are the bytes the page hands to the download button, not a reconstruction.
| build | audio inside | file bytes | wrong words | cues | SRT / VTT / TXT |
|---|---|---|---|---|---|
| 48 kHz WAV master | pcm_s16le, 48 kHz, mono | 3,725,838 | 15 of 89 = 16.85% | 13 | 895 / 873 / 564 B |
| 48 kHz FLAC | flac, 48 kHz, mono | 955,272 | 15 of 89 = 16.85% | 13 | identical to the row above |
| 16 kHz MP3, 24 kbit/s | mp3, 16 kHz, mono | 116,972 | 18 of 89 = 20.22% | 13 | 895 / 873 / 564 B, different text |
| 48 kHz m4a, AAC 64k | aac, 48 kHz, mono | 318,527 | 20 of 89 = 22.47% | 13 | 904 / 882 / 573 B |
| MP4, still picture | aac, 16 kHz, mono | 149,820 | 25 of 89 = 28.09% | 13 | 902 / 880 / 571 B |
| MP4 + soft SRT track | same audio, 1 subtitle stream | 150,575 | 25 of 89 = 28.09% | 13 | identical to the row above |
| MP4 + burned-in text | same audio, text in the frames | 157,350 | 25 of 89 = 28.09% | 13 | identical to the row above |
| MP4 + both | same audio, 1 subtitle stream, text in the frames | 158,105 | 25 of 89 = 28.09% | 13 | identical to the row above |
◆◆Read the third column against the sixth and the set of pages splits in two. The container is worth up to 3.9× in bytes and zero in subtitles when nothing about the samples changes. The audio stream inside the container is worth 10 wrong words out of 89 between the best and the worst build — and that is the only number on this page that a buyer of a converter would care about, which is why it is strange that no page in the set prints it.
Four MP4s, four different captions already inside, one subtitle file
The word most of this family ranks for is a word about an existing subtitle: mp4 to srt reads as “take the SRT out of my MP4”, and for many people that is exactly the job — a video exported by an editor or a platform with a subtitle track you would rather edit as text.
◆So we built all four situations on top of one MP4: the plain video; the video with a soft SRT track whose four blocks say things the speech never says; the video with a line of text painted into the frames; and one file with both. Against a single recogniser the four came back as one subtitle file: 902 bytes, SHA-256 6730ad87, 13 cues, 16 lines, longest line 38 display-width units, and 25 wrong words of 89 in every case.
◆◆Two things follow, and the second one matters more than the first.
- ◆◆An existing track is invisible to this tool. It is not read, not merged, not overwritten; the file you get is new text from the audio, and the old track is still where it was. If you wanted the track, this is the wrong button — extraction is a different operation, and one page in the set (subvideo) is the only one of the 15 that says so out loud.
- ◆◆Text painted into the picture is invisible too. The burned-in line did not add a word to the output and did not change the timing. A tool that transcribes audio cannot see writing; that sentence is worth having on a page that ranks for a word about video, because the picture is the part of a video this job never opens.
◆What that costs you is the thing no page says: if the MP4 you are holding already has a good subtitle track, exporting it and exporting a fresh transcript are two different files with two different word counts, and the cheap one is the one you did not pay for. We cannot extract a track, and we say so instead of letting you find out after the upload.
What the 15 ranking pages print about the file they hand you
◆Seven searches on ◇2026-11-01 — audio to srt, mp4 to srt, mp3 to srt, audio to text, flac to text, aac to text, mov to text — returned 101 distinct URLs across 52 hosts. Every host was fetched once; 15 returned a body worth reading (turboscribe answered with a 16-character anti-bot shell and fast-transcriber with a Cloudflare challenge, so both are counted as not read). Every fraction below is out of those 15.
| what a page could print | pages that do | example from the set |
|---|---|---|
| sells an SRT export | 14 of 15 | the one that does not (converter.app) is a raw file converter with no transcript |
| sells a VTT export | 12 of 15 | — |
| mentions timestamps | 9 of 15 | — |
| ◆prints a cue count | 0 of 15 | the two that use the word cue describe what an SRT is, not what their own file contains |
| ◆prints a reading speed | 0 of 15 | the words cps, characters per second and reading speed appear on none of the 15 |
| prints a line rule | 1 of 15 | audiosrt: “no more than 42 characters per line and two lines maximum” — no unit stated |
| ◆prints a gap rule | 0 of 15 | — |
| ◆says what happens to captions already in the file | 2 of 15 | subvideo distinguishes generating from extracting; transcript.you mentions embedded subtitles |
| prints a sample rate or a bitrate | 3 of 15 | — |
| prints an accuracy figure | 3 of 15 | any2text 98%, audiosrt quotes a figure once, sonix 99% five times |
| ◆gives a denominator for it | 0 of 15 | no page in the set uses WER, ground truth, test set or sample size |
| prints a file size for its own SRT | 6 of 15 | — |
Read the middle column down: the top of the list is a shop and the bottom is a measurement. The two rows that split it are 14 of 15 selling the export and 0 of 15 saying how many cues that export contains.
What each fraction was counted from
◆Fourteen of the 15 print a sentence selling the download and 12 name the VTT variant of it.
◆Of the 15 pages we read, 14 print a sentence selling the download and 12 print a sentence naming the VTT variant of it.
◆Zero of the 15 print the number of cue blocks in the file their own tool produces, and none of the 15 gives the boundary gaps between those blocks.
◆Zero of the 15 print how many characters per second a cue asks the viewer to read — the words cps, characters per second and reading speed return nothing across those 15.
◆One of the 15 gives a line rule (audiosrt, 42 characters, two lines) and does not state the unit, so a page on Chinese or Japanese subtitles cannot use it.
◆Two of the 15 address captions that already exist in the file: subvideo separates generating a transcript from extracting a track, and transcript.you mentions embedded subtitles.
◆Zero of the 15 gives a denominator under an accuracy claim — WER, ground truth, test set and sample size do not appear anywhere in the 15.
Three of the 15 print a sample rate or a bitrate, three print an accuracy figure, and six print the size of the subtitle file their tool hands back.
◆The shape of the gap is one sentence: ◇these 15 pages sell a file and do not measure it. Fourteen of 15 print an SRT export; one of 15 prints a line rule; none prints how many cues its own file has, how fast it reads, or what the gaps between blocks are. The one that gives a line rule (42 characters) does not say whether that is characters or width, which is the difference between a line that fits and a line twice as wide as it should be in any language that is not written in Latin letters. That number, and what it costs to get it wrong, is the subject of the timestamped transcript page; this page is about what is inside the file on the way in.
The numbers this page is built on
| what | measured | where it comes from |
|---|---|---|
| ◇corpus | 38.811 s, 89 reference words, 118 characters | two public readings joined by 0.4 s of digital silence |
| byte rate of the master | 96,002 bytes per second | 48 kHz × 16 bit × 1 channel = 768,000 bit/s |
| byte rate of the smallest build | 3,014 bytes per second | 116,972 B over 38.811 s |
| SRT byte rate | 23 to 24 bytes per second | 895 B over 38.811 s, rounded; 902 B on the MP4 builds |
| ◇SRT per cue | 68.85 bytes | 895 B ÷ 13 cues |
| lines and wrapping | 16 lines from 13 cues; 3 cues wrapped to 2 lines | the exported SRT, counted line by line |
| ◇line width | max 38 to 40 display-width units, budget 42, 0 over | recomputed independently with Python's east-asian width table |
| gaps between adjacent cues | 0 ms on every boundary, all eight builds | the SRT timestamps themselves |
| ◇cue duration | 0.500 to 4.780 s | the export clamps a cue's end to at least half a second after its start |
| reading speed | per cue 6.00 to 13.04 characters per second | characters in the cue ÷ seconds the cue is on screen |
| wall clock | 21.8 to 70.3 s for 38.811 s of audio | first build cold: 63 MiB model plus 21.5 MiB runtime inside its 67.8 s |
Eleven rows, read one at a time
◆The master's 3,725,838 bytes contain 768,000 bits every second, which is 96,002 bytes per second of audio.
◆The 149,820-byte MP4 carries its audio at 3,014 bytes per second, a factor of 31.9 fewer bytes than the master for the same recording.
◆Our SRT costs 23 to 24 bytes per second of audio: 895 bytes over 38.811 seconds, and 902 bytes on the four MP4 builds.
◆Dividing 895 bytes by 13 cues gives 68.85 bytes per cue, and those 13 cues carry 16 text lines because three of them wrap once.
◆No line in any of the eight exports reaches the 42-unit budget: the widest is 38 to 40 display-width units depending on the build, and 0 lines go over.
◆Every cue boundary in all eight builds sits at 0 ms of gap, so there is no silence between one block and the next anywhere in the eight files.
◆A cue lasts between 0.500 and 4.780 seconds, and the 0.500 s floor is the page's own clamp rather than anything the speech did.
◆Reading speed per cue runs from 6.00 to 13.04 characters per second, and the 6.00 floor is that one clamped cue, not a slow sentence.
The corpus itself is two public readings joined by 0.4 s of digital silence: 38.811 s, 89 reference words, 118 characters.
Wall clock ran 21.8 to 70.3 seconds across the runs, and the slowest one is the cold build that downloaded a 63 MiB model.
A gap of zero and a floor of six, on the same eight files
◆The 0 ms gap is a property of how the cue list is built: in all eight builds the end of one cue is the start of the next, which leaves no breath for a viewer to follow a speaker change.
◆The 6.00 cps floor is one cue, the last one, which the half-second clamp stretched; the slowest cue outside that clamp reads faster than 6.00.
Neither the gap figure nor the per-cue reading speed appears anywhere in the 15 pages, which is the whole reason this page exists.
What each of the eight builds produced, line by line
◆The WAV master gives 13 cues over 38.811 seconds: 895 bytes of SRT, 873 of VTT, 564 of TXT, and 15 wrong words of 89 (16.85%).
◆The 3.9× smaller FLAC gives the same 895, 873 and 564 bytes with the same three SHA-256 values, and the same 15 wrong words.
◆The 116,972-byte MP3 gives 895 / 873 / 564 bytes again, the same cue count, and different text: 18 wrong words (20.22%).
◆The 318,527-byte m4a gives 904 / 882 / 573 bytes, still 13 cues, and 20 wrong words (22.47%), with slowest cue 11.14 cps rather than 6.00.
◆The 149,820-byte MP4 gives 902 / 880 / 571 bytes, 13 cues, 16 lines, and 25 wrong words (28.09%).
◆Adding a soft SRT track takes the file to 150,575 bytes, and the SRT stays at 902 bytes with the same SHA-256 6730ad87.
◆Burning the text into the frames takes the file to 157,350 bytes, and the SRT is again 902 bytes with the same SHA-256.
◆Doing both takes the file to 158,105 bytes, and the SRT is 902 bytes with the same SHA-256 for the third time.
◆The MP3 and the FLAC were each run twice and reproduced their SRT, VTT and TXT with identical SHA-256 values on the second run.
What this page cannot do
- ◆◆Extract a subtitle track from a video. A soft SRT inside an MP4 is invisible here — we transcribed the audio and left the track alone, which we know because the output was identical with and without it.
- ◆◆Read text off the picture. Burned-in captions, on-screen titles and handwriting in the frame are not input. Our four MP4 builds prove it from the audio side; that is all they prove.
- Convert SRT to VTT or VTT to SRT. The picker takes audio and video. There is no
.srtor.vtton the list, and converting one subtitle format into another is a different job. - Merge a new transcript with an old track. You get a file; you do not get two tracks reconciled.
- Style or burn in. We produce the subtitle file, not a video with subtitles on it.
- Separate speakers. No cue carries a speaker label, and nothing here is a claim otherwise.
What our numbers do not cover
- ◆◆One recording, one speaker, one language, 38.811 seconds. A corpus, not a survey. A different room, microphone or accent will move every word count above.
- ◆◆The audio behind the eight builds is not identical everywhere. The WAV and the FLAC hold the same samples; the MP3, the m4a and the MP4 were re-encoded at 16 or 48 kHz. So the 10-word spread across builds is a real difference in what the recogniser was given, not a like-for-like container test — the honest reading is “the lossless pair moved nothing, and the lossy builds moved things by two to ten words”.
- ◆◆Two of the eight sit inside the 2-word band we treat as noise. The MP3 at 20.22% is exactly two words above the WAV at 16.85%; we print both and do not claim one is better.
- ◆◆Our corpus has one trailing line the builds disagree about. Three builds put the closing line on the wrong word and two lose the closing word to the silence, which is where most of the 10-word spread comes from. One recording is one sample of that behaviour.
- Three runs failed and were repeated.◆ One model download hung at 25 seconds and one browser session reported an abort; every build above is from a run that completed, and the MP3 and FLAC builds were repeated to confirm their output was identical, not merely similar.
- The burned-in caption was a single line of plain white text. A frame filled with writing, or a caption covering the speaker's mouth, was not tested, and we make no claim about either.
- No player was tested. We did not open these SRT files in VLC, Premiere or a phone, and we do not certify how they render. The page states what the files contain.
- Search volumes are printed as supplied. This page prints none of them, because the phrases in this set were not given to us with figures.
Try it on your own file
Drop an MP3, a WAV, a FLAC, an M4A, an AAC, an MP4 or a MOV on the front page, pick the language that is spoken, and wait. Press Export .SRT or Export .VTT when it finishes. The recognition runs in your browser tab, so the file never leaves your machine; the model is downloaded once at about 78.4 MiB and cached. The ceiling is 30 minutes of audio and 512 MiB per job. What comes back is the same shape we measured above: cues from the recogniser's own breaks, wrapped at 42 display-width units, floored at half a second per cue, no speaker labels, and no reading of any subtitle track you already have.