Mesteparten av forsinkelsen i direkte oversettelse er venting: på strømmen, på neste ord, på setningen. Den ene delen du styrer er latensmodusen: mindre forsinkelse, eller færre revisjoner.
En leser av en direkte oversettelse ser hver linje noen sekunder etter at taleren sa den. Dette gapet er ikke én forsinkelse, men flere, lagt sammen langs en kjede, og de fleste er en form for venting. Når du vet hvilken venting som er hvilken, blir valget av latensmodus enkelt, og det forteller en utvikler som bygger en leser hva som skal vises, og når.
Et nyttig mål før tallene: en menneskelig simultantolk ligger vanligvis to til fire sekunder bak taleren. Tolker kaller dette gapet for ear-voice span, og de håndterer språk med verbet sist ikke ved å vente på verbet, men ved å forutse det, eller ved å dele opp setningen i biter som kan stå alene. Ett til to sekunders forsinkelse er ikke en feil i programvaren; det er omtrent det en svært god tolk også gjør.
Hver direkte transkripsjon hos VocalStack går gjennom de samme trinnene, i samme rekkefølge, og hvert trinn venter på det før.
Teksten på originalspråket når en leser nesten slik den blir sagt. Oversettelsen kommer ett til to sekunder senere, og den talte setningen kommer etter oversettelsen, og derfor kommer et stemmeklipp alltid sist. Den første synlige effekten av kjeden kommer likevel lenge før noen stemme: selve teksten beveger seg.
Det første folk legger merke til i en direkte transkripsjon er at de nyeste ordene flytter seg. En frase dukker opp, endrer seg og setter seg. Det er utkaststadiet som virker, og det finnes av en grunn som gjelder for enhver talegjenkjenner.
En gjenkjenner avgjør et ord ved å se på hva som kommer etter det. På engelsk høres «I scream» og «ice cream» likt ut helt til neste ord kommer, og en avsluttende «s» kan høre til dette ordet eller det neste. Før det finnes lyd til høyre for et ord, er stavemåten en gjetning. De nyeste ordene i en direkte transkripsjon er derfor alltid de minst sikre. Et utkast er rett og slett den gjetningen, vist tidlig i stedet for skjult.
Hvert utkast erstatter hele den løpende halen: ordene som er hørt siden forrige bekreftelse, og som fortsatt endrer seg. En bekreftelse er endelig. Den endrer seg aldri, den har tidspunkter på ordnivå, og bekreftelsene er nummerert uten hull, slik at en leser kan se om en er gått glipp av.
For en utvikler er dette den ene regelen realtids-API-et krever: vis hvert bekreftet segment, deretter det siste utkastet etter dem, og fjern utkastet når en bekreftelse kommer. Hvis du legger til utkast i stedet for å erstatte dem, blir teksten duplisert og flimrer. Bekreftelsen tar bare over halen. WebSocket-veiledningen bygger en leser nettopp rundt dette.
For verten er tekst som beveger seg prisen for lav forsinkelse. Å vise ord før setningen er ferdig er det som gjør transkripsjonen levende. Oversettelsen kan imidlertid ikke ha det trikset, for et ord kan gjettes ut fra en halv frase, men en oversettelse kan ikke det.
Ordstilling er grunnen til at oversettelsen ikke kan følge med utkastet. Et tysk verb kan stå til slutt i leddet, og japansk setter verbet sist. En oversetter trenger hele leddet før den kan gjengi det trofast. Å oversette ord for ord gir en lytter fragmenter som må holdes i hodet til leddet er slutt. Tolker har ventet på verbet på tysk lenge før programvare prøvde seg.
VocalStack oversetter derfor setninger, ikke segmenter. Setninger er på som standard, og med dem på setter serveren bekreftelsene sammen til en setning og oversetter hele den. Så lenge setningen er åpen, er oversettelsen forløpig; når den er lukket, er oversettelsen endelig. En leser har én oppføring per setning, og erstatter den etter hvert som oppdateringer kommer.
Talen venter enda lenger. Bare en lukket setning blir lest opp, for en setning som fortsatt endrer seg ville blitt syntetisert på nytt ved hver revisjon. En lang setning leses opp i biter, slik at den første kan spilles av mens resten lages.
Med setninger av får hver bekreftelse i stedet sin egen oversettelsesramme. Den veien venter ingenting, men hele setninger leses langt bedre.
Alle disse ventetidene måles fra det øyeblikket lyden når VocalStack. For mange kringkastinger var lyden allerede forsinket da den kom fram.
Når kilden er en strøm og ikke en mikrofon, er lyden allerede bak før noe transkriberes. Den henger etter live-kanten, det nyeste øyeblikket strømmen har publisert.
En vanlig HTTP-lydstrøm, slik de fleste nettradiostasjoner publiserer, ligger typisk ett til tre sekunder bak. Serveren har en burst-buffer: noen sekunder med nylig lyd, sendt på én gang, slik at en ny lyttespiller kan starte uten å stoppe. Alle lyttere, også VocalStack, begynner så langt tilbake. HLS er verre: spillelistene starter en klient tre segmenter bak live-kanten, og i praksis betyr det flere sekunder til et halvt minutt, avhengig av segmentlengden. Standard DASH ligger vanligvis i samme område som HLS; bare varianten med lav forsinkelse kommer vesentlig under. En stasjons «direkte»-strøm kan være direkte på samme måte som et brev kan være «oppdatert».
Tallene er omtrentlige, og de hører til strømmen, ikke transkripsjonen: ingen innstilling på VocalStack-siden kan hente dem tilbake. Hvis de sekundene betyr noe for et arrangement, mates lyden inn fra en mikrofon eller en enkoder i stedet for en offentlig strøm. Forsinkelsen fra strømmen er fastsatt før VocalStack hører et ord; det er latensmodusen du faktisk kan flytte.
Latensmodusen gjør én ting: den setter balansen mellom forsinkelse og nøyaktighet. Innstillingen ligger under Advanced når en direkte transkripsjon opprettes, og på Speed-fanen mens den kjører. Der leser brikken AUTO, SPEED eller ACCURACY (Fast vises som SPEED). Via API-et endrer session.update modusen midt i strømmen.
Avveiningen er den navnene antyder. Fast får teksten ut tidligere, men reviderer mer av den; Accuracy bruker litt lenger og reviderer mindre. Et sittende publikum som leser oversatte undertekster merker sjelden et ekstra sekund, men de merker ord som hele tiden endrer seg. Accuracy er derfor ofte det snilleste valget, så lenge forsinkelsesdiagrammet er flatt. Auto viser også hva den gjør: en linje den har gjort raskere for å lukke et gap, har et merke FAST MODE i vertens transkripsjon, med en merknad om at nøyaktigheten kan være lavere der.
Uansett modus må transkripsjonen være klar før det første ordet, og det er den ene forsinkelsen kjeden bare betaler én gang.
På noen abonnement tar en direkte transkripsjon noen sekunder å starte. Hvor lang tid det tar, avhenger av abonnementet: radene for Start-up speed på prisisiden går fra en kaldstart på opptil 15 sekunder på Betal etter bruk til alltid varm på Enterprise.
Over API-et viser ventetiden seg som session.loading-rammer mens sesjonen starter, deretter en session.ready; klienten sender lyd først etter det. En lytter som åpner lenken i mellomtiden ser «Direkte. Den første linjen vises om et øyeblikk.» Når transkripsjonen kjører, er denne forsinkelsen bak deg, og det eneste spørsmålet som gjenstår er hvor mye av den gjenværende forsinkelsen du bærer.
Mens en direkte transkripsjon kjører, viser vertens Speed-fane hva alt dette summerer seg til: gapet mellom taleren og teksten akkurat nå, med modusbrikken ved siden av, og et diagram over gapet gjennom opptaket med gjennomsnitt og topp. I selve transkripsjonen har en linje som nådde lyttere sent et merke med antall sekunder mellom når den ble sagt og når den kom fram.
Et diagram som holder seg lavt og flatt betyr at modusen passer lyden. Et diagram som stiger betyr at pipelinen henger etter. På Accuracy kan det være øyeblikket for å gå over til Auto, som bytter litt nøyaktighet mot fart til gapet lukkes.
Utviklere får ett enkelt tall i stedet. Når en realtidssesjon avsluttes, inneholder session.done stats.realtimeFactor, som er lengden på lyden som er transkribert delt på tiden som gikk med til å transkribere den. En konvensjonsadvarsel: i litteraturen om talegjenkjenning betyr real-time factor vanligvis det motsatte, prosesseringstid over lydtid, der lavere er bedre. VocalStack rapporterer den motsatt, så her er høyere bedre: en direkte sesjon ligger nær 1, og under 1 betyr at lyden kom raskere enn pipelinen kunne transkribere den.
Ingen av disse sekundene er mystiske. Noen hører til strømmen, noen til et ord som venter på ordet etter, noen til setningen en oversettelse trenger, og resten til latensmodusen du valgte. API-referansen har detaljene ramme for ramme, og demoen på startsiden viser kjeden i praksis.
