A késleltetés legnagyobb része várakozás: az adatfolyamra, a következő szóra, a mondatra. Az egyetlen rész, amit te szabályozhatsz, a késleltetési mód: kevesebb késleltetés vagy kevesebb utólagos módosítás.
Az élő fordítást olvasó hallgató minden sort néhány másodperccel azután lát, hogy a beszélő kimondta. Ez a késés nem egyetlen késleltetés, hanem több, egy láncban összeadódó késleltetés, és ezek legtöbbje valójában várakozás. Ha tudod, melyik várakozás micsoda, a késleltetési mód választása egyszerű döntés lesz, a fejlesztő pedig tudni fogja, mit és mikor jelenítsen meg az olvasó.
Mérce a számok előtt: egy emberi szimultántolmács jellemzően két-négy másodperccel marad le a beszélő mögött. A tolmácsok ezt a rést fül–hang távolságnak (ear-voice span) nevezik. Az igevégű nyelvekkel, például a némettel vagy a japánnal úgy birkóznak meg, hogy nem várják ki az igét, hanem megsejtik, vagy olyan darabokra bontják a mondatot, amelyek önmagukban is megállnak. Egy-két másodperc késleltetés tehát nem a szoftver hibája; nagyjából az, amit egy nagyon jó emberi tolmács is produkál.
Minden élő átírás a VocalStacken ugyanazokon a szakaszokon megy át, ugyanabban a sorrendben, és mindegyik megvárja az előzőt.
Az eredeti nyelvű szöveg szinte azonnal eljut az olvasóhoz, ahogy elhangzik. A fordítás egy-két másodperccel később követi, a kimondott mondat pedig a fordítása után következik, ezért a hangklip mindig utoljára érkezik. A lánc első látható hatása azonban jóval a hang előtt jelentkezik: maga a szöveg mozog.
Az élő átiratban az emberek először azt veszik észre, hogy a legfrissebb szavak mozognak. Egy kifejezés megjelenik, megváltozik, majd megáll. Ezt a piszkozat-szakasz okozza, és ez minden beszédfelismerőre igaz.
A felismerő úgy dönt egy szó alakjáról, hogy megnézi, mi következik utána. Az „I scream” és az „ice cream” angolul egyformán hangzik a következő szóig; a záró „s” az adott szóhoz is tartozhat, és a következőhöz is. Amíg nincs hang a szó jobb oldalán, a helyesírása tipp, ezért az élő átirat legfrissebb szavai mindig a legbizonytalanabbak. A piszkozat tulajdonképpen ez a korai tipp, amelyet nem rejtünk el.
Minden piszkozat teljesen felülírja az élő végét: azokat a szavakat, amelyek az utolsó véglegesítés óta hangzottak el, és még változnak. A véglegesítés viszont végleges. Sosem változik, szóidőzítéseket hordoz, a véglegesítések hiányok nélkül számozottak, így az olvasó észreveszi, ha kihagyott egyet.
A fejlesztőknek ez az egyetlen szabály, amelyet a valós idejű API megkövetel: jelenítsd meg az összes véglegesített szegmenst, utána a legutóbbi piszkozatot, és töröld a piszkozatot, amikor véglegesítés érkezik. Ha a piszkozatokat fűzöd hozzá ahelyett, hogy cserélnéd, duplikált, villódzó szöveg lesz; a véglegesítés egyszerűen felemészti a farkat. A WebSocket-oktatóanyag épp ezt a működést építi be egy olvasóba.
A hosztnak a mozgó szöveg a kisebb késleltetés ára. A szavak a kifejezés befejezése előtt megjelenítve teszik élővé az átiratot. A fordításnak viszont ez a trükk nem engedhető meg, mert egy szó a félmondatból is kitalálható, de egy fordítás nem.
A szórend miatt a fordítás nem tud lépést tartani a piszkozattal. A német igét a tagmondat végére teheti, a japán pedig az igét a mondat végére írja. Bármely fordítónak szüksége van az egész tagmondatra ahhoz, hogy hűen adja vissza. Szóról szóra fordítva töredékeket kap a hallgató, amelyeket a tagmondat zárásakor kell majd értelmezni. A német tolmácsok már jóval azelőtt az igére vártak, hogy a szoftverek megpróbálkoztak volna vele.
A VocalStack ezért mondatokat fordít, nem szegmenseket. A mondatok alapértelmezés szerint be vannak kapcsolva; ilyenkor a szerver a véglegesítésekből mondatot állít össze, és egészét lefordítja. Amíg a mondat nyitva van, fordítása ideiglenes; amint lezárul, a fordítás véglegessé válik. Az olvasó mondatonként egy bejegyzést tart, és frissítésekkor cseréli.
A beszéd még tovább vár. Csak a lezárt mondat hangzik el, mert egy még változó mondatot minden módosításnál újra kellene szintetizálni. A hosszú mondatot darabokban szólaltatják meg, így az első rész lejátszható, miközben a többi készül.
Ha a mondatok ki vannak kapcsolva, minden véglegesítés saját fordítási keretet kap. Ez az út semmire nem vár, de az egész mondatok sokkal olvashatóbbak.
Minden várakozás attól a pillanattól mérődik, amikor a hang eljut a VocalStackhez. Sok közvetítésnél a hang már akkor késett, amikor megérkezett.
Ha a forrás mikrofon helyett adatfolyam, a hang már az átírás előtt késik. Az adatfolyam élő szélénél, vagyis a legfrissebb pillanattól lemaradva érkezik.
Egy sima HTTP-hangfolyam, amilyet a legtöbb internetes rádióadó publikál, jellemzően egy-három másodperccel késik. A szerver puffert tart: néhány másodperc friss hangot, amelyet egyszerre küld el, hogy az új hallgató lejátszója zökkenőmentesen indulhasson. Minden hallgató, a VocalStacket is beleértve, ennyivel visszább csatlakozik. A HLS rosszabb: a lejátszási listák a kliensnek három szegmenssel a live él mögül indulnak, ami a szegmenshossztól függően gyakorlatban több másodperctől fél percig terjedhet. A szokásos DASH nagyjából a HLS tartományába esik; csak az alacsony késleltetésű változata marad jóval alatta. Egy adó „élő” streamje olyan értelemben lehet élő, ahogy egy levél is lehet „friss”.
Ezek a számok közelítőek, és a streamhez tartoznak, nem az átíráshoz: a VocalStack oldalán semmilyen beállítás nem nyerheti vissza őket. Ha ezek a másodpercek számítanak egy eseménynél, mikrofonról vagy enkóderről táplálj hangot a szakaszba, ne nyilvános streamről. A stream késleltetése azelőtt rögzül, hogy a VocalStack egyetlen szót is hallana; a késleltetési mód az, amit valójában mozgathatsz.
A késleltetési mód egyet tesz: beállítja a késleltetés és a pontosság egyensúlyát. A beállítás élő átírás létrehozásakor az Advanced alatt található, futás közben pedig a Speed fülön. Ott a chip AUTO, SPEED vagy ACCURACY feliratot mutat (a Fast a SPEED néven jelenik meg). API-n a session.update módosítja futás közben.
A kompromisszum a nevekből adódik. A Fast hamarabb juttatja ki a szöveget, de többet módosít rajta; az Accuracy kicsit tovább tart, és kevesebbet módosít. Egy ülő közönség, amely a lefordított feliratokat olvassa, ritkán veszi észre a plusz egy másodpercet, de észreveszi a folyton változó szavakat. Az Accuracy ezért gyakran a barátságosabb beállítás, feltéve, hogy a késleltetési grafikon lapos marad. Az Auto nyíltan jelzi, mit csinál: a sort, amelyet a rés bezárása érdekében gyorsított, FAST MODE jelvény jelöli a házigazda átiratában, egy megjegyzéssel, hogy ott a pontosság alacsonyabb lehet.
Bármelyik módot is választod, az átírásnak készen kell állnia az első szóra, és ennek előkészítése az egyetlen késleltetés, amelyet a lánc csak egyszer fizet meg.
Egyes csomagoknál az élő átírás indulása néhány másodpercet vesz igénybe. Hogy mennyit, az a csomagtól függ: az árak oldalán lévő Start-up speed sor a pay as you go csomagnál legfeljebb 15 másodperces hidegindítástól az Enterprise csomag mindig meleg állapotáig terjed.
API-n a várakozás session.loading keretekként jelenik meg, amíg a munkamenet indul, majd session.ready következik; a kliens csak ezután küld hangot. Az a hallgató, aki addig megnyitja a linket, ezt látja: „Élő. Az első sor pillanatokon belül megjelenik.” Amint az átírás fut, ez a késleltetés lezárult, és csak az marad kérdés, hogy a hátralévő késleltetésből mennyit viszel magaddal.
Futás közben a házigazda Speed fülén látszik, mindez összesen mennyi: a beszélő és a szöveg aktuális távolsága, mellette a módjelzővel, valamint a rögzítés teljes hosszán futó grafikon az átlaggal és a csúcsértékkel. Magában az átiratban az a sor, amely késve ért a hallgatókhoz, jelvényt visel: megadja, hány másodperc telt el a kimondása és az érkezése között.
Ha a grafikon alacsonyan és laposan fut, a mód illik a hanghoz. Ha emelkedik, a feldolgozó lemarad. Accuracy módban ez lehet az a pillanat, amikor Autóra váltasz, amely a pontosság egy részéért gyorsaságot ad, amíg a rés be nem záródik.
A fejlesztők ehelyett egyetlen számot kapnak. Amikor a valós idejű munkamenet véget ér, a session.done a stats.realtimeFactor értéket hordozza: a leírt hang hosszát osztva az átírásra fordított idővel. Egy konvenció-figyelmeztetés: a beszédfelismerési szakirodalomban a real-time factor általában fordítva értendő, vagyis a feldolgozási idő osztva a hanghosszal, ahol a kisebb a jobb. A VocalStack fordítva adja meg, így itt a nagyobb a jobb: egy élő munkamenet 1 körül van, és 1 alatti érték azt jelenti, hogy a hang gyorsabban érkezett, mint ahogy a feldolgozó le tudta írni.
Egyik másodperc sem rejtélyes. Némelyik a streamhez tartozik, némelyik ahhoz a szóhoz, amely a következő szóra vár, némelyik ahhoz a mondathoz, amelyre a fordításnak szüksége van, a többi pedig a választott késleltetési módhoz. Az API-referencia részletezi a keretenkénti részleteket, a főoldal demója pedig végigmutatja a láncot működés közben.
