Většina zpoždění v živém překladu je čekání: na stream, na další slovo, na větu. Jedinou částí, kterou ovládáte, je režim latence: menší zpoždění, nebo méně revizí.
Posluchač, který čte živý překlad, vidí každý řádek několik sekund poté, co ho řečník vyslovil. Ta mezera není jedno zpoždění, ale několik zpoždění seřazených za sebou v řetězci, a většina z nich je svým způsobem čekání. Když víte, které čekání je které, je volba režimu latence snadná a vývojář, který staví čtečku, ví, co má vykreslovat a kdy.
Než se podíváme na čísla, hodí se jedno měřítko: lidský simultánní tlumočník obvykle mluví se zpožděním dvou až čtyř sekund za řečníkem. Tlumočníci tomu říkají „ear-voice span“ (rozpětí mezi uchem a hlasem) a u jazyků, kde sloveso stojí na konci věty, si nepomáhají tím, že by čekali na sloveso, ale tím, že ho předvídají, nebo větu rozdělí na části, které obstojí samy. Sekunda nebo dvě zpoždění nejsou chyba softwaru; je to zhruba to, co dělá velmi dobrý člověk.
Každý živý přepis na VocalStacku prochází týmiž stupni, ve stejném pořadí, a každý z nich čeká na ten předchozí.
Text v původním jazyce se čtenáři dostane téměř tak, jak zazní. Překlad přijde o sekundu nebo dvě později a mluvená věta přijde až po svém překladu, proto hlasový klip vždy dorazí jako poslední. První viditelný účinek řetězce se ale objeví dlouho před hlasem: samotný text se začne hýbat.
První, čeho si lidé u živého přepisu všimnou, je, že se nejnovější slova hýbou. Fráze se objeví, změní se a ustálí. To je práce konceptové fáze a má důvod, který platí pro každý systém rozpoznávání řeči.
Rozpoznávač ustálí slovo tak, že se podívá na to, co následuje. „I scream“ a „ice cream“ znějí v angličtině stejně, dokud nepřijde další slovo, a koncové „s“ může patřit tomuto slovu, nebo tomu následujícímu. Dokud není zvuk napravo od slova, jeho podoba je odhad, a nejnovější slova v jakémkoli živém přepisu jsou proto vždy nejméně jistá. Koncept je prostě ten odhad, ukázaný včas, místo aby byl skrytý.
Každý koncept nahradí celý živý konec, tedy slova slyšená od posledního potvrzení, která se ještě mění. Potvrzení je konečné. Nikdy se nezmění, nese časování na úrovni slov a potvrzení se číslují bez mezer, takže čtenář pozná, když mu nějaké chybí.
Pro vývojáře je to jediné pravidlo, které realtime API striktně vyžaduje: vykreslit každý potvrzený segment a za ně nejnovější koncept, a koncept vymazat, jakmile přijde potvrzení. Připojování konceptů místo jejich nahrazování dá zdvojený, blikající text; potvrzení prostě spotřebuje konec. Výukový návod pro WebSocket staví čtečku přesně kolem tohoto principu.
Pro hostitele je pohybující se text cenou za nízké zpoždění. Ukázat slova dřív, než je fráze dokončena, je to, co dělá přepis živým. Překlad si ale tenhle trik dovolit nemůže, protože slovo lze odhadnout z poloviny fráze, ale překlad ne.
Pořadí slov je důvod, proč překlad nedrží krok s konceptem. Německé sloveso může stát na konci své věty a japonština klade sloveso vždy na konec. Každý překladatel potřebuje celou větu, než ji věrně vykreslí. Překlad slovo po slovu dá posluchači útržky, které je nutné dočíst zpětně, až se věta uzavře. Němčina nutí tlumočníky čekat na sloveso už dávno předtím, než se to pokusil software.
VocalStack proto překládá věty, ne segmenty. Věty jsou ve výchozím nastavení zapnuté a při nich server spojí potvrzení do věty a přeloží ji celou. Dokud je věta otevřená, je její překlad předběžný; jakmile se uzavře, je překlad konečný. Čtečka drží jednu položku na větu a nahrazuje ji, jak přicházejí aktualizace.
Řeč čeká ještě déle. Mluví se jen uzavřená věta, protože věta, která se ještě mění, by se při každé revizi znovu syntetizovala. Dlouhá věta se mluví po částech, takže první část může hrát, zatímco se dělají ostatní.
Při vypnutých větách dostane každé potvrzení vlastní překladový rámec. Tahle cesta na nic nečeká, ale celé věty se čtou mnohem lépe.
Všechna tato čekání se měří od okamžiku, kdy zvuk dorazí k VocalStacku. U mnoha vysílání byl zvuk už v okamžiku příchodu zpožděný.
Pokud je zdrojem stream, a ne mikrofon, je zvuk už pozadu dřív, než se cokoli přepíše. Zaostává za živou hranou, tedy za nejnovějším okamžikem, který stream zveřejnil.
Prostý HTTP audio stream, jaký publikuje většina internetových rádií, zaostává typicky o sekundu až tři. Server drží burst buffer: několik sekund nedávného zvuku odeslaných naráz, aby přehrávač nového posluchače mohl začít bez zadrhávání. Každý posluchač, VocalStack nevyjímaje, se připojuje tak daleko zpět. HLS je horší: jeho playlisty začínají klienta tři segmenty za živou hranou, což v praxi znamená několik sekund až půl minuty podle délky segmentu. Standardní DASH obvykle spadá do stejného rozsahu jako HLS; jen jeho nízkolatenční varianta jde výrazně pod něj. „Živý“ stream stanice může být živý stejně jako aktuální dopis.
Tyto údaje jsou orientační a patří streamu, ne přepisu: žádné nastavení na straně VocalStacku je nedokáže vrátit zpět. Pokud na těch sekundách u události záleží, přiveďte zvuk do stupně z mikrofonu nebo enkodéru, a ne z veřejného streamu. Zpoždění streamu je pevné ještě předtím, než VocalStack uslyší jediné slovo; režim latence je to, čím můžete opravdu pohnout.
Režim latence dělá jedinou věc: nastavuje rovnováhu mezi zpožděním a přesností. Nastavení je pod položkou Advanced při vytváření živého přepisu a na kartě Speed, dokud přepis běží. Tam čip ukazuje AUTO, SPEED nebo ACCURACY (Fast se zobrazuje jako SPEED). Přes API mění režim za běhu session.update.
Kompromis je ten, který naznačují názvy. Fast dostane text ven dříve, ale musí ho revidovat víc; Accuracy trvá o něco déle a revidovat musí méně. Sedící publikum, které čte přeložené titulky, si zřídka všimne navíc jedné sekundy, ale všimne si slov, která se pořád mění. Accuracy je proto často vhodnější volba, pokud graf zpoždění zůstává rovný. Auto ukazuje, co dělá: řádek, který zrychlil, aby zavřel mezeru, nese v přepisu hostitele odznak FAST MODE s poznámkou, že přesnost tam může být nižší.
V každém režimu musí být přepis připraven před prvním slovem, a příprava je jediné zpoždění, které řetězec platí jen jednou.
U některých tarifů trvá spuštění živého přepisu několik sekund. Záleží na tarifu: řádek Start-up speed na stránce s ceníkem se pohybuje od studeného startu až 15 sekund u tarifu Pay as you go až po trvale připravený stav u Enterprise.
Přes API se čekání projeví jako rámce session.loading, zatímco se relace spouští, a poté session.ready; klient posílá zvuk až potom. Posluchač, který mezitím otevře odkaz, vidí „Živě. První řádek se objeví za chvíli.“ Jakmile přepis běží, je toto zpoždění za vámi a zbývá jen otázka, kolik ze zbývajícího zpoždění nesete.
Během běhu živého přepisu ukazuje hostitelova karta Speed, kolik to celé dohromady dělá: aktuální mezeru mezi řečníkem a textem, s čipem režimu vedle ní, a graf této mezery přes celou nahrávku s průměrem a špičkou. V samotném přepisu nese řádek, který k posluchačům dorazil pozdě, odznak s počtem sekund mezi okamžikem, kdy zazněl, a okamžikem, kdy dorazil.
Graf, který zůstává nízko a rovně, znamená, že režim sedí ke zvuku. Stoupající graf znamená, že zpracování zaostává. Při režimu Accuracy může být tou chvílí přejít na Auto, které vymění část přesnosti za rychlost, dokud se mezera nezavře.
Vývojáři dostanou místo toho jediné číslo. Když relace realtime skončí, session.done nese stats.realtimeFactor, tedy délku přepsaného zvuku dělenou časem, který na přepis spotřebovalo zpracování. Jedno upozornění ke konvenci: v literatuře o rozpoznávání řeči znamená real-time factor obvykle opak, tedy dobu zpracování vůči délce zvuku, kde nižší je lepší. VocalStack ho uvádí obráceně, takže zde platí, že vyšší je lepší: živá relace se drží blízko 1 a hodnota pod 1 znamená, že zvuk přicházel rychleji, než ho zpracování dokázalo přepsat.
Žádné z těchto sekund nejsou záhadné. Některé patří streamu, některé slovu, které čeká na slovo za ním, některé větě, kterou překlad potřebuje, a zbytek režimu latence, který jste zvolili. Referenční dokumentace API obsahuje podrobnosti rámec po rámci a demo na domovské stránce ukazuje celý řetězec v chodu.
