Derfor spiser dikteringsapper det første ordet ditt

Trykk på hurtigtasten. Begynn å snakke. Se transkripsjonen starte ved ord nummer to — noen ganger nummer tre. «Refaktorer retry-logikken» kommer ut som «retry-logikken». «Ikke merge det ennå» kommer ut som «merge det ennå», som er en genuint farlig setning å få skrevet på dine vegne. Denne svikten er lett å reprodusere på tvers av mikrofonkjeder med kaldstart, fra det som er innebygd i operativsystemet til dedikerte dikteringsverktøy.

Folk beskriver det på ulike måter — «den kutter starten», «jeg må ta en pause før jeg snakker», «det første ordet mangler alltid» — men det er ett fenomen, og når du først er blitt brent, utvikler du løsningen alle utvikler: trykk på tasten, vent et øyeblikk, så snakk. Som betyr at du nå utfører et lite, overtroisk ritual dusinvis av ganger om dagen for å kompensere for verktøyet ditt, og verktøyet har trent deg i stedet for omvendt.

Jeg gjorde det ritualet i månedsvis i andre verktøy. Da jeg bygde Keebye, sto det å drepe det tidlig på listen, for løsningen viste seg å kreve en ubehagelig avveining de fleste apper ikke vil ta — og jeg vil snakke like enkelt om avveiningen som om løsningen.

Hvorfor blir det første ordet kuttet?

Dette er et problem på kategorinivå, ikke én leverandørs slurv, og fysikken bak er enkel: mikrofoner er ikke øyeblikkelige.

Når en dikteringsapp starter et opptak på den naive måten — trykk på hurtigtasten, så åpne mikrofonen — må en hel kjede kjøre før den første prøven av talen din blir fanget opp. Lydøkten i operativsystemet må initialiseres. Inndataenheten må våkne, noe som for enkelte maskinvare betyr bokstavelig oppvarmingstid. Strømformatet må forhandles, buffere må allokeres, og de første bufferne som kommer inn, er ofte søppel som forkastes. Avhengig av maskin og enhet tar den kjeden et sted mellom «et øyeblikk» og et par sekunder.

I mellomtiden begynner du — et menneske med en allerede ferdigformet tanke — å snakke i det øyeblikket fingeren treffer tasten. Vanligvis et hårstrå før det øyeblikket, faktisk: intensjonen om å trykke og intensjonen om å snakke forlater hjernen sammen, og taleoppstarten slår rutinemessig appens beredskap. Alt du sa før strømmen gikk live, har aldri eksistert så langt appen vet. Modellen kan ikke transkribere lyd som aldri ble fanget opp. Derav: «retry-logikken».

Hvorfor starter apper mikrofonen ved behov i stedet for å holde den klar? Stort sett god folkeskikk. Å holde en mikrofon åpen koster litt strøm, og — mye viktigere — det tenner mikrofonindikatoren i operativsystemet, som brukere forståelig nok leser som «denne appen lytter til meg». Å åpne mikrofonen bare ved behov holder indikatoren ærlig og appen høflig. Kostnaden er kaldstartrisiko i begynnelsen av et opptak.

Løsningen: en mikrofon som allerede lytter når du trykker på tasten

Keebye angriper dette fra begge ender, og de to mekanismene er verdt å skille, fordi de løser hver sin halvdel av problemet.

Den varme mikrofonen. Etter det første opptaket ditt i en økt holder Keebye lydinndatastrømmen åpen. Det betyr at kaldstartkjeden — initialisering av økten, oppvåkning av enheten, forhandling av strømmen — allerede har skjedd før en senere diktering, så lenge strømmen holder seg frisk. Strømmen er live før fingeren din beveger seg.

Forhåndsbufferen. En varm strøm fikser appens forsinkelse, men ikke din — husk at taleoppstarten din kan slå tastetrykket. Så Keebye holder en rullerende buffer på 500 millisekunder med den nyeste lyden (8 000 prøver ved 16 kHz, i en ring). Når du trykker på hurtigtasten, tømmes det halve sekundet med lyd fra like før inn foran ytringen. Lyd som begynte inne i den bufferen, er tilgjengelig for transkriberingen i stedet for å bli forkastet før tastetrykket.

Det samlede resultatet: ved gjentatte dikteringer dekker den varme strømmen og forhåndsbufferen på 500 ms det vanlige tilfellet der talen begynner like før eller samtidig med tastetrykket. Den rituelle pausen blir unødvendig innenfor den grensen. Den kan ikke gjenopprette et ord som ble sagt mer enn et halvt sekund før opptaket startet, og den første dikteringen i en økt betaler fortsatt vanlig ventetid for å starte strømmen.

Avveiningen, sagt rett ut

Her er delen jeg nekter å begrave, for det er den ærlige prisen på designet: siden lydstrømmen holdes åpen mellom dikteringer, viser macOS mikrofonen som aktiv selv når du ikke dikterer. Den oransje prikken lyser. Ser du i Kontrollsenter, står Keebye oppført som bruker av mikrofonen, akkurat da, mens du ikke gjør noe.

Det som faktisk skjer i den tiden: lyden flyter inn i ringbufferen på 500 ms og forkastes kontinuerlig. Ingenting transkriberes. Ingenting lagres. Ingenting forlater bufferen før du trykker på tasten — og alt eldre enn et halvt sekund er borte for alltid, overskrevet av ringen. Men jeg skal ikke late som om indikatoren lyver, for det gjør den ikke: strømmen er åpen, og «i stand til å lytte hele tiden» er en rimelig beskrivelse av arkitekturen, selv om ingenting lytter i noen meningsfull forstand før du ber om det.

Jeg tok denne avveiningen bevisst, med åpne øyne, og her er resonnementet. Å åpne mikrofonen ved behov innfører kaldstartrisiko hver gang: kuttede ord, feil setninger, den innlærte pausen. Designet med varm strøm har en kostnad som lander på hvor komfortabel du er med en oransje prikk, støttet av en arkitektur du kan resonnere rundt: lokal historikk kun med tekst (som vi har skrevet om i dikteringen din bør aldri bare forsvinne), transkribering på enheten, ingen lyd lagret noen gang, et halvt sekund med ringminne. Jeg tar prikken. Hvis du ikke vil — er det en legitim posisjon, og den kan faktisk gjøre et annet verktøy til det riktige for deg; sidene våre Keebye vs. Superwhisper og Keebye vs. Wispr Flow er skrevet for å hjelpe med akkurat den avgjørelsen.

To grenser, så ingen blir overrasket

Den aller første dikteringen i en økt har fortsatt vanlig ventetid for å starte strømmen. Den varme mikrofonen er varm fordi et opptak allerede har skjedd; det første betaler fortsatt oppsettkostnaden. Senere dikteringer nyter godt av det så lenge strømmen holdes åpen.

Forhåndsbufferen er 500 millisekunder, og 500 millisekunder er et øyeblikk, ikke en setning. Bufferen dekker det naturlige tilfellet — et ord som begynner litt før tastetrykket. Leverer du en hel setning og så husker å trykke på tasten, er de tidligere ordene borte, ved design: ringen holder aldri mer enn et halvt sekund, nettopp for at appen ikke skal beholde meningsfull lyd mens den er inaktiv. En lengre forhåndsbuffer ville fanget flere av dine distre starter og holdt mer av omgivelseslyden din i minnet. Et halvt sekund er der jeg trakk den grensen.

Hvorfor et halvt sekund betyr mer enn det høres ut som

Et kuttet førsteord ser ut som en liten feil. I arbeidsflyten med parallelle lanes som Keebye ble bygget for — stemmen som styrekanal for flere AI-agenter og flere menneskesamtaler samtidig, arbeidsdagen beskrevet i to barn, tre startups, én stemme — skjer diktering dusinvis av ganger om dagen, i rykk, midt i et kontekstbytte. Et verktøy som krever en rituell pause, skattlegger hvert eneste rykk og, verre, snur av og til meningen din og sender den. «Merge det ennå» var morsomt nøyaktig én gang.

Pålitelighet i denne kategorien er ikke én stor funksjon. Det er akkumuleringen av mindre sikringer: forhåndsbuffer for åpningslyden, historikk bak transkripsjonen, og en innsettingsvei du kan hente tilbake fra. Dette innlegget handler om den første; innlegget om historikk dekker den andre.

Keebye er i tidlig tilgang for macOS. Start den gratis prøveperioden nedenfor, si «Ikke merge det ennå» på en gjentatt diktering, og sjekk om det første ordet overlever. Det er hele testen.