Choosing a Speech to Text Path in Foundry

What this slice covers

Turning audio into text looks like a single capability until you try to build with it. Azure Speech, which now reaches you as one of the Foundry Tools, offers several genuinely different routes to a transcript. They differ in latency, in how much audio they will swallow in one call, and in whether your application stands still while the service works. AI-901 does not ask you to recite method signatures. It asks you to read a described scenario — a live captioning widget, a voice note in a mobile app, an archive of recorded support calls — and pick the route that fits. Building that mapping is the whole job of this note.

Three shapes of a transcription job

The first shape is real-time recognition. Your application opens a connection, streams audio from a microphone or a file, and receives text while the speaker is still talking. This is what powers live captions and dictation. It is the route the Speech SDK quickstart demonstrates, and it is the only one where words appear on screen mid-sentence.

The second shape is fast transcription. Here you already hold a complete audio file and you want the entire transcript back from one synchronous call, as quickly as the service can produce it. Microsoft steers you here whenever the input is a file rather than a live microphone, and this route carries accuracy features you would otherwise have to assemble yourself, including identifying which language is being spoken and separating one speaker from another.

The third shape is batch transcription, which is asynchronous by design. You hand the service a set of recordings, it works through them on its own schedule, and you collect the results afterwards. Nothing in your application blocks. This is the shape for archives — a quarter of recorded calls, a media library, a compliance backlog.

The cleanest way to hold these three is as a question about who is waiting. A human watching captions is waiting in milliseconds. A user who just uploaded one recording is waiting in seconds and is staring at a spinner. A nightly job is not waiting at all, and paying for low latency there buys you nothing.

The duration boundaries that catch people out

Each route has a ceiling, and the ceilings are the single most common source of confusion. The simple recognise-once operation used in the SDK quickstart handles a single utterance of up to thirty seconds, and it will stop even earlier if it detects that the speaker has fallen silent. That behaviour is deliberate — it is built for a command or a dictated sentence, not for a meeting. The short-audio REST endpoint accepts a somewhat longer clip, up to a minute of audio in one request.

Learners routinely wire recognise-once into a transcription feature, test it on a ten-second clip, and only discover the ceiling when a real recording arrives. When the audio outruns the operation, the answer is not a bigger timeout; it is a different route. Longer, uninterrupted audio belongs to continuous recognition, to fast transcription, or to batch.

Where the audio actually comes from

The SDK separates two configurations, and keeping them distinct pays off. One describes the service — which endpoint you are calling, with which key, and which recognition language you expect. The other describes the audio source — the default microphone, or a named file on disk. Swapping a microphone-based example over to a file is a change to the second configuration only, which is why the quickstart can show both with almost identical code.

Uncompressed WAV is handled natively. Compressed containers such as MP4 are not simply opened for you: they require an additional media component on the machine plus a streaming input class that feeds the decoded audio in. Treat my MP3 did not work as a format-plumbing problem rather than a service problem.

Starting in the portal, finishing in code

The Foundry portal gives you a speech to text playground where you can upload a file, adjust the task and the language, and read the transcript directly. Two details matter for building. The playground exposes the raw service response alongside the readable transcript, so you can see the structure your code will have to parse — recognition status, offsets, durations, and the display text. It also hands you a generated code sample for the same configuration, which is the intended bridge from clicking to coding.

Mistakes people make

Three recur. The first is treating recognise-once as a general transcription API. The second is assuming that because the portal accepted a file, any file will do in code. The third is reaching for real-time streaming when the scenario has no live listener — a design that is harder to build, easier to break, and buys nothing.

One more is inherited: candidates who studied older material arrive expecting to slot speech into a broad natural language processing workload bucket. That taxonomy is not the current framing, and it will not help you choose between these routes.