Por que apps de ditado comem a sua primeira palavra

Aperte a hotkey. Comece a falar. Veja a transcrição começar na sua segunda palavra — às vezes na terceira. "Refatore a lógica de retry" sai como "a lógica de retry". "Não faça merge disso ainda" sai como "faça merge disso ainda", que é uma frase genuinamente perigosa de ter digitada em seu nome. Essa falha é fácil de reproduzir em pipelines de microfone com cold start, dos recursos embutidos do sistema a ferramentas de ditado dedicadas.

As pessoas descrevem isso de jeitos diferentes — "ele corta o começo", "eu preciso pausar antes de falar", "a primeira palavra sempre falta" —, mas é um fenômeno só, e uma vez mordido você desenvolve a solução alternativa que todo mundo desenvolve: aperte a tecla, espere um tempinho, aí fale. O que significa que você agora executa um pequeno ritual supersticioso dezenas de vezes por dia para compensar a sua ferramenta, e a ferramenta treinou você em vez do contrário.

Eu fiz esse ritual por meses em outras ferramentas. Construindo o Keebye, matá-lo foi uma das primeiras coisas da lista, porque a solução acabou exigindo uma troca desconfortável que a maioria dos apps não faz — e eu quero falar da troca com a mesma clareza com que falo da solução.

Por que a primeira palavra é cortada?

Este é um problema no nível da categoria, não desleixo de um fornecedor, e a física disso é simples: microfones não são instantâneos.

Quando um app de ditado inicia uma gravação do jeito ingênuo — aperte a hotkey, aí abra o microfone —, uma cadeia inteira precisa rodar antes de o primeiro sample da sua fala ser capturado. A sessão de áudio do sistema precisa inicializar. O dispositivo de entrada precisa acordar, o que para alguns hardwares significa tempo literal de aquecimento. O formato do stream é negociado, buffers são alocados, e os primeiros buffers que chegam costumam ser lixo que é descartado. Dependendo da máquina e do dispositivo, essa cadeia leva algo entre "um tempinho" e um par de segundos.

Enquanto isso, você — um ser humano com um pensamento já formado — começa a falar no instante em que o seu dedo encosta na tecla. Normalmente um fio de cabelo antes desse instante, na verdade: a intenção de apertar e a intenção de falar saem do seu cérebro juntas, e o início da fala rotineiramente vence o app. Tudo o que você disse antes de o stream ficar ativo nunca existiu, do ponto de vista do app. O modelo não consegue transcrever áudio que nunca foi capturado. Daí: "a lógica de retry".

Por que os apps iniciam o microfone sob demanda em vez de mantê-lo pronto? Principalmente por boa cidadania. Manter um microfone aberto custa um pouco de energia e — muito mais importante — acende o indicador de microfone do sistema, que os usuários compreensivelmente leem como "este app está me ouvindo". Abrir o microfone só sob demanda mantém o indicador honesto e o app com cara de educado. O custo é o risco de cold start no começo de uma gravação.

A solução: um microfone que já está escutando quando você aperta a tecla

O Keebye ataca isso pelas duas pontas, e vale separar os dois mecanismos porque eles resolvem duas metades diferentes do problema.

O microfone aquecido. Depois da sua primeira gravação de uma sessão, o Keebye mantém o stream de entrada de áudio aberto. Isso significa que a cadeia de cold start — inicialização da sessão, despertar do dispositivo, negociação do stream — já aconteceu antes de um ditado posterior, enquanto esse stream continuar saudável. O stream está ativo antes de o seu dedo se mover.

O pré-buffer. Um stream aquecido conserta o atraso do app, mas não o seu — lembre-se, o início da sua fala pode vencer o seu toque na tecla. Então o Keebye mantém um buffer rolante de 500 milissegundos do áudio mais recente (8.000 samples a 16 kHz, em um ring buffer). Quando você aperta a hotkey, esse meio segundo de áudio imediatamente anterior é despejado na frente do enunciado. O áudio que começou dentro desse buffer fica disponível para o transcritor em vez de ser descartado antes do toque na tecla.

O resultado combinado: em ditados repetidos, o stream aquecido e os 500 ms de pré-buffer cobrem o caso comum em que a fala começa pouco antes do toque na tecla ou junto com ele. A pausa ritual fica desnecessária dentro dessa fronteira. Isso não recupera uma palavra falada mais de meio segundo antes de a gravação começar, e o primeiro ditado de uma sessão ainda paga a latência normal de início de stream.

A troca, dita com todas as letras

Aqui está a parte que eu me recuso a enterrar, porque é o preço honesto do projeto: como o stream de áudio fica aberto entre os ditados, o macOS mostra o microfone como ativo mesmo quando você não está ditando. O ponto laranja está aceso. Se você olhar a Central de Controle, o Keebye está listado como usando o microfone, naquele exato momento, enquanto você não faz nada.

O que de fato acontece nesse tempo: o áudio flui para o ring buffer de 500 ms e é continuamente descartado. Nada é transcrito. Nada é armazenado. Nada sai do buffer até você apertar a tecla — e tudo mais velho que meio segundo já foi para sempre, sobrescrito pelo ring. Mas eu não vou fingir que o indicador está mentindo, porque não está: o stream está aberto, e "capaz de escutar sempre" é uma descrição justa da arquitetura, ainda que nada escute em qualquer sentido significativo até você pedir.

Eu fiz essa troca deliberadamente, de olhos abertos, e o raciocínio é este. Abrir o microfone sob demanda introduz risco de cold start toda vez: palavras cortadas, frases erradas, a pausa treinada. O projeto de stream aquecido tem um custo que recai sobre o seu conforto com um ponto laranja, sustentado por uma arquitetura sobre a qual você consegue raciocinar: histórico local só de texto (sobre o qual escrevemos em o seu ditado nunca deveria simplesmente sumir), transcrição on-device, nenhum áudio jamais armazenado, meio segundo de memória em ring. Eu fico com o ponto. Se você não fica — essa é uma posição legítima, e pode genuinamente tornar outra ferramenta a escolha certa para você; as nossas páginas Keebye vs Superwhisper e Keebye vs Wispr Flow foram escritas para ajudar exatamente nessa decisão.

Duas fronteiras, para ninguém se surpreender

O primeiro ditado de uma sessão ainda tem a latência normal de início de stream. O microfone aquecido está aquecido porque uma gravação já aconteceu; a primeira ainda paga o custo de configuração. Os ditados posteriores se beneficiam enquanto o stream permanecer aberto.

O pré-buffer é de 500 milissegundos, e 500 milissegundos são um tempinho, não uma frase. O buffer cobre o caso natural — uma palavra iniciada um pouco antes do toque na tecla. Se você entrega uma frase inteira e aí lembra de apertar a tecla, as palavras anteriores se foram, por projeto: o ring só guarda meio segundo, justamente para que o app não retenha áudio significativo enquanto está ocioso. Um pré-buffer mais longo pegaria mais dos seus começos distraídos e manteria mais do seu áudio ambiente na memória. Meio segundo é onde eu tracei essa linha.

Por que meio segundo importa mais do que parece

Uma primeira palavra cortada parece um bug pequeno. No fluxo de lanes paralelas para o qual o Keebye foi construído — voz como canal de controle de vários agentes de IA e várias conversas humanas ao mesmo tempo, o dia de trabalho descrito em dois filhos, três startups, uma voz —, o ditado acontece dezenas de vezes por dia, em rajadas, no meio de trocas de contexto. Uma ferramenta que exige uma pausa ritual tributa cada rajada e, pior, ocasionalmente inverte o seu sentido e o envia. "Faça merge disso ainda" teve graça exatamente uma vez.

Confiabilidade nesta categoria não é um grande recurso único. É o acúmulo de salvaguardas menores: pré-buffer para o áudio de abertura, histórico atrás da transcrição e um caminho de inserção recuperável. Este post é sobre a primeira delas; o post sobre histórico cobre a segunda.

O Keebye está em acesso antecipado para macOS. Comece o teste grátis abaixo, diga "Não faça merge disso ainda" em um ditado repetido e verifique se a primeira palavra sobrevive. Esse é o teste inteiro.