Večina zamude pri prevodu v živo je čakanje: na tok, na naslednjo besedo, na stavek. Edini del, ki ga lahko nadzorujete, je način zakasnitve: manj zamude ali manj popravkov.
Gledalec, ki bere prevod v živo, vidi vsako vrstico nekaj sekund po tem, ko jo je govorec izrekel. Ta razmik ni ena sama zamuda, ampak več zamud, ki se seštevajo vzdolž verige, in večina med njimi je oblika čakanja. Če veste, katero čakanje je katero, je izbira načina zakasnitve enostavna, razvijalcu, ki gradi bralnik, pa pove, kaj in kdaj naj prikaže.
Uporaben primerjalni okvir pred številkami: človeški simultani tolmač običajno govori dve do štiri sekunde za govorcem. Tolmači temu razmiku pravijo razmik uho–glas (ear-voice span), pri jezikih, kjer glagol stoji na koncu, pa ne čakajo na glagol, ampak ga predvidevajo ali stavek razdelijo na dele, ki lahko stojijo sami zase. Sekunda ali dve zamude nista napaka programske opreme; to je približno tisto, kar naredi zelo dober človek.
Vsak prepis v živo na VocalStack gre skozi enake faze, v istem vrstnem redu, in vsaka čaka na prejšnjo.
Besedilo v izvirnem jeziku doseže bralca skoraj takoj, ko je izgovorjeno. Prevod sledi za sekundo ali dve, izrečeni stavek pa pride za svojim prevodom, zato posnetek glasu vedno pride zadnji. Prvi viden učinek verige pa pride dolgo pred glasom: samo besedilo se premika.
Prva stvar, ki jo ljudje opazijo v prepisu v živo, je, da se najnovejše besede premikajo. Fraza se pojavi, spremeni in se ustali. To je delo faze osnutka, ta pa obstaja zaradi razloga, ki velja za vsak razpoznavalnik govora.
Razpoznavalnik besedo določi tako, da pogleda, kaj sledi. Besedni par »I scream« in »ice cream« zveni enako, dokler ne pride naslednja beseda; končni »s« lahko pripada tej ali naslednji besedi. Dokler ni zvoka desno od besede, je njen zapis ugibanje, zato so najnovejše besede v vsakem prepisu v živo vedno najmanj zanesljive. Osnutek je preprosto to ugibanje, prikazano zgodaj namesto skritega.
Vsak osnutek v celoti nadomesti živi rep: besede, slišane od zadnje potrditve, ki se še spreminjajo. Potrditev je dokončna. Nikoli se ne spremeni, ima časovne oznake za posamezne besede, potrditve pa so zaporedno oštevilčene brez vrzeli, tako da bralec opazi, če je kakšno zamudil.
Za razvijalca je to edino pravilo, ki ga realtime API zahteva: prikaži vsak potrjen segment, za njimi zadnji osnutek, osnutek pa počisti, ko pride potrditev. Dodajanje osnutkov namesto njihovega nadomeščanja povzroči podvojeno, utripajoče besedilo; potrditev preprosto pojé rep. Vadnica za WebSocket gradi bralnik prav okoli tega.
Za gostitelja je premikanje besedila cena nizke zakasnitve. Prikaz besed, preden je fraza končana, je tisto, zaradi česar se prepis zdi živ. Prevod pa si tega triku ne more privoščiti, ker se besedo da uganiti iz pol fraze, prevoda pa ne.
Vrstni red besed je razlog, zakaj prevod ne more slediti osnutku. Nemški glagol lahko stoji na koncu stavčne enote, japonščina pa postavi glagol na konec. Vsak prevajalec potrebuje celotno stavčno enoto, preden jo zvesto upodobi. Prevod beseda za besedo bi poslušalcu dal odlomke, ki jih mora po zaprtju stavka razumeti nazaj. Tolmači so zaradi nemščine čakali na glagol že dolgo, preden se je programska oprema tega sploh lotila.
VocalStack zato prevaja stavke, ne odsekov. Stavki so privzeto vklopljeni, in ko so, strežnik potrditve sestavi v stavek in prevede celoten stavek. Dokler je stavek odprt, je njegov prevod začasen; ko se zapre, je prevod dokončen. Bralec drži en vnos na stavek in ga zamenja, ko prihajajo posodobitve.
Govor čaka še dlje. Prebrani so samo zaprti stavki, ker bi se stavek, ki se še spreminja, ob vsaki reviziji znova sintetiziral. Dolg stavek se bere na glas po delih, tako da lahko prvi del igra, medtem ko se izdelujejo ostali.
Če so stavki izklopljeni, dobi vsaka potrditev svoj okvir prevoda. Ta pot ne čaka ničesar, vendar so celi stavki veliko lepši za branje.
Vse te čakalne dobe se merijo od trenutka, ko zvok prispe do VocalStack. Pri mnogih prenosih je zvok ob prihodu že zamujal.
Kadar je vir tok, ne mikrofon, je zvok že zadaj, preden se kaj prepiše. Zaostaja za robom v živo, najnovejšim trenutkom, ki ga je tok objavil.
Navaden HTTP zvočni tok, kakršnega objavlja večina spletnih radijskih postaj, običajno zaostaja za sekundo ali tri. Strežnik ima medpomnilnik za izbruh: nekaj sekund nedavnega zvoka, poslanega naenkrat, da se predvajalnik novega poslušalca lahko zažene brez zastojev. Vsak poslušalec, tudi VocalStack, se pridruži tako daleč nazaj. HLS je slabši: njegovi seznami predvajanja začnejo odjemalca tri segmente za robom v živo, kar v praksi pomeni od nekaj sekund do pol minute, odvisno od dolžine segmentov. Standardni DASH običajno pride v isti razpon kot HLS; le njegova različica z nizko zakasnitvijo je precej pod tem. »Živi« tok postaje je lahko živ tako, kot je lahko pismo aktualno.
Te številke so približne in pripadajo toku, ne prepisu: nobena nastavitev na strani VocalStack teh sekund ne more povrniti. Če so te sekunde pomembne za dogodek, zvok posredujte z mikrofona ali kodirnika, ne z javnega toka. Zamuda toka je določena, preden VocalStack sliši eno samo besedo; način zakasnitve je tisto, kar lahko dejansko premaknete.
Način zakasnitve opravi eno stvar: nastavi ravnovesje med zakasnitvijo in natančnostjo. Nastavitev je pod Advanced, ko ustvarite prepis v živo, na zavihku Speed pa med delovanjem. Tam značka prikazuje AUTO, SPEED ali ACCURACY (Fast se prikaže kot SPEED). Prek API-ja session.update spremeni način med tokom.
Trgovina je ta, ki jo nakazujejo imena. Fast besedilo hitreje pošlje ven, vendar ga revidira več; Accuracy vzame malo več časa in revidira manj. Gledalec, ki sedi in bere prevedene podnapise, redko opazi dodatno sekundo, pa opazi besede, ki se ves čas spreminjajo. Accuracy je zato pogosto prijaznejša nastavitev, dokler graf zakasnitve ostaja raven. Auto pokaže, kaj počne: vrstica, ki jo je pospešil, da bi zaprl vrzel, nosi značko FAST MODE v prepisu gostitelja z opombo, da je tam natančnost lahko nižja.
Ne glede na način mora biti prepis pripravljen pred prvo besedo, pripravljanje pa je edina zamuda, ki jo veriga plača samo enkrat.
Pri nekaterih paketih se prepis v živo zažene nekaj sekund. Koliko, je odvisno od paketa: vrstica Start-up speed na strani cenika gre od hladnega zagona z zamudo do 15 sekund pri paketu Pay as you go do vedno segretega pri paketu Enterprise.
Prek API-ja se čakanje pokaže kot okvirji session.loading, medtem ko se seja zaganja, nato session.ready; odjemalec pošlje zvok šele potem. Poslušalec, ki medtem odpre povezavo, vidi »Live. The first line appears in a moment.« Ko prepis teče, je ta zamuda za vami, edino vprašanje, ki ostane, pa je, koliko preostale zamude še nosite.
Medtem ko prepis v živo teče, zavihek Speed pri gostitelju prikazuje, kaj vse to skupaj znaša: trenutno razliko med govorcem in besedilom, poleg nje značko načina, ter graf te razlike skozi posnetek s povprečjem in največjo vrednostjo. V samem prepisu vrstica, ki je prišla do poslušalcev pozno, nosi značko s številom sekund med trenutkom izgovora in trenutkom prihoda.
Graf, ki ostaja nizko in raven, pomeni, da način ustreza zvoku. Graf, ki se vzpenja, pomeni, da cevovod zaostaja. Pri Accuracy bi to lahko bil trenutek za preklop na Auto, ki zamenja nekaj natančnosti za hitrost, dokler se vrzel ne zapre.
Razvijalci namesto tega dobijo eno številko. Ko se seja v živo konča, session.done nosi stats.realtimeFactor, to je prepisani zvok, deljen s časom, porabljenim za prepisovanje. Opozorilo glede konvencije: v literaturi o razpoznavanju govora realtime factor običajno pomeni obratno, čas obdelave, deljen z zvočnim časom, kjer je manj boljše. VocalStack ga prikazuje obratno, zato tu velja, da je več boljše: seja v živo je blizu 1, pod 1 pa pomeni, da je zvok prispel hitreje, kot ga je cevovod lahko prepisal.
Nobena od teh sekund ni skrivnostna. Nekatere pripadajo toku, nekatere besedi, ki čaka na naslednjo, nekatere stavku, ki ga prevod potrebuje, preostale pa načinu zakasnitve, ki ste ga izbrali. Referenca API-ja vsebuje podrobnosti okvir za okvirjem, predstavitev na domači strani pa prikazuje verigo v delovanju.
