Word-level timestamps: what breaks without them
Every word given a start and end time in the audio. Four features depend on it, most speech engines do not return one, and the hard part is not the timing.
Ask a text-to-speech engine for an audio file and you get an audio file. Ask it where the eighth word begins and most engines have no answer. That gap, between having the audio and knowing what is being said at any given millisecond, is what word-level timestamps close, and it turns out to decide far more of a product than it first appears.
What a word-level timestamp actually is
A word-level timestamp is a start time and an end time, in the audio, for every single word of the text. Not for the paragraph, not for the sentence: for the word. A three-minute article produces a table of six or seven hundred entries, each one saying "this word runs from 42.180 to 42.415 seconds."
The distinction from sentence-level timing matters more than it sounds. Sentence timing tells you which sentence is playing. Word timing tells you which word is playing, which is the difference between an interface that follows the reading and one that approximates it. At normal speech rates, a sentence lasts four to six seconds. Highlighting a whole sentence for six seconds does not feel like following along; it feels like a light being left on.
The four things that quietly depend on it
Read-along highlighting. The text on screen lights up in step with the voice. This is the visible one, and the one people ask for by name, because it is what makes an audio version usable by someone who reads with difficulty rather than someone who has stopped reading altogether.
Searching inside speech. Typing a name and jumping to the moment it is spoken requires knowing where each word sits. Without timestamps you can search the transcript, but you cannot land on the audio.
Subtitles that sit right. A subtitle file is a list of text blocks with in and out points. Generated from sentence timing, the blocks drift out of step within a paragraph; generated from word timing, they sit where the words are and the cuts fall on breath, not on a guess.
Correcting three words without regenerating an article. If a name is mispronounced, the fix should cost three words of synthesis, not the whole piece. That means finding the passage in the audio, cutting at the silences that bound it, splicing in the corrected segment, and reassembling. All of it starts from knowing exactly where the passage lives.
Take timestamps away and none of these four fail loudly. They simply become unavailable, which is a much easier thing to discover late.
Where they come from, and why not every engine has them
There are two ways to obtain word timings. The first is that the engine returns them as it synthesises: it knows what it produced, so it can report where. This is the accurate route, and it costs nothing extra.
The second is forced alignment. You take the audio and the original text, run a speech recogniser over the audio, and match its output back against the text you started from. It works, it is what you fall back on when the engine is silent, and it introduces its own error. It also costs a second pass over every file.
Whether an engine returns timings is not a quality signal. Excellent voices ship without them and unremarkable voices ship with them. It is an interface decision made early in a product's life, and it is rarely revisited, which is why it is worth asking about before you build on top of an engine rather than after.
The hard part is not the timing, it is the alignment
Here is the part that surprises teams building this for the first time: the written word and the spoken word do not line up one to one.
A speech engine expands text before reading it. An acronym may be spelled out letter by letter, so one written token becomes six spoken ones. A year is read as words, a decimal number becomes a phrase around a separator, a currency symbol turns into a noun that appears nowhere in the source, an ordinal grows a suffix. Every one of these breaks the assumption that the nth written word corresponds to the nth spoken interval.
If you highlight by counting words, the highlight is correct until the first acronym and wrong for the rest of the paragraph. The fix is to keep the mapping between the source token and however many spoken tokens it produced, and to carry that mapping through every downstream feature. It is unglamorous work, and it is the actual difficulty, the timings themselves are the easy half.
Two smaller traps are worth naming. Long files accumulate drift when timings are stitched across chunk boundaries, so the last minute of a twenty-minute reading is where errors surface first. And a text edited after synthesis invalidates the whole table: timings belong to a specific audio of a specific text, and treating them as reusable across versions produces highlighting that is confidently, subtly wrong.
What to ask before you commit
If read-along, in-speech search, aligned subtitles or targeted correction are anywhere on your roadmap, the questions are: does the engine return word-level timings natively or does alignment have to be added; how are expanded tokens mapped back to the source; and does the timing survive a re-read of the same article. An engine that answers "sentence level" is not disqualified, it just means the four features above are a project rather than a setting.
At WeDispatch, the rule is written as a capability of the engine rather than a property of a plan, precisely because engines change: a reading tier that does not return word timings switches the dependent features off and says so on screen, instead of offering a highlight that quietly points at the wrong word. If you want to see what it looks like in practice, the read-along audio entry covers the interface side, in-speech search the retrieval side, and targeted correction the repair side. The quickest answer, though, is to hear it on one of your own articles.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo