Gran parte del retraso en la traducción en directo es espera: la del stream, la de la siguiente palabra, la de la frase. La única parte que controlas es el modo de latencia: menos retraso o menos revisiones.
Quien sigue una traducción en directo ve cada línea unos segundos después de que el orador la pronuncie. Ese retraso no es uno solo, sino varios que se acumulan a lo largo de una cadena, y casi todos son una forma de espera. Entender qué tipo de espera es cada una facilita elegir el modo de latencia y le dice a un desarrollador que construye un lector qué mostrar, y cuándo.
Un punto de referencia útil antes de las cifras: un intérprete simultáneo humano suele hablar con dos a cuatro segundos de retraso respecto al orador. Los intérpretes llaman a ese desfase entre oído y voz (ear-voice span), y las lenguas de verbo final no lo resuelven esperando al verbo, sino anticipándolo o dividiendo la frase en fragmentos que puedan sostenerse solos. Un segundo o dos de retraso no es un defecto del software; es aproximadamente lo que hace una persona muy buena.
Cada transcripción en directo en VocalStack pasa por las mismas etapas, en el mismo orden, y cada una espera a la anterior.
El texto en el idioma original llega a quien lo lee casi tal como se pronuncia. La traducción llega uno o dos segundos después, y la frase hablada llega después de su traducción, por eso un clip de voz siempre llega el último. El primer efecto visible de la cadena, sin embargo, llega mucho antes que cualquier voz: el propio texto se mueve.
Lo primero que nota la gente en una transcripción en directo es que las palabras más nuevas se mueven. Aparece una frase, cambia y se asienta. Eso es la etapa de borrador en acción, y existe por una razón que vale para cualquier reconocedor de voz.
Un reconocedor asienta una palabra fijándose en lo que viene después. «Asta» y «hasta» suenan igual hasta que llega la palabra siguiente; una «s» final puede pertenecer a esta palabra o a la siguiente. Mientras no haya audio a la derecha de una palabra, su escritura es una suposición, así que las palabras más nuevas de cualquier transcripción en directo son siempre las menos seguras. Un borrador es simplemente esa suposición mostrada pronto en lugar de ocultarla.
Cada borrador reemplaza por completo la cola en directo: las palabras oídas desde la última confirmación, que todavía están cambiando. Una confirmación es final. Nunca cambia, lleva tiempos a nivel de palabra, y las confirmaciones se numeran sin huecos para que quien lee pueda saber si se le ha escapado una.
Para un desarrollador, esta es la única regla que exige la API en tiempo real: mostrar cada segmento confirmado, luego el último borrador después de ellos, y borrar el borrador cuando llega una confirmación. Añadir borradores en lugar de reemplazarlos produce texto duplicado y parpadeante; la confirmación simplemente consume la cola. El tutorial de WebSocket construye un lector justo sobre esto.
Para quien emite, mover el texto es el precio de la baja latencia. Mostrar palabras antes de que la frase esté terminada es lo que hace que la transcripción se sienta en directo. La traducción, en cambio, no puede permitirse ese truco, porque una palabra puede adivinarse a partir de media frase, pero una traducción no.
El orden de las palabras es la razón por la que la traducción no puede seguir el ritmo del borrador. Un verbo alemán puede quedar al final de su cláusula, y el japonés coloca el verbo al final. Cualquier traductor necesita la cláusula completa para traducirla con fidelidad. Traducir palabra por palabra entrega al oyente fragmentos que hay que dejar sin leer hasta que se cierra la cláusula. El alemán ya obligaba a los intérpretes a esperar el verbo mucho antes de que el software lo intentara.
Por eso VocalStack traduce frases, no segmentos. Las frases están activadas por defecto, y con ellas activadas, el servidor ensambla las confirmaciones en una frase y traduce la frase entera. Mientras la frase está abierta, su traducción es provisional; cuando se cierra, la traducción es final. Quien lee mantiene una entrada por frase y la reemplaza a medida que llegan las actualizaciones.
La voz espera todavía más. Solo se lee una frase cerrada, porque una frase que sigue cambiando se volvería a sintetizar con cada revisión. Una frase larga se locuta en trozos, de modo que el primero puede sonar mientras se preparan los demás.
Con las frases desactivadas, cada confirmación recibe en cambio su propio fotograma de traducción. Esa vía no espera nada, pero las frases completas se leen mucho mejor.
Todas estas esperas se miden desde el momento en que el audio llega a VocalStack. En muchas emisiones, el audio ya llegaba tarde.
Cuando la fuente es un stream y no un micrófono, el audio ya va retrasado antes de que se transcriba nada. Va por detrás del borde en directo, el momento más reciente que el stream ha publicado.
Un stream de audio HTTP sencillo, como los que publican la mayoría de las radios por internet, suele ir uno o tres segundos por detrás. El servidor mantiene un búfer de ráfaga: unos segundos de audio reciente, enviados de golpe para que el reproductor de un nuevo oyente pueda arrancar sin cortes. Todos los oyentes, incluido VocalStack, se unen con ese retraso. HLS es peor: sus listas de reproducción empiezan al cliente tres segmentos detrás del borde en directo, lo que en la práctica significa de varios segundos a medio minuto según la duración de los segmentos. DASH estándar suele caer en el mismo rango que HLS; solo su variante de baja latencia baja bastante de ahí. La transmisión «en directo» de una emisora puede ser «en directo» en el mismo sentido en que una carta puede estar «al día».
Estas cifras son aproximadas, y pertenecen al stream, no a la transcripción: ningún ajuste del lado de VocalStack puede recuperarlas. Si esos segundos importan en un evento, introduce el audio desde un micrófono o un codificador en lugar de un stream público. El retraso del stream queda fijado antes de que VocalStack oiga una palabra; el modo de latencia es lo único que realmente puedes mover.
El modo de latencia hace una sola cosa: fija el equilibrio entre retraso y precisión. El ajuste aparece bajo Advanced al crear una transcripción en directo, y en la pestaña Speed mientras se ejecuta. Allí la etiqueta muestra AUTO, SPEED o ACCURACY (Fast aparece como SPEED). A través de la API, session.update cambia el modo durante el stream.
La contrapartida es la que sugieren los nombres. Fast saca el texto antes, pero revisa más; Accuracy tarda un poco más y revisa menos. Un público sentado que lee subtítulos traducidos rara vez nota un segundo extra, pero sí nota las palabras que no dejan de cambiar. Por eso Accuracy suele ser el ajuste más amable, siempre que el gráfico de retraso se mantenga plano. Auto deja ver sus cartas: una línea que aceleró para cerrar un hueco lleva una insignia FAST MODE en la transcripción del anfitrión, con una nota que indica que ahí la precisión puede ser menor.
Sea cual sea el modo, la transcripción tiene que estar lista antes de la primera palabra, y prepararla es el único retraso que la cadena paga una sola vez.
En algunos planes, una transcripción en directo tarda unos segundos en empezar. Cuánto depende del plan: la fila Start-up speed de la página de precios va desde un arranque en frío de hasta 15 segundos en Pago por uso hasta estar siempre caliente en Enterprise.
A través de la API, la espera aparece como fotogramas session.loading mientras la sesión arranca, y después un session.ready; el cliente solo envía audio después de eso. Un oyente que abre el enlace mientras tanto ve "Live. The first line appears in a moment." Una vez que la transcripción está en marcha, este retraso queda atrás, y la única pregunta que queda es cuánto del retraso restante estás cargando.
Mientras una transcripción en directo se ejecuta, la pestaña Speed del anfitrión muestra el resultado de todo esto: la distancia actual entre el orador y el texto, con el chip de modo junto a ella, y un gráfico de esa distancia a lo largo de la grabación con su media y su pico. En la transcripción, una línea que llegó tarde a los oyentes lleva una insignia con el número de segundos entre el momento en que se dijo y el momento en que llegó.
Un gráfico que se mantiene bajo y plano significa que el modo se ajusta al audio. Un gráfico que sube significa que la cadena se está quedando atrás. Con Accuracy, quizá sea el momento de pasar a Auto, que cambia algo de precisión por velocidad hasta que se cierra la distancia.
Los desarrolladores reciben en cambio un solo número. Cuando termina una sesión en tiempo real, session.done incluye stats.realtimeFactor, es decir, el audio transcrito dividido por el tiempo empleado en transcribirlo. Una advertencia sobre la convención: en la literatura de reconocimiento de voz, el factor de tiempo real suele significar lo contrario, el tiempo de procesamiento entre el tiempo de audio, donde menor es mejor. VocalStack lo reporta al revés, así que aquí mayor es mejor: una sesión en directo se sitúa cerca de 1, y por debajo de 1 significa que el audio llegó más deprisa de lo que la cadena podía transcribirlo.
Ninguno de estos segundos es misterioso. Algunos pertenecen al stream, otros a una palabra que espera a la siguiente, otros a la frase que necesita una traducción, y el resto al modo de latencia que elegiste. La referencia de la API tiene el detalle fotograma a fotograma, y la demo de la página de inicio muestra la cadena en funcionamiento.
