MP3 to SRT: the bitrate you export does not reach the subtitle file

◆Eight deliveries of one recording, and what each one did

One 52.469-second recording, built eight ways in ffmpeg, each run through this page on 2026-11-08 in a fresh browser profile with one file per page load. The SRT and VTT are the bytes the export buttons hand to the download, captured by wrapping URL.createObjectURL, not a reconstruction. Reference text is 133 words; wrong words are substitutions plus deletions plus insertions against that reference, computed by a separate alignment script rather than taken from the page.

◆Two rows in that table are the same file at different sample rates: 44.1 kHz and 8 kHz, both at 32 kbit/s, and 610 bytes apart in size. They are 6 words apart, and the 8 kHz one also carried one more insertion than the other (5 against 4). That is the largest real difference in the set and it belongs to bandwidth, not to file size. Going the other way, the ten times bigger row against the cheapest one (2,101,332 against 210,250 bytes) is one word worse in this run, which is inside the run-to-run spread discussed further down.

The 85.7 seconds on the first row is a cold run: 21 of those seconds are the one-time 63 MiB model plus 21.5 MiB runtime download. The other seven ran on a warm profile and their times are single observations, not a benchmark.

◆The one change that clearly lost words was not the bitrate

Sort the eight by words right and the picture stops looking like a bitrate story. Three deliveries sit at 118, one sits at 119, two sit at 117, and two sit at 113 — and the two at the bottom are the narrowband file and the file with half a second of silence glued to the front.

◆The narrowband file is the cleanest single variable in the set. It is a 32 kbit/s mono MP3, the same bitrate as the cheapest delivery in the table, and within 610 bytes of the same size (210,860 against 210,250). The only thing that differs is that the samples were resampled to 8,000 Hz before encoding. It lost 6 words against the 44.1 kHz file at the same bitrate, and its SRT is 2 bytes larger.

◆The words it got wrong are the signature of narrow bandwidth rather than of a cheap encoder. It is the only delivery that printed a word nobody said: where the reference has the two words jingle of, the 8 kHz transcript has three, one of them invented. It lost the word pair jingle / jingo to a single substitution, and it turned a family name into a near-rhyme and a common word into a homophone where the wideband encodes at the same bitrate did not. None of those five appeared on the 64, 128 or 320 kbit/s rows.

• ◆Same bitrate, different bandwidth. 32 kbit/s at 8 kHz: 113 of 133 right. 32 kbit/s at 44.1 kHz: 119 of 133.
• ◆Same bandwidth, ten times the bitrate. 44.1 kHz at 32 kbit/s: 119. At 320 kbit/s: 118.
• ◆What a telephone-style file costs. 6 words out of 133, the largest gap between any two rows in the table.

◆So the practical answer to mp3 to srt is not the one the pages ranking for the phrase give. It is: check that the file carries the full speech band; the encode rate above that is nearly free to ignore. A voice memo exported at 8 kHz for size is a worse input than the same voice memo exported at 32 kbit/s and 44.1 kHz, even though the two files are the same size to the kilobyte.

◆Half a second of silence at the front moves the clock by half a second

The eighth delivery is the cheapest file with 0.500 seconds of digital silence glued to the front — the shape a file takes when a recorder starts before anybody speaks, or when a clip is padded for an editor. It is 1,986 bytes larger than the same file without the silence, which is what 0.500 seconds at 32 kbit/s costs.

◆The subtitle does not shift by 0.500 seconds, and it does not refuse the silence either. The first cue still starts at 00:00:00,000, the last cue now ends at 00:00:52,970 instead of 00:00:52,470, and the cue count is still 20. The file simply covers 0.500 seconds more audio at both ends of the same grid.

◆What did move is the words: 22 wrong against 18 for the identical audio without the silence. That is four words, outside the 3-word band we treat as run-to-run noise, so we print it as a result and do not offer an explanation for it. The same run also produced 2 insertions instead of 4 and the same single deletion, so the two transcripts are not the same text with a shifted start — they are different decodes of the same speech.

◆The honest reading of that row is a warning about how the pages ranking for this phrase talk about quality: if half a second of digital zeros in front of the speech can move the wrong-word count by four out of 133, then any page quoting a single accuracy figure for mp3 to srt without a fixed input and a fixed reference is quoting a number nobody can reproduce. We publish the input, the reference and the alignment instead.

◆What the 15 ranking pages print about the file they hand back

◆Four searches on ◇2026-11-08 — mp3 to srt, mp3 to srt converter, mp3 to srt free, transcribe mp3 to srt — returned 60 result slots across 21 hosts. Two hosts answered HTTP 403 to every user-agent layer we tried (turboscribe twice, fast-transcriber once) and one result was a car badge, so 15 pages were read for this count. Every fraction below is out of those 15.

◆The gap that shaped this page is in the seventh row. Four of the 15 name a bitrate, and the two that go into detail point the same way: AudioSRT grades 320 kbit/s as “near-lossless”, 192 as excellent, 128 as still very high and “64 and below” as the point where accuracy drops; Sonix recommends 128 kbit/s or higher and warns that files below about 96 kbit/s may introduce artefacts. Neither prints a number for any of those grades. We ran the experiment, and on our material the advice held at the bottom of the range and not at the top: the 32 kbit/s file was one word better than the 320 kbit/s one, and the delivery that lost six words was the one nobody warns about, the 8 kHz file.

◆Repeatability, and why we do not report a four-word gap

◆Each of the eight deliveries was run once. The pattern that matters most — three identical subtitle files from three different bitrates — does not depend on a tolerance, because it is a byte comparison: bc6824a4 three times, with 1,390 bytes of SRT, 1,347 bytes of VTT and 719 bytes of TXT each. Two other pairs came back byte-identical for a reason we can name too: the VBR file and the 24 kHz file are different encodes of the same samples and landed on the same 1,391-byte SRT (SHA-256 a4d96743) and the same 1,348-byte VTT.

◆The word counts that differ by one are a different kind of evidence. 119 against 118 is the sort of gap this recogniser has produced between runs of the same file before, which is why the page does not claim that 32 kbit/s is better than 128. It claims only what a byte comparison supports: the three files from 64 kbit/s upward are the same file.

◆Where the page does take a position is the 6-word and 4-word gaps, which sit outside that band. Those are reported as results of this material on this day, with the exact inputs published, and not as a law. Anyone can rebuild the eight files: the script, the eight ffmpeg commands and the audio they were cut from are the same ones used for every other measurement on this site.

Questions this page gets asked

Does the bitrate of my MP3 change the SRT file?

Not once it is high enough to decode the same words. A 64 kbit/s mono MP3, a 128 kbit/s mono MP3 and a 320 kbit/s stereo MP3 of one 52.469-second recording returned one identical subtitle file: 1,390 bytes, SHA-256 bc6824a4, 20 cues, 118 of 133 reference words right. The three audio files are 420,300, 840,558 and 2,101,332 bytes apart, 5.0 times over. At 32 kbit/s the SRT changed by 5 bytes and the word count by one, in favour of the cheaper file.

What bitrate should I export before converting to SRT?

Above whatever your encoder needs to keep the words, which on our material was 64 kbit/s mono. Everything from 64 up produced the same subtitle. Going to 320 kbit/s stereo added 1,260,774 bytes to the audio over the 128 kbit/s file and zero bytes to the subtitle. The three identical runs took 37.4, 30.2 and 25.9 seconds here, one observation each, which is not a ranking of encodes.

How many cues will an MP3 produce?

Cue count follows where the recogniser breaks the speech, not the format, the bitrate or the length of the transcript. All eight deliveries of the same 52.469 seconds came back with 20 cues. Six of the eight wrapped at least one cue onto a second line; the longest line was 42 display-width units, the budget this site wraps to, and no line went over it.

Does a silence at the front of the MP3 move the subtitles?

The first cue still starts at 00:00:00,000 and the last one sits 0.500 seconds further along, because the file is 0.500 seconds longer. Half a second of digital silence in front of the speech took the wrong words from 18 to 22 out of 133 in this run, which is outside the 3-word band we treat as run-to-run noise, so we report it and do not explain it. The subtitle file grew by 2 bytes, and the transcript this run printed itself was one word shorter.

How big is the SRT compared with the MP3?

Small enough that the audio choice dwarfs it. The 128 kbit/s MP3 is 840,558 bytes and its SRT is 1,390 bytes, which is 0.165% of the file. At 320 kbit/s the same SRT is 0.066% of the file, and it did not change at all.

What does 8 kHz do to the words?

It is the one delivery that made a real difference, and the low bitrate is not what did it. An 8 kHz mono MP3 at 32 kbit/s and a 44.1 kHz mono MP3 at 32 kbit/s are both 32 kbit/s and about 210,000 bytes; the 8 kHz file came back with 113 of 133 words right against 119 for the 44.1 kHz file, 6 words apart, with 5 insertions against 4. Narrowband audio is the cost, not the file size.

Can I get SRT from an MP3 without uploading it?

Yes. The file is opened in the tab, decoded there and handed to a recogniser running in the same tab; zero bytes leave the device. There is no account, no minute allowance and no per-file limit on this page. What it does cost is time on your own machine, and the table below prints how long each of the eight deliveries took here, including the one cold run that paid for the 63 MiB model download.

Where does the credit line in the exported file come from?

The export buttons add one line naming this tool, and there is a checkbox above them that removes it before the file is written. The measurements on this page were captured with that checkbox in its default state, so the sizes below include the credit line. Turn it off and every SRT here gets shorter by the same number of bytes.

Where these numbers come from, and where they stop

• ◆The input. One 52.469-second recording assembled from three clips already used across this site’s measurements: a clean synthetic sentence (33 words), a lightly noisy reading (32 words) and a heavily noisy reading (68 words), joined with 0.300 seconds of silence between them. 133 reference words in total.
• ◆The deliveries. Eight ffmpeg encodes of those samples: MP3 at 32, 64, 128 and 320 kbit/s, one VBR encode, one 8 kHz encode, one 24 kHz encode, and the 32 kbit/s file with half a second of digital silence in front.
• ◆The run. A real Chrome instance with a throwaway profile, one file per page load, against the live page on 2026-11-08. The SRT and VTT bytes were captured from the object URL the page itself creates when the export button is pressed.
• ◆The scoring. A separate alignment script compares the transcript with the 133-word reference and counts substitutions, deletions and insertions. The page’s own word counter reports 135 to 137 words because it counts the tokens it printed, contractions and all; both numbers are printed in the CSV.
• ◆What this does not cover. One speaker, one language, one room, 52 seconds. Every MP3 was encoded by us from the same source, so nothing here was downloaded from a phone, a recorder or a platform. The 15 competitor pages were read, not run — not one of them was given these eight files.
• ◆What we did not measure. No volume or loudness normalisation, no VBR-versus-CBR test on anything but this one pair, no files longer than a minute, and no listening test of the resulting subtitles.