A maior parte do atraso na tradución en directo é espera: pola emisión, pola seguinte palabra, pola frase. A única parte que controlas é o modo de latencia: menos atraso ou menos revisións.
Unha persoa oínte que le unha tradución en directo ve cada liña uns segundos despois de que o falante a dixese. Esa diferenza non é un único atraso, senón varios sumados ao longo dunha cadea, e a maioría deles son unha forma de espera. Coñecer cada espera fai que a elección do modo de latencia sexa sinxela, e indica a quen desenvolve que debe mostrar nun lector, e cando.
Un referente útil antes dos números: un intérprete simultáneo humano adoita falar de dous a catro segundos por detrás do falante. Os intérpretes chaman a esa distancia o «intervalo oído-voz», e nas linguas de verbo final non agardan polo verbo, senón que o anticipan, ou dividen a frase en anacos que poden sosterse por si mesmos. Un ou dous segundos de atraso non é un defecto do software; é aproximadamente o que fai unha persoa moi boa no oficio.
Cada transcrición en directo en VocalStack pasa polas mesmas etapas, na mesma orde, e cada unha espera pola anterior.
O texto na lingua orixinal chega a un lector case tal como se fala. A tradución segue un ou dous segundos despois, e a frase falada chega despois da súa tradución, por iso un clip de voz sempre chega o último. O primeiro efecto visible da cadea, con todo, chega moito antes de calquera voz: o propio texto se move.
A primeira cousa que a xente nota nunha transcrición en directo é que as palabras máis recentes se moven. Unha frase aparece, cambia e asenta. Esa é a etapa de borrador en acción, e existe por unha razón que afecta a todo recoñecedor de fala.
Un recoñecedor asenta unha palabra mirando o que vén despois. «I scream» e «ice cream» soan igual ata que chega a palabra seguinte; unha «s» final pode pertencer a esta palabra ou á seguinte. Ata que hai audio á dereita dunha palabra, a súa grafía é unha suposición, así que as palabras máis recentes de calquera transcrición en directo son sempre as menos seguras. Un borrador é simplemente esa suposición mostrada cedo en vez de ocultada.
Cada borrador substitúe por completo a cola en directo: as palabras escoitadas desde a última confirmación, que aínda cambian. Unha confirmación é final. Nunca cambia, leva marcas de tempo a nivel de palabra, e as confirmacións van numeradas sen saltos para que un lector poida detectar se perdeu unha.
Para quen desenvolve isto, é a única regra que a API en tempo real esixe: renderizar cada segmento confirmado, despois o último borrador detrás deles, e limpar o borrador cando chega unha confirmación. Engadir borradores en vez de substituílos produce texto duplicado e con tremor; a confirmación simplemente consome a cola. O tutorial de WebSocket constrúe un lector precisamente sobre isto.
Para un anfitrión, mover o texto é o prezo do atraso baixo. Mostrar palabras antes de que a frase remate é o que fai que a transcrición se sinta en directo. A tradución, en cambio, non se pode permitir ese truco, porque unha palabra pode adiviñarse a partir de media frase, pero unha tradución non.
A orde das palabras é a razón de que a tradución non poida seguir o ritmo do borrador. Un verbo alemán pode quedar ao final da súa cláusula, e o xaponés pon o verbo o último. Calquera tradutor necesita a cláusula completa para render o sentido con fidelidade. Traducir palabra a palabra entrega ao oínte fragmentos que hai que deixar sen ler cando pecha a cláusula. O alemán fixo que os intérpretes esperasen polo verbo moito antes de que o software o intentase.
Por iso VocalStack traduce frases, non segmentos. As frases están activadas por defecto, e con elas activadas o servidor une as confirmacións nunha frase e traduce a frase completa. Mentres a frase está aberta a súa tradución é provisional; cando pecha, a tradución é final. Un lector mantén unha entrada por frase e substitúea segundo chegan as actualizacións.
A voz espera aínda máis. Só se fala unha frase pechada, porque unha frase que aínda cambia volvería sintetizarse en cada revisión. Unha frase longa fálase en pedazos, de modo que o primeiro pode sonar mentres se xeran os demais.
Con as frases desactivadas, cada confirmación recibe o seu propio cadro de tradución. Esa vía non espera por nada, pero as frases completas len moito mellor.
Todas estas esperas se miden desde o momento en que o audio chega a VocalStack. Nunha morea de emisións, o audio xa ía atrasado cando chegou.
Cando a orixe é un fluxo e non un micrófono, o audio xa vai atrasado antes de transcribirse. Vai por detrás do bordo en directo, o momento máis novo que o fluxo publicou.
Un fluxo de audio HTTP simple, do tipo que publican a maioría das emisoras de radio por internet, adoita ir un ou tres segundos por detrás. O servidor mantén un búfer de ráfaga: uns segundos de audio recente, enviados de golpe para que o reprodutor dun novo oínte poida arrancar sen quedarse parado. Todos os oíntes, incluído VocalStack, entran tanto atrás. HLS é peor: as súas listas de reprodución comezan un cliente tres segmentos por detrás do bordo en directo, o que na práctica significa varios segundos ou medio minuto, segundo a lonxitude do segmento. DASH estándar adoita quedar no mesmo rango que HLS; só a súa variante de baixa latencia baixa bastante. O fluxo «en directo» dunha estación pode estar en directo do mesmo xeito que unha carta está ao día.
Estas cifras son aproximadas, e pertencen ao fluxo, non á transcrición: ningunha opción do lado de VocalStack as pode recuperar. Se eses segundos importan nun evento, alimenta a etapa con audio dun micrófono ou dun codificador en vez dun fluxo público. O atraso do fluxo fíxase antes de que VocalStack escoite unha palabra; o modo de latencia é o que de verdade podes mover.
O modo de latencia fai unha única cousa: fixa o equilibrio entre atraso e precisión. A opción está en Advanced cando se crea unha transcrición en directo, e na pestana Speed mentres se executa. Alí o distintivo lee AUTO, SPEED ou ACCURACY (Fast aparece como SPEED). Pola API, session.update cambia o modo a mitad do fluxo.
A compensación é a que suxiren os nomes. Fast saca o texto antes pero revisa máis; Accuracy tarda un pouco máis e revisa menos. Un público sentado que le subtítulos traducidos raramente nota un segundo extra, pero sí nota palabras que non paran de cambiar. Por iso Accuracy adoita ser a opción máis amable, sempre que o gráfico de atraso se manteña plano. Auto deixa ver as súas cartas: unha liña que acelerou para pechar unha diferenza leva un distintivo FAST MODE na transcrición do anfitrión, cunha nota de que a precisión pode ser menor aí.
Sexa cal sexa o modo, a transcrición debe estar lista antes da primeira palabra, e prepararla é o único atraso que a cadea paga só unha vez.
Nalgúns plans, unha transcrición en directo tarda uns segundos en arrancar. Canto depende do plan: a fila Velocidade de arranque da páxina de prezos vai desde un arranque en frío de ata 15 segundos en Pagamento por uso ata sempre quente en Enterprise.
Pola API, a espera aparece como cadros session.loading mentres arranca a sesión, e despois un session.ready; o cliente só envía audio despois. Un oínte que abra a ligazón mentres tanto ve «En directo. A primeira liña aparece nun momento.» Unha vez que a transcrición está en marcha, este atraso queda atrás, e a única pregunta que queda é canto do atraso restante estás a levar.
Mentres se executa unha transcrición en directo, a pestana Speed do anfitrión mostra o total de todo isto: a diferenza actual entre o falante e o texto, co chip do modo ao lado, e un gráfico desa diferenza ao longo da gravación, coa súa media e o seu pico. No propio texto da transcrición, unha liña que chegou tarde aos oíntes leva un distintivo co número de segundos entre o momento en que se dixo e o momento en que chegou.
Un gráfico que se mantén baixo e plano indica que o modo se axusta ao audio. Un gráfico que sobe indica que a canalización vai quedando atrás. En Accuracy, pode ser o momento de pasar a Auto, que cambia algo de precisión por velocidade ata que a diferenza se pecha.
Quen desenvolve obtén un único número no seu lugar. Cando remata unha sesión en tempo real, session.done leva stats.realtimeFactor: o audio transcrito dividido polo tempo empregado en transcribilo. Un aviso sobre a convención: na literatura de recoñecemento de fala, factor de tempo real adoita significar o inverso, tempo de procesamento sobre tempo de audio, onde menor é mellor. VocalStack o informa ao revés, así que aquí maior é mellor: unha sesión en directo sitúase preto de 1, e por debaixo de 1 significa que o audio chegou máis rápido do que a canalización o podía transcribir.
Ningún destes segundos é misterioso. Algúns pertencen ao fluxo, outros a unha palabra que espera pola seguinte, outros á frase que necesita unha tradución, e o resto ao modo de latencia que escolliches. A referencia da API ten o detalle cadro a cadro, e a demostración da páxina de inicio mostra a cadea en funcionamento.
