Upload the Same File Five Times: Whether the Text Ever Changes

The question behind the test

People ask it in two different moods. Sometimes they want permission to trust a transcript: if the model is deterministic, a good result stays good. Sometimes they want an excuse to re-upload: if it is a lottery, the next draw might be better.

Both questions have the same answer, and the answer is not the interesting part. What is interesting is which things you can change and still get the same text, because that tells you where the model is actually looking.

Five uploads, one string

One file: 25.80 seconds, 44.1 kHz mono WAV, 2,275,642 bytes, five sentences read by a single synthesized voice. We sent it six times in a row and hashed the transcript field each time.

• Control run: 330 characters, 62 words, sha256 af80e95f16f00cc8.
• Repeat 1: 330 characters, 62 words, same sha256. 5.18 seconds.
• Repeat 2: 330 characters, 62 words, same sha256. 5.62 seconds.
• Repeat 3: 330 characters, 62 words, same sha256. 6.19 seconds.
• Repeat 4: 330 characters, 62 words, same sha256. 5.28 seconds.
• Repeat 5: 330 characters, 62 words, same sha256. 3.97 seconds.

Not a similar transcript. The same one, character for character, six times out of six. No reworded clause, no punctuation drift, no missing comma.

That is a stronger claim than it sounds. A model that samples its output freely would produce small variations on a clean file - a different comma placement, a contraction expanded once and kept once. Six identical hashes means the decoding here is effectively deterministic on this input.

What else did not matter

Two more single-variable changes, both with the same result.

• Renamed to a different file name, same bytes: 330 characters, identical.
• Re-encoded to 32 kbps MP3 at 22.05 kHz mono, 103,671 bytes - a 22-fold size drop: 330 characters, identical.

The rename is worth stating plainly because it is a common worry. The file name is not read as content. A file called quarterly-review.wav and a file called 2026-11-10T09-14-22.wav with the same bytes produce the same text.

That matches what this site found on a full bitrate ladder. Nine rates from 1024 kbps down to 32 kbps all returned the same 160 characters from one source. Speech survives a lot of compression.

It is not unlimited. In a separate export-route test the same day, mono at 16 kHz 32 kbps lost two characters out of 330. So the line is not bitrate - it is how far you push the sample rate and channel count down.

What did change: the wait

Same file, same bytes, six uploads: 5.18, 5.62, 6.19, 5.28 and 3.97 seconds of wall time, plus the control run. That is a 2.22-second spread on identical input.

Nothing about the audio changed between those runs. The variation is queueing, network and how busy the inference capacity was at that moment. It is the only part of this pipeline that is not reproducible, and it is the part people mistake for the model being unstable.

If a transcript comes back with different words, that is not load. Something in the file is different. In our tests it took a channel or sample-rate change to do it.

Why determinism is useful to know

It changes what you do when the result is bad. If the text is wrong, re-uploading the same file will hand you the same wrong text. That is not a failure of the tool; it is what makes the result checkable. You can compare two runs and know that any difference came from the file.

• Wrong words from a clean file: fix the recording, not the upload. A retry returns the same text.
• Empty transcript: something about the audio is outside what the model accepts. A retry will fail the same way.
• Different text after you re-exported: the export changed something that matters, and the channel and sample rate are the first things to check.

This is also why an accuracy number can be quoted honestly. A system that returns a slightly different answer each time cannot be measured on one file. A system that returns the same answer can be.

The limit on this result

Six runs of one file is not a proof of determinism across all inputs. It is evidence for this input, at this length, on this day. A longer recording has more places for a boundary decision to land differently, and a noisier recording has more places where the model has to choose.

What we can say is narrower. On a clean 25.8-second clip the output was bit-identical six times. That sets the expectation: if your file is clean and your result moved, look at what else changed.

The other limit is that this is a single endpoint on a single model. Other tools may sample more freely. The test here is about what this page does, and it is written down so you can run it yourself.

What to do with it

If it is wrong, stop re-uploading and go look at the audio. Check the sample rate and the channel count. Listen for a second conversation. Confirm the file has speech in it at all.

If you do re-upload after changing something, the diff is meaningful. Same file twice giving the same timestamp-zero text tells you the model is stable. A different result after you changed the export tells you which knob mattered.

And when the upload feels slow, remember the spread here. 2.22 seconds between the fastest and slowest run of the same 2.28 MB file, with nothing else different.

Your upload does leave the browser. It is posted to the transcription endpoint over an encrypted connection, processed in memory once, and discarded when the text returns. Nothing is stored between runs, which is part of why the same bytes give the same text rather than a cached copy.