Derfor æder dikteringsapps dit første ord

Tryk på hotkeyen. Begynd at tale. Se transskriptionen begynde ved dit andet ord — nogle gange dit tredje. »Refaktorér retry-logikken« bliver til »retry-logikken«. »Ikke merge det endnu« bliver til »merge det endnu«, og det er en oprigtigt farlig sætning at få skrevet på sine vegne. Den fejl er nem at reproducere på tværs af mikrofon-pipelines med koldstart, fra operativsystemets indbyggede værktøjer til dedikerede dikteringsapps.

Folk beskriver det på forskellige måder — »den klipper starten af«, »jeg er nødt til at holde pause, før jeg taler«, »det første ord mangler altid« — men det er ét fænomen, og har man først været bidt, udvikler man den løsning, alle udvikler: tryk på tasten, vent et øjeblik, og tal så. Hvilket betyder, at du nu opfører et lille overtroisk ritual snesevis af gange om dagen for at kompensere for dit værktøj, og værktøjet har trænet dig i stedet for omvendt.

Jeg opførte det ritual i månedsvis i andre værktøjer. Da jeg byggede Keebye, stod det højt på listen at få det afskaffet, for løsningen viste sig at kræve en ubehagelig afvejning, som de fleste apps ikke vil gå ind på — og jeg vil tale om afvejningen lige så ligefremt som om løsningen.

Hvorfor bliver det første ord skåret væk?

Det er et problem på kategoriniveau, ikke én leverandørs sjuskeri, og fysikken bag er enkel: mikrofoner er ikke øjeblikkelige.

Når en dikteringsapp starter en optagelse på den naive måde — tryk på hotkeyen, og åbn derefter mikrofonen — skal en hel kæde køre, før den første prøve af din tale bliver optaget. Operativsystemets lydsession skal initialiseres. Inputenheden skal vågne, hvilket for noget hardware betyder bogstavelig opvarmningstid. Streamformatet bliver forhandlet, buffere bliver allokeret, og de første buffere, der ankommer, er ofte skrald, som bliver kasseret. Afhængigt af maskinen og enheden tager den kæde et sted mellem »et øjeblik« og et par sekunder.

I mellemtiden begynder du — et menneske med en allerede formet tanke — at tale i det øjeblik, din finger rammer tasten. Faktisk som regel en anelse før det øjeblik: intentionen om at trykke og intentionen om at tale forlader din hjerne sammen, og talens start slår rutinemæssigt appens parathed. Alt, du sagde, før streamen gik i luften, har aldrig eksisteret, hvad appen angår. Modellen kan ikke transskribere lyd, der aldrig blev optaget. Deraf: »retry-logikken«.

Hvorfor starter apps mikrofonen efter behov i stedet for at holde den klar? Mest af hensyn til god opførsel. At holde en mikrofon åben koster lidt strøm og — langt vigtigere — tænder operativsystemets mikrofonindikator, som brugere forståeligt nok læser som »den her app lytter til mig«. At åbne mikrofonen først efter behov holder indikatoren ærlig og appen pæn at se på. Prisen er risikoen for koldstart i begyndelsen af en optagelse.

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

Keebye angriber det her fra begge ender, og de to mekanismer er værd at skille ad, for de løser to forskellige halvdele af problemet.

Den varme mikrofon. Efter din første optagelse i en session holder Keebye lydinput-streamen åben. Det betyder, at koldstart-kæden — initialisering af sessionen, opvågning af enheden, forhandling af streamen — allerede er sket inden en senere diktering, så længe den stream forbliver sund. Streamen er i luften, før din finger bevæger sig.

Pre-rollen. En varm stream retter appens forsinkelse, men ikke din — husk, at din tale kan starte før dit tastetryk. Derfor holder Keebye en rullende buffer på 500 millisekunder af den seneste lyd (8.000 prøver ved 16 kHz, i en ring). Når du trykker på hotkeyen, bliver det halve sekund lyd fra lige før skyllet ind foran ytringen. Lyd, der begyndte inde i den buffer, er tilgængelig for transskriberingen i stedet for at blive kasseret inden tastetrykket.

Det samlede resultat: ved gentagne dikteringer dækker den varme stream og de 500 ms pre-roll det almindelige tilfælde, hvor talen begynder lige før eller sammen med tastetrykket. Den rituelle pause bliver unødvendig inden for den grænse. Den kan ikke redde et ord, der blev sagt mere end et halvt sekund før optagelsen starter, og sessionens første diktering betaler stadig den normale latens ved streamstart.

Afvejningen, sagt ligeud

Her er den del, jeg nægter at begrave, for det er designets ærlige pris: da lydstreamen forbliver åben mellem dikteringer, viser macOS mikrofonen som aktiv, også når du ikke dikterer. Den orange prik lyser. Kigger du i Kontrolcenter, står Keebye opført som en app, der bruger mikrofonen, lige nu, mens du ingenting laver.

Hvad der faktisk sker i det tidsrum: lyden flyder ind i ringbufferen på 500 ms og bliver løbende kasseret. Intet bliver transskriberet. Intet bliver gemt. Intet forlader bufferen, før du trykker på tasten — og alt ældre end et halvt sekund er væk for altid, overskrevet af ringen. Men jeg vil ikke lade som om, indikatoren lyver, for det gør den ikke: streamen er åben, og »kan altid lytte« er en fair beskrivelse af arkitekturen, selvom intet lytter i nogen meningsfuld forstand, før du beder om det.

Jeg tog den afvejning bevidst og med åbne øjne, og her er ræsonnementet. At åbne mikrofonen efter behov indfører risiko for koldstart hver gang: klippede ord, forkerte sætninger, den indlærte pause. Designet med en varm stream har en pris, der lander på, hvor tryg du er ved en orange prik, understøttet af en arkitektur, du kan ræsonnere om: lokal historik med kun tekst (som vi har skrevet om i din diktering bør aldrig bare forsvinde), transskription on-device, ingen lyd nogensinde gemt, et halvt sekunds ringhukommelse. Jeg tager prikken. Vil du ikke det — er det en legitim holdning, og det kan oprigtigt gøre et andet værktøj til det rigtige valg for dig; vores sider Keebye vs. Superwhisper og Keebye vs. Wispr Flow er skrevet for at hjælpe med præcis den beslutning.

To grænser, så ingen bliver overrasket

Sessionens allerførste diktering har stadig normal latens ved streamstart. Den varme mikrofon er varm, fordi der allerede er sket en optagelse; den første betaler stadig opsætningsprisen. Senere dikteringer får gavn af det, så længe streamen forbliver åben.

Pre-rollen er 500 millisekunder, og 500 millisekunder er et øjeblik, ikke en sætning. Bufferen dækker det naturlige tilfælde — et ord, der er begyndt en anelse før tastetrykket. Leverer du en hel sætning og derefter kommer i tanke om at trykke på tasten, er de tidligere ord væk, ved design: ringen rummer altid kun et halvt sekund, netop for at appen ikke opbevarer meningsfuld lyd, mens den er i tomgang. En længere pre-roll ville fange flere af dine distræte starter og holde mere af din omgivende lyd i hukommelsen. Et halvt sekund er dér, jeg trak den grænse.

Hvorfor et halvt sekund betyder mere, end det lyder

Et klippet første ord ligner en lille fejl. I det workflow med parallelle lanes, Keebye blev bygget til — stemmen som styringskanal for flere AI-agenter og flere menneskelige samtaler på én gang, den arbejdsdag der er beskrevet i To børn, tre startups, én stemme — sker der diktering snesevis af gange om dagen, i byger, midt i et kontekstskift. Et værktøj, der kræver en rituel pause, beskatter hver eneste byge og vender, værre endnu, af og til din mening om og sender den af sted. »Merge det endnu« var kun sjovt én gang.

Pålidelighed i denne kategori er ikke én stor funktion. Det er ophobningen af mindre sikringer: pre-roll til lyden i starten, historik bag transskriptionen og en indsættelsesvej, man kan komme tilbage fra. Dette indlæg handler om den første; indlægget om historik dækker den anden.

Keebye er i early access til macOS. Start din gratis prøveperiode nedenfor, sig »Ikke merge det endnu« i en gentaget diktering, og tjek, om det første ord overlever. Det er hele testen.