Convert audio to text

Audio-only is a first-class input here

Meeting recordings, phone calls, lecture captures, interviews and voice memos are overwhelmingly audio files. A tool built around video that accepts an MP3 as an afterthought tends to show it: a black rectangle where the picture would be, caption controls that cannot apply, and an interface insisting on a step that does not exist for you.

So an audio file gets an audio player rather than an empty video frame, and the output is pinned to a transcript because there is no picture to put captions on. MP3, M4A, WAV and anything else your browser can decode all work the same way.

Everything else is identical, because it is the same engine. The audio is decoded, resampled to 16kHz mono and handed to the same Whisper model that a video's soundtrack would be.

Why this is the case where not uploading matters most

Nobody worries much about uploading a clip of a dog. The recordings that arrive as audio files are the ones people genuinely cannot put through a web service: a client call, a consultation, a therapy session, an internal all-hands, an interview under an embargo.

The usual answer is a hosted transcription service with a privacy policy, and a policy is a promise about what someone will choose to do with a file they already hold. Here the file is not sent, so there is nothing held and no promise required. That is a different kind of claim, and the reason it can be made is that there is no server in this product at all.

It is also checkable rather than taken on trust. Open your browser's network panel, transcribe something, and watch: the only request is the model downloading to you, and you can disconnect from the network after it lands and transcribe anyway.

Long recordings, and the thing that will actually stop you

The cap is 2 hours of audio per recording, and it is a memory limit. Audio is held as 16kHz floating point samples at roughly 3.84MB a minute, in the same tab as a resident speech model. The check runs before transcription starts, so a two-and-a-half-hour recording is refused with a reason rather than after twenty minutes of work.

Below that, the thing to plan around is time rather than any limit. Transcription measured 8.6x faster than realtime on a 31-minute recorded lecture, Chrome, 16GB Windows laptop using WebGPU. Without WebGPU, the WebAssembly fallback is a great deal slower and that path has not been measured, so a long recording on a machine without it is a tab you leave running.

The tab has to stay open, which is the honest trade for there being no server doing it for you. Progress is reported in audio-seconds actually processed rather than an invented percentage, and you can stop part way and keep what has been transcribed so far.

Getting something usable out of it

A raw transcript of a meeting is rarely the end goal. What people want is a record they can search, a set of decisions, or a quote with a timestamp attached to it.

• Export Markdown for anything you will keep. The timestamps survive as text and the paragraphs stay readable
• Fix the names first. They are the errors most likely to matter and the fastest to find, because you already know which names were said
• Add speaker labels by hand if the recording is a conversation. Speaker changes sit at pauses, which are visible on the waveform
• Use the copy-for-an-assistant export rather than a plain copy if an AI is going to read it, so it is told the text is machine-made