A maior parte do atraso na tradução ao vivo é espera: pelo fluxo, pela próxima palavra, pela frase. A única parte que você controla é o modo de latência: menos atraso ou menos revisões.
Quem lê uma tradução ao vivo vê cada linha alguns segundos depois de o orador tê-la dito. Essa diferença não é um atraso só, mas vários somados ao longo de uma cadeia, e a maioria deles é uma forma de espera. Entender qual espera é qual torna a escolha do modo de latência simples e mostra a um desenvolvedor que está criando um leitor o que renderizar, e quando.
Um parâmetro útil antes dos números: um intérprete humano simultâneo costuma falar de dois a quatro segundos atrás do orador. Os intérpretes chamam essa distância de ear-voice span e, em idiomas de verbo final, não esperam pelo verbo: antecipam-no ou dividem a frase em pedaços que se sustentam sozinhos. Um ou dois segundos de atraso não é um defeito do software; é, mais ou menos, o que faz um ótimo intérprete humano.
Cada transcrição ao vivo no VocalStack passa pelas mesmas etapas, na mesma ordem, e cada uma espera pela anterior.
O texto no idioma original chega ao leitor quase no momento em que é falado. A tradução vem um ou dois segundos depois, e a fala vem depois da sua tradução, por isso um clipe de voz sempre chega por último. O primeiro efeito visível da cadeia, porém, aparece muito antes de qualquer voz: o próprio texto se move.
A primeira coisa que as pessoas notam em uma transcrição ao vivo é que as palavras mais recentes se mexem. Uma frase aparece, muda e se assenta. É a etapa do rascunho em ação, e ela existe por um motivo que vale para todo reconhecedor de fala.
Um reconhecedor define uma palavra olhando para o que vem depois dela. “I scream” e “ice cream” soam iguais até a próxima palavra chegar; um “s” final pode pertencer a esta palavra ou à seguinte. Enquanto não houver áudio à direita de uma palavra, a grafia dela é um palpite, e por isso as palavras mais novas de qualquer transcrição ao vivo são sempre as menos certas. Um rascunho é simplesmente esse palpite mostrado cedo, em vez de escondido.
Cada rascunho substitui por completo a cauda ao vivo: as palavras ouvidas desde a última confirmação, que ainda estão mudando. Uma confirmação é final. Ela nunca muda, traz os tempos de cada palavra, e as confirmações são numeradas sem falhas, para que o leitor perceba se perdeu alguma.
Para um desenvolvedor, esta é a única regra que a API de tempo real exige: renderize todo segmento confirmado e, depois deles, o rascunho mais recente; ao chegar uma confirmação, limpe o rascunho. Acrescentar rascunhos em vez de substituí-los gera texto duplicado e piscando; a confirmação simplesmente consome a cauda. O tutorial de WebSocket cria um leitor exatamente em torno disso.
Para o apresentador, mover o texto é o preço da latência baixa. Mostrar as palavras antes de a frase terminar é o que faz a transcrição parecer ao vivo. A tradução, porém, não pode usar esse truque, porque uma palavra pode ser adivinhada a partir de meia frase, mas uma tradução não.
A ordem das palavras é a razão de a tradução não acompanhar o rascunho. Um verbo alemão pode ficar no fim da oração, e o japonês coloca o verbo por último. Qualquer tradutor precisa da oração inteira para traduzi-la com fidelidade. Traduzir palavra por palavra entrega ao ouvinte fragmentos que precisam ficar sem sentido até a oração fechar. O alemão faz os intérpretes esperar pelo verbo desde muito antes de o software tentar o mesmo.
Por isso o VocalStack traduz frases, não segmentos. As frases vêm ativadas por padrão e, com elas ativadas, o servidor reúne as confirmações em uma frase e traduz a frase inteira. Enquanto a frase está aberta, a tradução é provisória; quando ela fecha, a tradução se torna final. O leitor mantém uma entrada por frase e a substitui à medida que as atualizações chegam.
A fala espera ainda mais. Só uma frase fechada é falada, porque uma frase que ainda está mudando seria sintetizada de novo a cada revisão. Uma frase longa é falada em partes, para que a primeira possa tocar enquanto as demais são geradas.
Com as frases desativadas, cada confirmação recebe seu próprio quadro de tradução. Esse caminho não espera por nada, mas frases inteiras são bem mais agradáveis de ler.
Todas essas esperas são medidas a partir do momento em que o áudio chega ao VocalStack. Em muitas transmissões, o áudio já estava atrasado quando chegou.
Quando a fonte é um fluxo, e não um microfone, o áudio já está atrasado antes de qualquer transcrição. Ele fica para trás da borda ao vivo, o momento mais recente que o fluxo publicou.
Um fluxo de áudio HTTP comum, do tipo que a maioria das rádios na internet publica, costuma ficar de um a três segundos para trás. O servidor mantém um buffer de rajada: alguns segundos de áudio recente, enviados de uma só vez para que o player de um novo ouvinte possa começar sem travar. Todo ouvinte, inclusive o VocalStack, entra nesse ponto anterior. O HLS é pior: suas playlists começam o cliente três segmentos atrás da borda ao vivo, o que, na prática, significa vários segundos a meio minuto, dependendo da duração dos segmentos. O DASH padrão costuma ficar na mesma faixa do HLS; só a variante de baixa latência fica bem abaixo. A transmissão “ao vivo” de uma emissora pode estar ao vivo do mesmo jeito que uma carta é “atual”.
Esses números são aproximados, e pertencem ao fluxo, não à transcrição: nenhuma configuração do lado do VocalStack consegue recuperá-los. Se esses segundos importam para um evento, envie o áudio da etapa a partir de um microfone ou de um encoder, e não de uma transmissão pública. O atraso do fluxo está definido antes de o VocalStack ouvir a primeira palavra; o modo de latência é o que você pode de fato mudar.
O modo de latência faz uma coisa só: define o equilíbrio entre atraso e precisão. A configuração fica em Advanced ao criar uma transcrição ao vivo, e na aba Speed enquanto ela roda. Lá, o selo mostra AUTO, SPEED ou ACCURACY (Fast aparece como SPEED). Pela API, session.update muda o modo durante o fluxo.
A troca é a que os nomes sugerem. O Fast tira o texto mais cedo, mas revisa mais dele; o Accuracy demora um pouco mais e revisa menos. Um público sentado lendo legendas traduzidas raramente percebe um segundo a mais, mas percebe palavras que não param de mudar. Por isso o Accuracy costuma ser a configuração mais gentil, desde que o gráfico de atraso fique estável. O Auto deixa às claras o que faz: uma linha que ele acelerou para fechar um atraso recebe um selo FAST MODE na transcrição do apresentador, com uma nota de que a precisão pode ser menor ali.
Seja qual for o modo, a transcrição precisa estar pronta antes da primeira palavra, e preparar isso é o único atraso que a cadeia paga apenas uma vez.
Em alguns planos, uma transcrição ao vivo leva alguns segundos para começar. Quanto tempo depende do plano: a linha Start-up speed na página de preços vai de uma partida a frio de até 15 segundos no Pague conforme o uso até sempre aquecido no Enterprise.
Pela API, a espera aparece como mensagens session.loading enquanto a sessão começa, seguidas de um session.ready; o cliente só envia áudio depois disso. Um ouvinte que abrir o link nesse meio-tempo vê "Live. The first line appears in a moment." Depois que a transcrição está rodando, esse atraso já ficou para trás, e a única pergunta que resta é quanto do atraso restante você está carregando.
Enquanto uma transcrição ao vivo roda, a aba Speed do apresentador mostra o total de tudo isso: a diferença atual entre o orador e o texto, com o selo do modo ao lado, e um gráfico dessa diferença ao longo da gravação, com a média e o pico. Na própria transcrição, uma linha que chegou tarde aos ouvintes traz um selo com o número de segundos entre o momento em que foi falada e o momento em que chegou.
Um gráfico baixo e estável significa que o modo combina com o áudio. Um gráfico em alta significa que o pipeline está ficando para trás. No Accuracy, pode ser o momento de passar para o Auto, que troca um pouco de precisão por velocidade até a diferença fechar.
Os desenvolvedores recebem um número único. Quando uma sessão de tempo real termina, session.done traz stats.realtimeFactor, que é o áudio transcrito dividido pelo tempo gasto transcrevendo-o. Um alerta sobre convenção: na literatura de reconhecimento de fala, fator de tempo real normalmente significa o inverso, tempo de processamento sobre tempo de áudio, em que menor é melhor. O VocalStack o informa ao contrário, então aqui maior é melhor: uma sessão ao vivo fica perto de 1, e abaixo de 1 significa que o áudio chegou mais rápido do que o pipeline consegue transcrever.
Nenhum desses segundos é misterioso. Alguns pertencem ao fluxo, alguns a uma palavra esperando a seguinte, alguns à frase de que a tradução precisa, e o resto ao modo de latência que você escolheu. A referência da API tem o detalhe mensagem por mensagem, e a demonstração na página inicial mostra a cadeia em funcionamento.
