La major part del retard en la traducció en directe és espera: al flux, a la paraula següent, a la frase. L'únic factor que controles és el mode de latència: menys retard o menys revisions.
Un oient que llegeix una traducció en directe veu cada línia uns quants segons després que la persona que parla l'hagi dita. Aquesta distància no és un únic retard, sinó diversos que se sumen al llarg d'una cadena, i la majoria són una forma d'espera. Saber quina espera és cadascuna fa que triar el mode de latència sigui una decisió fàcil, i indica a qui desenvolupa un lector què cal mostrar i quan.
Abans de les xifres, un punt de referència útil: un intèrpret simultani humà sol parlar entre dos i quatre segons per darrere de la persona que parla. Els intèrprets anomenen aquesta distància ear-voice span, i per als idiomes amb el verb al final no esperen el verb, sinó que l'anticipen o divideixen la frase en trossos que es poden entendre per separat. Un o dos segons de retard no és un defecte del programari; és més o menys el que fa un molt bon intèrpret humà.
Cada transcripció en directe a VocalStack passa per les mateixes etapes, en el mateix ordre, i cadascuna espera l'anterior.
El text en la llengua original arriba a un lector gairebé tal com es diu. La traducció arriba un o dos segons més tard, i la frase parlada arriba després de la seva traducció, per això un clip de veu sempre és l'últim en arribar. El primer efecte visible de la cadena, però, arriba molt abans de qualsevol veu: el text mateix es mou.
La primera cosa que la gent nota en una transcripció en directe és que les paraules més recents es mouen. Apareix una frase, canvia i s'assenta. Això és la fase d'esborrany en acció, i existeix per una raó que s'aplica a qualsevol reconeixedor de la parla.
Un reconeixedor decideix una paraula mirant què hi ha després. «I scream» i «ice cream» sonen igual fins que arriba la paraula següent; una «s» final pot pertànyer a aquesta paraula o a la següent. Mentre no hi hagi àudio a la dreta d'una paraula, la seva ortografia és una suposició, de manera que les paraules més recents de qualsevol transcripció en directe són sempre les menys segures. Un esborrany és simplement aquesta suposició mostrada d'hora en lloc d'amagada.
Cada esborrany substitueix completament la cua en directe: les paraules sentides des de la darrera confirmació, que encara canvien. Una confirmació és definitiva. Mai no canvia, porta temps a nivell de paraula, i les confirmacions es numeren sense forats perquè un lector pugui saber si n'ha perdut alguna.
Per a un desenvolupador, aquesta és l'única regla que l'API en temps real exigeix: mostra cada segment confirmat i, després d'ells, l'últim esborrany; esborra l'esborrany quan arriba una confirmació. Afegir esborranys en lloc de substituir-los produeix text duplicat i parpellejant; la confirmació simplement consumeix la cua. El tutorial de WebSocket construeix un lector exactament sobre aquesta base.
Per a l'anfitrió, el text que es mou és el preu d'un retard baix. Mostrar paraules abans que la frase estigui acabada és el que fa que la transcripció se senti en directe. La traducció, però, no es pot permetre aquest truc, perquè una paraula es pot endevinar a partir de mitja frase, però una traducció no.
L'ordre de les paraules és la raó per la qual la traducció no pot anar al mateix ritme que l'esborrany. Un verb alemany pot quedar al final de la seva clàusula, i el japonès posa el verb al final. Qualsevol traductor necessita tota la clàusula abans de traduir-la fidelment. Traduir paraula per paraula dona a l'oient fragments que cal desfer quan la clàusula es tanca. L'alemany ha fet esperar els intèrprets pel verb molt abans que el programari ho intentés.
Per tant, VocalStack tradueix frases, no segments. Les frases estan activades per defecte, i amb elles activades el servidor munta les confirmacions en una frase i en tradueix el conjunt. Mentre la frase està oberta, la seva traducció és provisional; quan es tanca, la traducció és definitiva. Un lector té una entrada per frase i la reemplaça a mesura que arriben les actualitzacions.
La parla espera encara més. Només es parla una frase tancada, perquè una frase que encara canvia es tornaria a sintetitzar a cada revisió. Una frase llarga es parla a trossos, de manera que el primer pot sonar mentre es preparen la resta.
Amb les frases desactivades, cada confirmació rep el seu propi marc de traducció. Aquest camí no espera res, però les frases senceres es llegeixen molt millor.
Totes aquestes esperes es mesuren des del moment en què l'àudio arriba a VocalStack. En moltes emissions, l'àudio ja anava tard quan hi va arribar.
Quan la font és un flux en lloc d'un micròfon, l'àudio ja va per darrere abans que es transcrigui res. Va per darrere de la vora en directe, el moment més recent que el flux ha publicat.
Un flux d'àudio HTTP simple, el tipus que publiquen la majoria d'emissores de ràdio per internet, sol anar d'un a tres segons per darrere. El servidor manté una memòria intermèdia de ràfega: uns quants segons d'àudio recent, enviats tots alhora perquè el reproductor d'un nou oient pugui començar sense aturar-se. Tots els oients, VocalStack inclòs, es connecten aquesta distància enrere. HLS és pitjor: les seves llistes de reproducció fan que un client comenci tres segments per darrere de la vora en directe, cosa que a la pràctica vol dir diversos segons o fins a mig minut segons la durada del segment. El DASH estàndard sol situar-se en el mateix rang que HLS; només la seva variant de baixa latència baixa força per sota. Un flux «en directe» d'una emissora pot estar en directe de la mateixa manera que una carta és actual.
Aquestes xifres són aproximades i pertanyen al flux, no a la transcripció: cap configuració per part de VocalStack no els pot recuperar. Si aquells segons importen per a un esdeveniment, alimenta l'escenari amb àudio d'un micròfon o d'un codificador en lloc d'un flux públic. El retard del flux queda fixat abans que VocalStack senti cap paraula; el mode de latència és el que realment pots moure.
El mode de latència fa una sola cosa: fixa l'equilibri entre retard i precisió. La configuració es troba sota Advanced quan es crea una transcripció en directe, i a la pestanya Speed mentre s'executa. Allà, l'etiqueta mostra AUTO, SPEED o ACCURACY (Fast apareix com a SPEED). Per l'API, session.update canvia el mode durant el flux.
La compensació és la que suggereixen els noms. Fast fa sortir el text abans però en revisa més; Accuracy triga una mica més i en revisa menys. Un públic assegut que llegeix subtítols traduïts rarament nota un segon més, però sí que nota les paraules que no paren de canviar. Per això Accuracy sovint és la configuració més amable, sempre que el gràfic de retard es mantingui pla. Auto mostra les seves cartes: una línia que va accelerar per tancar una bretxa porta una insígnia FAST MODE a la transcripció de l'anfitrió, amb una nota que indica que la precisió pot ser inferior en aquell punt.
Sigui quin sigui el mode, la transcripció ha d'estar a punt abans de la primera paraula, i preparar-la és l'únic retard que la cadena paga només una vegada.
En alguns plans, una transcripció en directe triga uns quants segons a començar. Depèn del pla: la fila «Velocitat d'arrencada» de la pàgina de preus va des d'una arrencada en fred de fins a 15 segons en el Pagament per ús fins a estar sempre activa a Enterprise.
Per l'API, l'espera es veu als frames session.loading mentre la sessió s'inicia, seguits d'un session.ready; el client només envia àudio després d'això. Un oient que obri l'enllaç mentrestant veu «En directe. La primera línia apareix d'un moment a l'altre.» Quan la transcripció ja està en marxa, aquest retard ja és enrere, i l'única pregunta que queda és quant del retard restant estàs carregant.
Mentre una transcripció en directe s'executa, la pestanya Speed de l'anfitrió mostra el total de tot això: la bretxa actual entre la persona que parla i el text, amb l'etiqueta del mode al costat, i un gràfic d'aquesta bretxa al llarg de la gravació amb la seva mitjana i el pic. A la transcripció, una línia que ha arribat tard als oients porta una insígnia amb el nombre de segons entre el moment en què es va dir i el moment en què va arribar.
Un gràfic que es manté baix i pla vol dir que el mode s'adapta a l'àudio. Un gràfic que puja vol dir que el procés va per darrere. En Accuracy, potser és el moment de passar a Auto, que canvia una mica de precisió per velocitat fins que la bretxa es tanca.
Els desenvolupadors obtenen un sol número. Quan acaba una sessió en temps real, session.done porta stats.realtimeFactor: l'àudio transcrit dividit pel temps invertit a transcriure'l. Un avís sobre la convenció: a la literatura del reconeixement de la parla, factor de temps real sol significar el contrari, temps de procés dividit pel temps d'àudio, on com més baix millor. VocalStack el reporta a la inversa, de manera que aquí com més alt millor: una sessió en directe es troba al voltant de 1, i per sota de 1 significa que l'àudio va arribar més de pressa del que el procés podia transcriure.
Cap d'aquests segons és misteriós. Alguns pertanyen al flux, altres a una paraula que espera la paraula següent, altres a la frase que necessita una traducció, i la resta al mode de latència que has triat. L'referència de l'API té el detall frame a frame, i la demostració de la pàgina d'inici mostra la cadena en funcionament.
