Por qué las apps de dictado se comen tu primera palabra

Pulsa la hotkey. Empieza a hablar. Mira cómo la transcripción arranca en tu segunda palabra — a veces la tercera. «Refactoriza la lógica de reintento» sale como «la lógica de reintento». «No fusiones eso todavía» sale como «fusiones eso todavía», que es una frase genuinamente peligrosa para que la escriban en tu nombre. Este fallo es fácil de reproducir en pipelines de micrófono con arranque en frío, desde los integrados del sistema hasta herramientas de dictado dedicadas.

La gente lo describe de formas distintas — «recorta el principio», «tengo que pausar antes de hablar», «siempre falta la primera palabra» —, pero es un solo fenómeno, y una vez que te ha mordido desarrollas el apaño que desarrolla todo el mundo: pulsa la tecla, espera un momento y entonces habla. Lo que significa que ahora estás ejecutando un pequeño ritual supersticioso decenas de veces al día para compensar a tu herramienta, y la herramienta te ha entrenado a ti en lugar de al revés.

Yo hice ese ritual durante meses con otras herramientas. Al construir Keebye, matarlo fue de las primeras cosas de la lista, porque el arreglo resultó exigir un intercambio incómodo que la mayoría de las apps no van a hacer — y quiero hablar del intercambio con la misma claridad que del arreglo.

¿Por qué se corta la primera palabra?

Este es un problema a nivel de categoría, no la chapuza de un proveedor, y la física es sencilla: los micrófonos no son instantáneos.

Cuando una app de dictado inicia una grabación de la forma ingenua — pulsa la hotkey y entonces abre el micrófono —, toda una cadena tiene que ejecutarse antes de capturar la primera muestra de tu habla. La sesión de audio del sistema operativo tiene que inicializarse. El dispositivo de entrada tiene que despertarse, lo que en cierto hardware significa un tiempo de calentamiento literal. Se negocia el formato del flujo, se asignan búferes, y los primeros búferes que llegan suelen ser basura que se descarta. Según la máquina y el dispositivo, esa cadena tarda entre «un instante» y un par de segundos.

Mientras tanto, tú — un ser humano con un pensamiento ya formado — empiezas a hablar en el instante en que tu dedo toca la tecla. En realidad, normalmente un pelo antes de ese instante: la intención de pulsar y la intención de hablar salen juntas de tu cerebro, y el inicio del habla suele adelantarse a que la app esté lista. Todo lo que dijiste antes de que el flujo se activara nunca existió, hasta donde la app sabe. El modelo no puede transcribir audio que nunca se capturó. De ahí: «la lógica de reintento».

¿Por qué las apps abren el micro bajo demanda en lugar de mantenerlo listo? Sobre todo por civismo. Mantener un micrófono abierto cuesta un poco de energía y — mucho más importante — enciende el indicador de micrófono del sistema, que los usuarios interpretan comprensiblemente como «esta app me está escuchando». Abrir el micro solo bajo demanda mantiene el indicador honesto y a la app con buena pinta. El coste es riesgo de arranque en frío al principio de cada grabación.

El arreglo: un micro que ya está escuchando cuando pulsas la tecla

Keebye ataca esto por los dos extremos, y merece la pena separar los dos mecanismos porque resuelven dos mitades distintas del problema.

El micro caliente. Después de tu primera grabación de una sesión, Keebye mantiene abierto el flujo de entrada de audio. Eso significa que la cadena de arranque en frío — inicialización de sesión, despertar del dispositivo, negociación del flujo — ya ha ocurrido antes de un dictado posterior, mientras ese flujo siga sano. El flujo está vivo antes de que tu dedo se mueva.

El pre-roll. Un flujo caliente arregla el retraso de la app, pero no el tuyo — recuerda que el inicio de tu habla puede adelantarse a tu pulsación. Así que Keebye mantiene un búfer rodante de 500 milisegundos del audio más reciente (8.000 muestras a 16 kHz, en un anillo). Cuando pulsas la hotkey, ese medio segundo de audio inmediatamente anterior se vuelca al principio de la locución. El audio que empezó dentro de ese búfer queda disponible para el transcriptor en lugar de descartarse antes de la pulsación.

El resultado combinado: en dictados repetidos, el flujo caliente y el pre-roll de 500 ms cubren el caso habitual en que el habla empieza justo antes de la pulsación o a la vez que ella. La pausa ritual se vuelve innecesaria dentro de esa frontera. No puede recuperar una palabra dicha más de medio segundo antes de que empiece la grabación, y el primer dictado de una sesión sigue pagando la latencia normal de arranque del flujo.

El intercambio, dicho sin rodeos

Aquí está la parte que me niego a enterrar, porque es el precio honesto del diseño: como el flujo de audio permanece abierto entre dictados, macOS muestra el micrófono como activo aunque no estés dictando. El punto naranja está encendido. Si miras el Centro de control, Keebye aparece usando el micro, en ese momento, mientras tú no haces nada.

Lo que ocurre realmente durante ese tiempo: el audio fluye hacia el búfer en anillo de 500 ms y se descarta de forma continua. No se transcribe nada. No se almacena nada. Nada sale del búfer hasta que pulsas la tecla — y todo lo más antiguo que medio segundo desaparece para siempre, sobrescrito por el anillo. Pero no voy a fingir que el indicador miente, porque no lo hace: el flujo está abierto, y «capaz de escuchar siempre» es una descripción justa de la arquitectura, aunque nada escuche en ningún sentido significativo hasta que tú lo pidas.

Hice este intercambio deliberadamente, con los ojos abiertos, y este es el razonamiento. Abrir el micro bajo demanda introduce riesgo de arranque en frío cada vez: palabras recortadas, frases equivocadas, la pausa aprendida. El diseño de flujo caliente tiene un coste que recae sobre tu comodidad con un punto naranja, respaldado por una arquitectura sobre la que puedes razonar: historial local solo de texto (que contamos en tu dictado no debería esfumarse sin más), transcripción on-device, ningún audio almacenado jamás, medio segundo de memoria en anillo. Yo me quedo con el punto. Si tú no — es una postura legítima, y podría hacer que otra herramienta sea genuinamente la elección correcta para ti; nuestras páginas Keebye vs Superwhisper y Keebye vs Wispr Flow están escritas para ayudar exactamente con esa decisión.

Dos fronteras, para que nadie se sorprenda

El primer dictado de una sesión sigue teniendo la latencia normal de arranque del flujo. El micro está caliente porque ya ocurrió una grabación; el primero sigue pagando el coste de configuración. Los dictados posteriores se benefician mientras el flujo siga abierto.

El pre-roll son 500 milisegundos, y 500 milisegundos son un instante, no una frase. El búfer cubre el caso natural: una palabra empezada ligeramente antes de la pulsación. Si sueltas una frase entera y luego te acuerdas de pulsar la tecla, las palabras anteriores se han ido, por diseño: el anillo solo llega a contener medio segundo, precisamente para que la app no retenga audio significativo mientras está en reposo. Un pre-roll más largo atraparía más de tus arranques despistados y mantendría más audio ambiental en memoria. Medio segundo es donde tracé esa línea.

Por qué medio segundo importa más de lo que parece

Una primera palabra recortada parece un bug pequeño. En el flujo de trabajo de carriles en paralelo para el que se construyó Keebye — la voz como canal de control de varios agentes de IA y varias conversaciones humanas a la vez, la jornada descrita en dos hijos, tres startups, una voz —, el dictado ocurre decenas de veces al día, en ráfagas, a mitad de un cambio de contexto. Una herramienta que exige una pausa ritual grava cada ráfaga y, peor aún, de vez en cuando invierte tu significado y lo envía. «Fusiones eso todavía» tuvo gracia exactamente una vez.

La fiabilidad en esta categoría no es una gran función. Es la acumulación de salvaguardas más pequeñas: pre-roll para el audio de apertura, historial detrás de la transcripción y una ruta de inserción recuperable. Este artículo va de la primera; el post sobre el historial cubre la segunda.

Keebye está en acceso anticipado para macOS. Empieza tu prueba gratuita abajo, di «No fusiones eso todavía» en un dictado repetido y comprueba si sobrevive la primera palabra. Esa es toda la prueba.