First listen and replay want different rates
Aliases: slow first pass · faster repeat · presentation versus replay
What it is
The first time a bank speaks a six-digit code, the listener is still building the string and needs a rate that can be held. When they say “say that again,” the scaffold is often already there and what is missing is the middle pair — replaying the whole thing at the same rate wastes time on parts they already have. First-listen versus replay rate is a change in time density for the same content across presentations, not a global “speech rate” setting.
Why it happens
First encoding does two jobs at once: identify each unit, and seat it in a structure that does not yet exist. If time runs out, the structure never forms and people abandon the whole string. On replay the structure is there; attention becomes alignment — known chunks can be skimmed, unknown slots still need clarity. So replay can be faster overall; better still, slow only the stretch that failed to land, rather than slowing the whole sentence again.
The inverse holds: if the first pass was already too fast for a scaffold to form, speeding the replay never fills the missing slots. The default should be conservative first, faster second; if replay rate in the logs is already high on first pass, fix the first pass rather than making the second even quicker. A nav prompt “turn right in three hundred metres” and the reminder fifty metres later are not the same band either — the second is reactivation of a known instruction, not new encoding.
Studying it
A presentation-count × rate factorial: the same code or address slow / medium / fast on first play, then one of those three on replay. Dependent measures: whole-string accuracy on first pass, digits recovered after replay, time from replay to done, and barge-in during replay (they already have enough). Preference is the wrong primary: “the second felt too fast” can coexist with “the faster second is how I finished copying.”
In logs, align “say it again” with how many times that content has played. If the second pass is a full-speed copy of the first, completion time nearly doubles while recovery is only a digit or two in the middle, rate has not tracked presentation. Labs that forbid “replay from the middle” overestimate how necessary a full reread is.
Where it stops holding
If the replay is because of noise or because neither side heard clearly, the second pass should be slower and clearer, not faster — intelligibility is missing, not time. “Read the house number again” is a different slice of content, not a second presentation of the same string. Listeners with hearing difficulty or a non-native language may need the slow band both times; grafting “expert replay acceleration” onto them hurts. A global rate setting still works: it shifts both curves and does not cancel the first-versus-second difference.
Applying it
- For costly content — digit strings, addresses, account numbers — use a conservative rate first. After a replay of the same content, step one band faster, or replay only the chunk that failed.
- Make “say it again” and “from the middle” different commands. The latter must not be forced to start at digit one.
- Second mentions of a known instruction (nav reminder, alarm restatement) should be shorter and faster by default; do not reread the first-play script.
- How to check: first-pass accuracy, recovery after replay, time-to-copy on the second pass. If the second is as long as the first and barge-in lands on already-known chunks, replay rate has not been designed.