Orate vs PromptSmart: fixed speed against voice tracking

We build Orate, and we do not ship voice tracking. Starting there, because a comparison page written by one side that omits the other side’s best feature is not worth reading. VoiceTrack is a genuinely better idea than what we do, and if it worked everywhere it would end this comparison.

The trade in one paragraph

PromptSmart Pro gives you speech-following scroll, which is the most useful idea anyone has had in this category, and it frequently stops following you the moment you start recording video. Orate gives you a fixed speed that never stops, with a default rate that differs per writing system, and it never follows your voice at all. Which of those you want depends almost entirely on whether the prompter is running while the camera is.

Side by side

Why voice tracking breaks at the record button

This is not a bug in a particular release and it is not carelessness on PromptSmart’s part. When you record video with voice tracking on, two independent consumers need the same audio input at the same instant:

• The video encoder, which needs a continuous audio stream to mux into the file alongside the picture. A gap here is a gap in your recording.
• The speech recogniser, which needs the same stream to work out which word you just said and how far down the script you are.

On both iOS and Android, a microphone input is normally handed to one consumer. Two subsystems that each independently ask the operating system for “the microphone” do not quietly share it — one wins, and which one depends on ordering, on the audio session category, and on details that shift between OS versions. That is why the symptom is inconsistent enough to read like flakiness.

The outcomes are all bad in different ways: the script stops moving, or the recording ends up with no usable audio, or the session drops and capture stops altogether. The full mechanism is in the write-up on microphone contention.

Why we did not ship it

There is a correct fix and it is not a toggle. The app has to own its audio pipeline: open the microphone once as a single source it controls, then fan the buffers out to both destinations — a copy to the encoder for the file, a copy to the recogniser for the scroll position. Neither consumer ever talks to the microphone; only the app does.

That means writing a capture layer rather than wiring a recording SDK to a speech SDK, and handling route changes, interruptions and sample-rate conversion yourself. It is considerably more expensive than either half alone, which is exactly why both features exist widely and the combination barely does. We would rather ship no voice tracking than a version that drops out on the take that mattered. Our capture layer sits behind an interface with one implementation for this reason — so owning the audio path later is not a rewrite.

Making fixed speed not feel like fixed speed

The reputation is worse than the reality, and three things close most of the gap:

1. Calibrate to yourself, not the default. Read 20 seconds of your own script aloud, count the words, multiply by three. That is your rate, and it is probably not the number any app shipped with.
2. Write in short paragraphs with deliberate breaks. A fixed scroll punishes long unbroken blocks because there is nowhere to catch up. Line breaks are slack.
3. Record in shorter takes. Drift accumulates. Two ninety-second takes stay in sync far more easily than one three-minute take, and you were going to cut between them anyway.

Our defaults differ by writing system rather than being one constant, which matters if you read in Hindi, Tamil, Telugu, Bengali, Arabic or Chinese — the reasoning is here. Those rates are informed starting points rather than measurements, and are labelled as such on that page.

Which one to choose