Perché le app di dettatura si mangiano la tua prima parola

Premi la hotkey. Inizi a parlare. Guardi la trascrizione partire dalla tua seconda parola — a volte dalla terza. «Rifattorizza la logica di retry» esce come «la logica di retry». «Non fare il merge ancora» esce come «fare il merge ancora», che è una frase genuinamente pericolosa da farsi digitare per conto proprio. Questo fallimento è facile da riprodurre su qualsiasi pipeline di microfono con avvio a freddo, dagli strumenti integrati nel sistema alle app di dettatura dedicate.

Le persone lo descrivono in modi diversi — «taglia l'inizio», «devo fare una pausa prima di parlare», «la prima parola manca sempre» — ma è un unico fenomeno, e una volta che ti ha morso sviluppi la soluzione che sviluppano tutti: premi il tasto, aspetti un attimo, poi parli. Il che significa che ora esegui un piccolo rituale scaramantico decine di volte al giorno per compensare il tuo strumento, e lo strumento ha addestrato te invece del contrario.

Ho fatto quel rituale per mesi con altri strumenti. Costruendo Keebye, eliminarlo era tra le prime cose in lista, perché la soluzione si è rivelata richiedere un compromesso scomodo che la maggior parte delle app non accetta — e voglio parlare del compromesso con la stessa chiarezza con cui parlo della soluzione.

Perché la prima parola viene tagliata?

È un problema di categoria, non la sciatteria di un fornitore, e la fisica è semplice: i microfoni non sono istantanei.

Quando un'app di dettatura avvia una registrazione nel modo ingenuo — premi la hotkey, poi apri il microfono — deve girare tutta una catena prima che venga catturato il primo campione del tuo parlato. La sessione audio del sistema operativo deve inizializzarsi. Il dispositivo di input deve svegliarsi, il che per alcuni hardware significa letteralmente un tempo di riscaldamento. Si negozia il formato dello stream, si allocano i buffer, e i primi buffer che arrivano sono spesso spazzatura da scartare. A seconda della macchina e del dispositivo, quella catena impiega tra «un attimo» e un paio di secondi.

Intanto tu — un essere umano con un pensiero già formato — inizi a parlare nell'istante in cui il dito tocca il tasto. Di solito un pelo prima di quell'istante, in realtà: l'intenzione di premere e l'intenzione di parlare lasciano il tuo cervello insieme, e l'inizio del parlato batte regolarmente la prontezza dell'app. Tutto ciò che hai detto prima che lo stream fosse attivo non è mai esistito, per quanto ne sa l'app. Il modello non può trascrivere audio che non è mai stato catturato. Da qui: «la logica di retry».

Perché le app avviano il microfono su richiesta invece di tenerlo pronto? Soprattutto per buona educazione. Tenere un microfono aperto costa un po' di energia e — cosa molto più importante — accende l'indicatore del microfono del sistema operativo, che gli utenti comprensibilmente leggono come «quest'app mi sta ascoltando». Aprire il microfono solo su richiesta mantiene onesto l'indicatore e l'app dall'aria educata. Il costo è il rischio di avvio a freddo all'inizio di una registrazione.

La soluzione: un microfono che sta già ascoltando quando premi il tasto

Keebye affronta la cosa da entrambi i lati, e vale la pena separare i due meccanismi perché risolvono due metà diverse del problema.

Il microfono caldo. Dopo la tua prima registrazione di una sessione, Keebye tiene aperto lo stream di ingresso audio. Vuol dire che la catena di avvio a freddo — inizializzazione della sessione, risveglio del dispositivo, negoziazione dello stream — è già avvenuta prima di una dettatura successiva, finché quello stream resta in salute. Lo stream è attivo prima che il tuo dito si muova.

Il pre-roll. Uno stream caldo risolve il ritardo dell'app, ma non il tuo — ricorda, l'inizio del tuo parlato può battere la pressione del tasto. Quindi Keebye tiene un buffer scorrevole di 500 millisecondi dell'audio più recente (8.000 campioni a 16 kHz, in un anello). Quando premi la hotkey, quel mezzo secondo di audio immediatamente precedente viene riversato in testa all'enunciato. L'audio iniziato dentro quel buffer è disponibile al trascrittore invece di essere scartato prima della pressione del tasto.

Il risultato combinato: nelle dettature ripetute, lo stream caldo e i 500 ms di pre-roll coprono il caso comune in cui il parlato inizia appena prima o insieme alla pressione del tasto. La pausa rituale diventa inutile dentro quel confine. Non può recuperare una parola pronunciata più di mezzo secondo prima dell'avvio della registrazione, e la prima dettatura di una sessione paga comunque la normale latenza di avvio dello stream.

Il compromesso, detto chiaramente

Ecco la parte che mi rifiuto di seppellire, perché è il prezzo onesto del progetto: poiché lo stream audio resta aperto tra una dettatura e l'altra, macOS mostra il microfono come attivo anche quando non stai dettando. Il puntino arancione è acceso. Se guardi il Centro di Controllo, Keebye risulta tra chi usa il microfono, proprio in quel momento, mentre tu non stai facendo niente.

Cosa sta succedendo davvero in quel tempo: l'audio scorre nel buffer ad anello da 500 ms e viene continuamente scartato. Niente viene trascritto. Niente viene conservato. Niente lascia il buffer finché non premi il tasto — e tutto ciò che è più vecchio di mezzo secondo è perso per sempre, sovrascritto dall'anello. Ma non farò finta che l'indicatore stia mentendo, perché non mente: lo stream è aperto, e «capace di ascoltare sempre» è una descrizione corretta dell'architettura, anche se niente ascolta in alcun senso significativo finché non lo chiedi tu.

Ho fatto questo compromesso deliberatamente, a occhi aperti, ed ecco il ragionamento. Aprire il microfono su richiesta introduce ogni volta un rischio di avvio a freddo: parole tagliate, frasi sbagliate, la pausa addestrata. Il progetto a stream caldo ha un costo che ricade sulla tua tolleranza verso un puntino arancione, sostenuto da un'architettura su cui puoi ragionare: cronologia locale solo testuale (che abbiamo raccontato in La tua dettatura non dovrebbe sparire e basta), trascrizione on-device, nessun audio mai conservato, mezzo secondo di memoria ad anello. Il puntino me lo prendo. Se tu no — è una posizione legittima, e potrebbe rendere davvero un altro strumento la scelta giusta per te; le nostre pagine Keebye vs Superwhisper e Keebye vs Wispr Flow sono scritte per aiutare esattamente con quella scelta.

Due confini, così nessuno resta sorpreso

La primissima dettatura di una sessione paga comunque la normale latenza di avvio dello stream. Il microfono è caldo perché una registrazione è già avvenuta; la prima paga comunque il costo di configurazione. Le dettature successive ne beneficiano finché lo stream resta aperto.

Il pre-roll è 500 millisecondi, e 500 millisecondi sono un attimo, non una frase. Il buffer copre il caso naturale — una parola iniziata poco prima della pressione del tasto. Se pronunci una frase intera e poi ti ricordi di premere il tasto, le parole precedenti sono perse, per progetto: l'anello contiene sempre e solo mezzo secondo, proprio perché l'app non trattenga audio significativo mentre è inattiva. Un pre-roll più lungo catturerebbe più delle tue partenze distratte e terrebbe in memoria più audio ambientale. Mezzo secondo è dove ho tracciato quella linea.

Perché mezzo secondo conta più di quanto sembri

Una prima parola tagliata sembra un bug piccolo. Nel flusso a corsie parallele per cui Keebye è stato costruito — la voce come canale di controllo per diversi agenti AI e diverse conversazioni umane insieme, la giornata descritta in Due figli, tre startup, una voce — la dettatura avviene decine di volte al giorno, a raffiche, in mezzo a un cambio di contesto. Uno strumento che pretende una pausa rituale mette una tassa su ogni raffica e, peggio, ogni tanto ti ribalta il significato e lo invia. «Fare il merge ancora» ha fatto ridere esattamente una volta.

L'affidabilità in questa categoria non è una grande funzione. È l'accumulo di tutele più piccole: il pre-roll per l'audio iniziale, la cronologia dietro la trascrizione e un percorso di inserimento recuperabile. Questo articolo parla della prima; l'articolo sulla cronologia copre la seconda.

Keebye è in accesso anticipato per macOS. Inizia la prova gratuita qui sotto, di' «Non fare il merge ancora» in una dettatura ripetuta e controlla se la prima parola sopravvive. È tutto qui il test.