Waarom dictatie-apps je eerste woord opeten

Druk op de hotkey. Begin te praten. Kijk hoe het transcript begint bij je tweede woord — soms je derde. "Refactor de retry-logica" komt eruit als "de retry-logica". "Merge dat nog niet" komt eruit als "merge dat", wat een oprecht gevaarlijke zin is om namens jou getypt te krijgen. Deze storing is eenvoudig te reproduceren over microfoonpijplijnen met een koude start heen, van ingebouwde OS-tools tot gespecialiseerde dictatietools.

Mensen beschrijven het op verschillende manieren — "hij kapt het begin af", "ik moet even wachten voor ik begin te praten", "het eerste woord ontbreekt altijd" — maar het is één verschijnsel, en ben je er eenmaal door gebeten, dan ontwikkel je de workaround die iedereen ontwikkelt: druk op de toets, wacht een tel, en praat dan. Wat betekent dat je nu tientallen keren per dag een klein bijgelovig ritueel uitvoert om je tool te compenseren, en dat de tool jou heeft getraind in plaats van andersom.

Ik heb dat ritueel maandenlang uitgevoerd in andere tools. Bij het bouwen van Keebye stond het doden ervan boven aan de lijst, omdat de oplossing een ongemakkelijke afweging bleek te vereisen die de meeste apps niet willen maken — en ik wil het over die afweging net zo onomwonden hebben als over de oplossing.

Waarom valt het eerste woord weg?

Dit is een probleem op categorieniveau, geen slordigheid van één leverancier, en de fysica ervan is simpel: microfoons zijn niet instant.

Wanneer een dictatie-app een opname op de naïeve manier start — hotkey indrukken, en dan de microfoon openen — moet er een hele keten draaien voordat het eerste sample van je spraak is vastgelegd. De audiosessie van het besturingssysteem moet initialiseren. Het invoerapparaat moet ontwaken, wat voor sommige hardware letterlijk opwarmtijd betekent. Het streamformaat wordt onderhandeld, buffers worden gealloceerd, en de eerste buffers die binnenkomen zijn vaak rommel die wordt weggegooid. Afhankelijk van de machine en het apparaat duurt die keten ergens tussen "een tel" en een paar seconden.

Ondertussen begin jij — een mens met een al gevormde gedachte — te spreken op het moment dat je vinger de toets raakt. Meestal zelfs een haartje voor dat moment: de intentie om te drukken en de intentie om te spreken verlaten je brein samen, en het begin van je spraak wint het routineus van de gereedheid van de app. Alles wat je zei voordat de stream live ging, heeft voor de app nooit bestaan. Het model kan geen audio transcriberen die nooit is vastgelegd. Vandaar: "de retry-logica".

Waarom starten apps de microfoon op aanvraag in plaats van hem klaar te houden? Vooral fatsoen. Een microfoon openhouden kost een beetje energie en — veel belangrijker — het laat de microfoonindicator van het besturingssysteem oplichten, wat gebruikers begrijpelijkerwijs lezen als "deze app luistert naar me". De microfoon alleen op aanvraag openen houdt de indicator eerlijk en de app netjes. De prijs is het risico van een koude start aan het begin van een opname.

De oplossing: een microfoon die al luistert wanneer je de toets indrukt

Keebye pakt dit van twee kanten aan, en de twee mechanismen zijn het scheiden waard omdat ze twee verschillende helften van het probleem oplossen.

De warme microfoon. Na je eerste opname van een sessie houdt Keebye de audio-invoerstream open. Dat betekent dat de koudestartketen — sessie-initialisatie, apparaat wekken, streamonderhandeling — al heeft plaatsgevonden vóór een latere dictatie, zolang die stream gezond blijft. De stream is live voordat je vinger beweegt.

De pre-roll. Een warme stream lost de laatheid van de app op, maar niet die van jou — onthoud: het begin van je spraak kan het van je toetsaanslag winnen. Dus houdt Keebye een rollende buffer van 500 milliseconden van de meest recente audio bij (8.000 samples op 16 kHz, in een ring). Wanneer je de hotkey indrukt, wordt die halve seconde audio van net ervoor vooraan de uiting geplakt. Audio die binnen die buffer begon, is beschikbaar voor de transcriber in plaats van vóór de toetsaanslag te worden weggegooid.

Het gecombineerde resultaat: bij herhaalde dictaties dekken de warme stream en de pre-roll van 500 ms het gangbare geval waarin spraak net vóór of tegelijk met de toetsaanslag begint. De rituele pauze wordt binnen die grens overbodig. Het kan geen woord terughalen dat meer dan een halve seconde vóór de start van de opname is uitgesproken, en de eerste dictatie van een sessie betaalt nog steeds de normale latency van het starten van de stream.

De afweging, onomwonden gesteld

Dit is het deel dat ik weiger te begraven, want het is de eerlijke prijs van het ontwerp: omdat de audiostream tussen dictaties door openblijft, toont macOS de microfoon als actief, ook wanneer je niet dicteert. De oranje stip staat aan. Kijk je in Bedieningspaneel, dan staat Keebye vermeld als gebruiker van de microfoon, op dat moment, terwijl je niets doet.

Wat er in die tijd werkelijk gebeurt: de audio stroomt de ringbuffer van 500 ms in en wordt continu weggegooid. Er wordt niets getranscribeerd. Er wordt niets opgeslagen. Er verlaat niets de buffer tot je de toets indrukt — en alles ouder dan een halve seconde is voorgoed weg, overschreven door de ring. Maar ik ga niet doen alsof de indicator liegt, want dat doet hij niet: de stream is open, en "in staat om altijd te luisteren" is een eerlijke beschrijving van de architectuur, ook al luistert er in geen enkele betekenisvolle zin iets tot jij erom vraagt.

Ik heb deze afweging bewust gemaakt, met open ogen, en dit is de redenering. De microfoon op aanvraag openen introduceert elke keer het risico van een koude start: afgekapte woorden, verkeerde zinnen, de aangeleerde pauze. Het warmestream-ontwerp heeft een prijs die landt op je comfort met een oranje stip, gedekt door een architectuur die je kunt doorgronden: lokale geschiedenis met alleen tekst (waarover we schreven in Je dictatie hoort nooit zomaar te verdwijnen), on-device transcriptie, nooit opgeslagen audio, een halve seconde ringgeheugen. Ik neem de stip erbij. Wil jij dat niet — dat is een legitiem standpunt, en het kan oprecht betekenen dat een andere tool de juiste keuze voor je is; onze pagina's Keebye vs Superwhisper en Keebye vs Wispr Flow zijn geschreven om precies bij die afweging te helpen.

Twee grenzen, zodat niemand verrast wordt

De allereerste dictatie van een sessie heeft nog steeds de normale latency van het starten van de stream. De microfoon is warm omdat er al een opname is geweest; die eerste betaalt nog steeds de opstartkosten. Latere dictaties profiteren zolang de stream open blijft.

De pre-roll is 500 milliseconden, en 500 milliseconden is een tel, geen zin. De buffer dekt het natuurlijke geval — een woord dat net vóór de toetsaanslag begint. Spreek je een hele zin uit en denk je daarna pas aan de toets, dan zijn de eerdere woorden weg, by design: de ring bevat nooit meer dan een halve seconde, juist zodat de app geen betekenisvolle audio bewaart terwijl hij niets doet. Een langere pre-roll zou meer van je verstrooide starts opvangen en meer van je omgevingsgeluid in het geheugen houden. Bij een halve seconde heb ik die streep getrokken.

Waarom een halve seconde meer uitmaakt dan het klinkt

Een afgekapt eerste woord ziet eruit als een kleine bug. In de parallelle-lanes-workflow waarvoor Keebye is gebouwd — stem als stuurkanaal voor meerdere AI-agents en meerdere menselijke gesprekken tegelijk, de werkdag beschreven in Twee kinderen, drie startups, één stem — gebeurt dictatie tientallen keren per dag, in salvo's, middenin een contextwissel. Een tool die een rituele pauze eist belast elk salvo en, erger, draait af en toe je betekenis om en verstuurt hem. "Merge dat" was precies één keer grappig.

Betrouwbaarheid in deze categorie is niet één grote functie. Het is de opeenstapeling van kleinere waarborgen: pre-roll voor de openingsaudio, geschiedenis achter het transcript, en een herstelbaar invoegpad. Deze post gaat over de eerste; de post over geschiedenis behandelt de tweede.

Keebye is in early access voor macOS. Start hieronder je gratis proefperiode, zeg "Merge dat nog niet" bij een herhaalde dictatie, en controleer of het eerste woord het overleeft. Dat is de hele test.