How Live Transcription Works

This reference goes deeper into the mechanics behind Swiftscore's live transcription: how audio is captured and converted to text, what happens when something goes wrong mid-observation, and what guarantees you have around accuracy and data persistence. For a feature-level overview of the transcript view, speaker labels, filtering, and notes, see Live Transcription.

Capture approach

Swiftscore is built around a record-then-transcribe capture model: audio is recorded for the duration of the observation, and transcription is generated from that recording. This approach is designed to maximize reliability — because the full audio is captured first, a transcription hiccup partway through a session does not mean lost content. If a transcription step needs to retry or fall back to a different method, it can do so against the complete recording rather than a partial, in-progress stream.

A live-streaming mode is also supported as a secondary capture path, which is what produces the line-by-line transcript you see building in real time during the observation. Whether you're watching the transcript populate live or reviewing it shortly after you stop recording, the underlying goal is the same: get you an accurate transcript without requiring you to babysit the technology.

Speech-to-text processing

Speech recognition is handled by automated speech-to-text processing tuned for real-time and near-real-time use. In typical conditions — a reasonable microphone and normal classroom background noise — you should expect:

Words to begin appearing within roughly a second of being spoken during live capture.
A transcript accurate enough to support reliable downstream review, search, and AI-assisted analysis, including quoting specific moments from the lesson.

No transcription system is perfect, especially with classroom acoustics, overlapping speakers, or accents the system handles less confidently. If a portion of the transcript looks off, you can review it against the audio and correct it manually.

Automatic fallback handling

Transcription reliability depends on having more than one path to a finished transcript. Swiftscore is designed to try multiple transcription providers in sequence: if the primary speech-to-text service is unavailable or fails partway through, the system automatically attempts the next available provider rather than simply giving up. This fallback chain runs behind the scenes — you don't need to do anything to trigger it.

If every automated transcription path is unavailable, Swiftscore will not silently lose your audio. Instead, you're given a clear option to fall back to uploading the audio for transcription later, or to proceed with text-only notes for the observation. Your recorded audio is preserved in this scenario so you can retry transcription afterward.

Handling connection issues mid-session

Because live transcription depends on a live connection while you're recording, the system is built to handle common disruptions without losing your session:

Brief connectivity drops. If your connection to the transcription service drops mid-observation, Swiftscore attempts to reconnect automatically and resume where it left off, rather than restarting the transcript from scratch.
Backgrounded or inactive browser tabs. Some browsers reduce activity for tabs that aren't in focus. If this affects the live connection, transcription resumes cleanly once the tab is active again.
Authentication refresh. Sessions are re-authenticated transparently in the background as needed, so a session timeout mid-observation doesn't interrupt your recording.
Microphone access issues. If microphone permission is denied or unavailable, you'll see a clear, actionable message rather than a silent failure — the system won't keep retrying against a microphone it can't reach.

Speaker identification

Speaker separation (distinguishing one speaker's voice from another, such as teacher versus students) runs automatically as part of transcription for both live and uploaded audio, with no extra step required and no impact on how quickly words appear. If your school or district prefers transcripts without automatic speaker separation — for example, in particularly noisy classroom settings where it tends to be less reliable — this can be turned off at the organization level on request.

Accuracy and data handling

Transcripts include word-level detail (not just the text, but how the text breaks down over time), which supports features like searching within a transcript and reviewing specific moments.
Your final transcript is saved when you stop recording, and the underlying captured audio is retained as part of the observation record, supporting both review and, if ever needed, re-processing.
Because of the record-then-transcribe approach, a transient transcription failure does not mean your observation is lost — the audio itself remains the source of truth until a complete transcript is successfully produced and saved.

What this means for you in practice

You don't need a perfect, uninterrupted internet connection to trust the system — brief drops are handled automatically.
If your primary transcription path has an outage, you'll still end up with a transcript (or, at worst, audio you can transcribe later) rather than nothing.
Speaker labels and word-level detail are available without any manual setup.
If something does go wrong, Swiftscore tells you clearly rather than failing silently, and your recording is preserved so you don't have to redo the observation.