Muse Voice Transcribe makes an impressive promise: speech can become text while a person is still talking. Meta introduced the model on September 1, 2026 as its first real-time audio perception model, combining streaming automatic speech recognition, speaker diarization, and endpointing. Those capabilities can make dictation, live notes, voice agents, and in-progress captions feel much more responsive.
But a responsive transcript is not automatically a caption file.
An SRT or WebVTT file is a timed publishing artifact. It needs stable wording, cue-level start and end times, readable segmentation, correct speaker treatment, relevant non-speech information, and a review process tied to the original recording. A stream of low-latency words may be a valuable first signal, but it does not by itself satisfy those requirements.
That distinction is central to how Whisper Web approaches speech to text. The useful deliverable is not the first text a model emits. It is the version a person can search, replay, correct, organize into timed passages, and export for the next job. This guide explains where Muse Voice Transcribe fits, what remains between a live hypothesis and SRT or VTT, and how to build a caption workflow that preserves evidence all the way back to the audio.
The short answer
Muse Voice Transcribe is optimized to perceive speech in real time. According to Meta's official launch article, it processes audio in 80-millisecond chunks and decides whether to keep listening or emit a text token. Its adaptive-delay system can wait longer when a word is difficult and move faster when the acoustic context is clear. The same model family also produces speaker-turn and speech-end signals.
SRT and WebVTT solve a later problem. They tell a media player exactly what text to show, when to show it, and—in WebVTT's case—optionally where or how to place it. Their cues should use final, reviewed language rather than unstable partial hypotheses. Captions also need meaningful sounds and speaker identification when those details are necessary to understand the media.
The practical pipeline is therefore:
- Preserve or record the source media.
- Generate a live or batch transcript.
- Finalize and time-align the words.
- Review terminology, numbers, speakers, and meaningful sounds against playback.
- Segment the approved text into readable cues.
- Export SRT or WebVTT.
- Watch the captioned program from beginning to end and correct the file.
Muse can improve the first-response portion of that pipeline. It does not eliminate the rest.
What Muse Voice Transcribe actually provides
Meta describes Muse Voice Transcribe as an autoregressive multimodal model in the Muse Spark family. Audio arrives at 12.5 chunks per second, with each 80-millisecond chunk represented as a soft token. At each step, the model can request the next audio chunk or emit text. When the stream ends, an empty-audio token tells the model to finish the remaining text.
That listen-or-write design is the basis of adaptive delay. Fixed-delay systems make the same latency compromise for every word. Muse can use more context for an ambiguous phrase and less for an obvious one. Meta says it trained this behavior with reinforcement learning that combines a word-error-rate reward with a delay reward.
Meta also uses special output tokens for two related tasks:
- Diarization: start-of-turn and speaker tokens indicate that the voice may have changed and assign an anonymous speaker label.
- Endpointing: speech-onset and speech-endpoint tokens indicate when speech begins and when a turn appears to be complete.
The launch page says the model supports diarization with more than 20 speakers, was trained across more than 70 languages with 25 extensively verified for the initial release, handles code-switching, and can use language, keyword, and context biasing. Meta also demonstrates a conversation longer than one hour. These are provider claims about the model and its launch demonstrations, not guarantees for every microphone, accent, room, API mode, or production workload.
Meta reported that Muse ranked first on the Artificial Analysis streaming speech-to-text leaderboard and on the public diarization comparisons shown at launch, with model inclusion and rankings dated September 1, 2026. The Artificial Analysis streaming methodology matters when interpreting that statement: its index uses roughly eight hours of audio, weighted across AA-AgentTalk, VoxPopuli, and Earnings22, and its final-transcript latency begins at a detected end of speech. It is a useful controlled comparison, but it is not a promise that every real meeting, lecture, or location recording will behave like the benchmark.
Muse Voice Transcribe is available through the hosted Meta Model API and also powers dictation in Meta AI for Mac and Muse Code. Launch reporting lists the API price as $3 per 1,000 audio minutes, or $0.18 per hour. Pricing and access conditions can change, so an implementation should confirm the current Meta developer page rather than hard-code a launch-day number into a permanent budget.
For readers who want model context and a usable browser workflow without confusing the two, the independent Muse Voice Transcribe guide and online workspace explicitly separates Meta's model claims from its own transcription product. Muse Voice is not affiliated with Meta and says its current browser workspace is not powered by Meta's Muse Voice Transcribe API.
Three different artifacts: live text, transcript, caption file
The easiest way to design the workflow is to stop using transcript as a name for every text-shaped object.
| Artifact | Primary job | Can it change? | Timing required? | Ready to publish? | | --- | --- | --- | --- | --- | | Live hypothesis | Give immediate feedback while speech arrives | Frequently | Approximate turn timing may be enough | No | | Reviewed transcript | Preserve the meaning of the recording in corrected text | Only through deliberate edits | Passage or word timing is highly useful | Sometimes, as a document | | Caption file | Synchronize readable text and meaningful audio information with media playback | Should be versioned and controlled | Cue start and end times are mandatory | Yes, after QA |
A live partial can revise itself as more audio arrives. A phrase such as “recognize speech” may begin with a plausible but wrong interpretation and settle only after the next syllable. That behavior is normal in streaming ASR. Displaying the partial is useful; treating it as an immutable subtitle is not.
A reviewed transcript has a different contract. The reviewer needs to know which passages are automatic, which words have been corrected, which speaker labels are uncertain, and how to return to the corresponding moment in the recording. A transcript can preserve paragraphs and turns without deciding how many characters a viewer should read during a two-second shot.
A caption file adds the presentation layer. Each cue needs boundaries, text, and an intended relationship to the visual frame. Captions may also identify a speaker or describe music and sound effects that carry meaning. The file must survive import into a player or editor, not merely look right in the transcription interface.
Why endpointing is not caption timing
Endpointing answers a conversational question: has the speaker probably finished this turn? Caption timing answers a presentation question: when should this particular block of text appear and disappear?
Those questions overlap, but they are not equivalent.
Suppose a speaker delivers a 24-second answer without a long pause. A voice agent may need only one endpoint at the end so it knows when to respond. A caption editor may need eight or ten cues within the same answer so viewers are not asked to read an entire paragraph at once. Conversely, a dramatic pause may belong inside one sentence; splitting mechanically at every silence can damage meaning and rhythm.
Word or segment timestamps create better raw material for caption timing because they keep text attached to acoustic events. Even then, timestamps are measurements, not editorial decisions. A good cue boundary usually respects several signals at once:
- the actual start and end of the spoken phrase;
- grammatical and semantic boundaries;
- changes of speaker;
- shot changes and important visual information;
- the time a viewer needs to read the cue;
- continuity with the cues before and after it.
Meta's public launch article does not claim that Muse emits ready-made SRT, WebVTT, or word-level timestamps. A detailed independent review of the current API documentation and behavior reports that the launch API does not return word timestamps, formatted caption files, or confidence scores, and that its diarization and endpointing modes are selected separately. Those API details should be rechecked against Meta's live developer documentation before building because preview services evolve quickly.
The important design conclusion is stable even if the API later adds more metadata: endpoint events should not be stretched into cue timings by dividing a turn evenly. Alignment should come from the audio.
What SRT and WebVTT require
SRT is a widely supported, deliberately simple subtitle format. A typical cue contains a numeric identifier, a start and end timestamp separated by an arrow, and one or more lines of text:
17 00:01:12,400 --> 00:01:15,200 We should verify the speaker name before publishing the interview.
WebVTT is a web standard defined by the W3C. It begins with a WEBVTT header, uses a period rather than a comma for fractional seconds, and supports cue settings, regions, voice spans, styling hooks, chapters, descriptions, and other time-aligned metadata:
WEBVTT 00:01:12.400 --> 00:01:15.200 We should verify the speaker name before publishing the interview.
The W3C WebVTT specification defines a cue as time-aligned text or data with a start timestamp and an end timestamp that is later than the start. Cues are ordered by start time. WebVTT can also position and align cue boxes, but extra layout instructions should be used intentionally and tested in the target player.
Neither format can infer whether the words are correct. A syntactically valid file can still display the wrong name, cover a lower-third graphic, omit an off-camera speaker, drift away from the audio, or remain on screen across a scene where it no longer belongs.
That is why caption quality is broader than ASR accuracy. The FCC has described four dimensions of caption quality—accuracy, synchronicity, completeness, and placement—in its closed-captioning best-practices materials. Those dimensions are a useful editorial checklist even when a particular project is not governed by the FCC rules.
A reviewable workflow from speech to captions
1. Define the deliverable before transcription
Start by identifying the destination. A searchable interview transcript, live event captions, social-video subtitles, broadcast captions, and a multilingual subtitle package have different requirements.
For prerecorded video, decide whether you need SRT, WebVTT, burned-in open captions, or a platform-specific format. Confirm frame rate, media duration, language, speaker-identification rules, and whether the destination player preserves WebVTT positioning. If captions will be translated, establish a reviewed source-language transcript first; translating an ASR error merely reproduces the error in another language.
2. Preserve one authoritative media file
Keep the original recording or a controlled mezzanine copy as the source of truth. Give it a stable identifier and record its exact duration. Do not build final cues against one edit and attach them to another.
If the picture edit changes, captions may need to be conformed: timings shift, lines disappear, and phrases move across cuts. Keeping the approved text linked to media timestamps makes that work auditable. It also lets a reviewer settle disputes by listening instead of guessing from prose.
3. Use live output for immediacy, not finality
Muse Voice Transcribe's most interesting role is at the front of the workflow. A producer can see speech appear quickly during a recording, a host can notice that a name was misunderstood, or a live operator can monitor speaker turns. Keyword and context biasing may help with expected terminology, but a hint is not proof that the resulting word is correct.
Store final transcript events separately from partial events. Do not append every partial string to a document, because many streaming systems revise earlier text. Preserve event IDs, turn IDs, speaker labels, and source timing when the API supplies them. Log the model identifier and configuration used for the job so a later evaluation can reproduce the result.
For consequential material, a partial transcript should never trigger publication or an irreversible action. Wait for final events, then review the recording.
4. Run a timestamp-capable final pass
If the live system does not provide word timing, process the authoritative recording through a timestamp-capable transcription or forced-alignment stage. This can be a separate speech-to-text model, an aligner that maps an approved transcript back to the waveform, or the timing system already built into a transcription workspace.
This is where a two-pass architecture can be useful:
- Pass one: low-latency streaming text for monitoring, search, and immediate feedback.
- Pass two: stable final text plus word or segment timing for review and caption construction.
The passes can disagree. Do not silently choose whichever string looks better. Compare differences around names, numbers, negation, acronyms, code-switches, and overlapping speech, then replay those regions. The goal is one approved transcript tied to the audio, not a collage of unexplained model outputs.
Whisper Web does not currently claim a built-in integration with Meta's Muse Voice Transcribe API. Its present value is the review side of the problem: the Audio Transcript Studio keeps playback, searchable timed passages, corrections, subtitles, export, and controlled follow-up around the same recording. A team experimenting with Muse would still need to design and validate the handoff into any later alignment or editorial system.
5. Correct the text before designing cues
Reviewing after cue segmentation creates duplicate work: one wording change may affect several subtitle blocks and their reading time. First approve the transcript at the word and speaker level.
Prioritize the errors with the highest consequence:
- personal names, company names, and product terminology;
- dates, times, prices, measurements, percentages, and addresses;
- negative constructions such as “did” versus “did not”;
- quoted statements and contractual commitments;
- acronyms, technical terms, medications, and legal language;
- language switches and words rendered in the wrong writing system;
- short responses such as “yes,” “no,” and “right,” especially during overlap.
Search is useful for repeated terminology, but every replacement needs context. A global find-and-replace can turn one correct phrase into many new mistakes.
6. Verify speakers and meaningful sound
Diarization labels voices; it does not know a person's real-world identity unless that identity is established elsewhere. “Speaker A” should become a person's name only after the reviewer has evidence. In meetings, interviews, and panels, a wrong label can falsely assign a decision or quotation even when every recognized word is correct.
Captions also carry more than dialogue. The W3C definition of captions includes synchronized equivalents for speech and the non-speech audio needed to understand the program, such as relevant music, laughter, sound effects, and speaker identification. WCAG 2.2 requires captions for prerecorded synchronized media at Level A and for live synchronized media at Level AA, subject to the stated exceptions; see the WCAG 2.2 time-based media criteria.
Do not describe every incidental sound. Include audio information when removing it would change the viewer's understanding: an unseen door slam, an alarm, ironic applause, a speaker continuing off screen, or music whose lyrics or mood carries the scene.
7. Segment for reading, meaning, and picture
Once the wording is approved, form cues around complete ideas. Avoid leaving an article or preposition stranded at the end of a line when a natural reflow is available. Keep a speaker change visually clear. Do not reveal a punchline, answer, or plot point several seconds before it is spoken merely because the words were available in a transcript buffer.
There is no single universal character count or cue duration that suits every language, audience, screen, and platform. Treat house-style numbers as constraints to test, not laws of reading. A narrow vertical video, a classroom lecture, and a fast two-person exchange need different line breaks.
For every cue, inspect:
- Entry: Does the text appear with the corresponding speech, not long before it?
- Exit: Does it remain long enough to read without hanging over unrelated action?
- Segmentation: Is the phrase understandable on its own and across the next cue?
- Line breaks: Do breaks follow syntax and preserve names or fixed phrases?
- Speaker change: Can the viewer tell that a new person is speaking?
- Placement: Does the cue avoid faces, labels, demonstrations, and other important graphics?
- Continuity: Is there distracting flicker or an unnecessary gap between connected cues?
8. Export from the reviewed state
The export must be generated from the corrected transcript, not from the original ASR result cached at job creation. Version the output alongside the media revision and language, for example interview-v12.en.vtt rather than captions-final-final.vtt.
For teams that want to test this editorial stage without building a Meta API client, the independent Muse Voice speech-to-text workspace accepts audio, video, browser recordings, or media URLs, then lets users review timed text and speaker labels before exporting TXT, DOCX, PDF, SRT, VTT, or JSON. That workflow is separate from Meta's model; using it is not a test of Muse Voice Transcribe's API accuracy.
Whisper Web follows the same review-before-export principle. Its Speech to Text AI workspace supports file, recording, and URL intake, while the transcript tools keep corrections connected to playback and timed output. The product workflow matters because a caption is only trustworthy when the human-approved state is the state that gets exported.
Validate the file, then watch the program
Automated validation should catch mechanical defects before a person starts playback:
- invalid or missing headers;
- malformed timestamps;
- an end time earlier than a start time;
- cues out of chronological order;
- unintended overlaps;
- cues outside the media duration;
- empty cues or unsupported markup;
- encoding problems and replacement characters;
- duplicate cue identifiers where uniqueness is required;
- suspiciously long text or extremely short display windows.
Mechanical validity is only the first gate. Import the actual file into the actual destination player and watch it at normal speed. Test a mobile-sized viewport as well as desktop or television layouts. Check the beginning and end of the program, scene cuts, rapid exchanges, overlapping speakers, music, silence, and any section that was edited after transcription.
For high-value work, use two review passes with different purposes:
- Content pass: words, speakers, punctuation, meaningful sound, and completeness.
- Presentation pass: timing, reading rhythm, line breaks, placement, and player compatibility.
The reviewer should be able to click from a questionable cue back to the matching audio. That short feedback loop is more reliable than editing a detached text file from memory.
Measure the workflow, not just the model
Word error rate is useful for comparing recognized text to a reference, but it cannot measure the entire caption deliverable. A practical evaluation should combine model, editorial, and playback metrics.
Recognition and attribution
- Word error rate on representative recordings
- Accuracy of names, numbers, and domain terms
- Speaker confusion and missed speaker changes
- Behavior during overlap and background noise
- Code-switching and writing-system consistency
Timing and presentation
- Time from speech to first partial text
- Time from detected speech end to stable final text
- Alignment error at cue entry and exit
- Percentage of cues requiring manual retiming
- Reading-speed and line-length exceptions under the chosen house style
- Placement conflicts with important on-screen content
Editorial effort
- Reviewer minutes per finished media minute
- Corrections per thousand transcript words
- Speaker-label corrections per hour
- Cues resegmented after automatic generation
- Defects found in final playback QA
A lower WER can reduce editing, but it may not reduce cue work. A model can recognize every word correctly and still produce no usable word timing. Another can return good timings but unstable speaker labels. Measure the part of the pipeline that consumes human time and creates publishing risk.
When a hybrid workflow is worth it
A two-pass design adds cost and engineering complexity, so it should solve a real need.
Use a live-plus-final workflow when:
- viewers or operators need text while the event is happening;
- a voice interface must react promptly to completed turns;
- the recording will later become a polished video, course, interview, or archive;
- speaker attribution matters during the session and after it;
- the final deliverable needs accurate cue timing, SRT, or WebVTT;
- the organization can preserve the recording and reconcile two outputs responsibly.
A simpler batch workflow is usually better when no one needs immediate text. Upload the completed media once, generate timed text, review it, and export. Fewer components mean fewer reconnection cases, fewer transcript versions, and a clearer source of truth.
For live-only captions, the balance shifts again. Partial results may be unavoidable, and WCAG distinguishes live captions from prerecorded captions. The operator should label automatic output honestly, monitor failures, and retain a path for corrections if the recording will remain available later. A real-time stream can serve the event; the archived video should receive a reviewed caption file.
Privacy, consent, and operational control
Speech data may contain identities, confidential meetings, customer details, health information, or legally sensitive statements. A caption pipeline should document where audio travels, which service receives it, how long raw media and derived text are stored, who can access them, and how deletion works.
Meta's launch-page microphone demo states that its demo audio is processed to produce the transcript and is not stored. That notice is scoped to the demo; it should not be generalized to every API account, Meta AI for Mac, or third-party application. Review the current service terms and the controls attached to the actual account before uploading sensitive recordings.
Consent matters independently of storage. Confirm that the person operating the workflow has permission to record, transcribe, identify speakers, and publish captions. Use anonymous speaker labels until identities are verified. Do not let an automatic transcript become an authoritative legal, medical, employment, or financial record without appropriate human review.
Operationally, preserve:
- the media version used for alignment;
- the raw model response when policy permits;
- the model and configuration identifiers;
- the reviewed transcript revision;
- the exported caption file;
- the reviewer and approval timestamp;
- a change history for post-publication corrections.
That evidence makes caption quality maintainable instead of accidental.
Final recommendation
Muse Voice Transcribe is important because it brings streaming recognition, speaker turns, and endpointing into one real-time model design. Meta's adaptive-delay approach addresses a real problem: a speech system should not wait the same amount of time for every word. Its multilingual and multi-speaker claims make it an obvious candidate for evaluation in dictation, meetings, live captions, and voice interfaces.
The model should still be evaluated for the job it actually performs. Fast text is not word alignment. An endpoint is not a subtitle boundary. Anonymous diarization is not verified identity. A low benchmark WER is not proof that names, numbers, accents, overlapping speech, and code-switches will be correct in your recordings.
For publishable captions, preserve the audio, finalize and align the text, review consequential words and speakers, add meaningful non-speech information, segment for reading, export from the approved state, validate the file, and watch the complete program in its destination player.
That is the difference between seeing speech appear and delivering captions people can rely on.