Cea mai mare parte a întârzierii din traducerea live este așteptare: după flux, după următorul cuvânt, după propoziție. Singura parte pe care o controlezi este modul de latență: mai puțină întârziere sau mai puține revizuiri.
Un ascultător care citește o traducere live vede fiecare rând la câteva secunde după ce vorbitorul l-a rostit. Această întârziere nu este una singură, ci mai multe, adunate pe un lanț, iar majoritatea sunt o formă de așteptare. Dacă știi care așteptare este care, alegerea modului de latență devine ușoară și îi spune unui dezvoltator care construiește un cititor ce să afișeze și când.
Un reper util înainte de cifre: un interpret simultan uman vorbește de obicei cu două până la patru secunde în urma vorbitorului. Interpreții numesc acest decalaj ear-voice span și se descurcă cu limbile cu verbul la final nu așteptând verbul, ci anticipându-l sau tăind propoziția în bucăți care pot sta singure. O secundă sau două de întârziere nu este un defect al software-ului; este cam ce face un interpret uman foarte bun.
Fiecare transcriere live de pe VocalStack trece prin aceleași etape, în aceeași ordine, iar fiecare așteaptă etapa dinaintea ei.
Textul din limba originală ajunge la cititor aproape cum este rostit. Traducerea urmează cu o secundă sau două mai târziu, iar propoziția rostită vine după traducerea ei, de aceea un clip vocal ajunge mereu ultimul. Primul efect vizibil al lanțului, totuși, apare cu mult înainte de orice voce: textul în sine se mișcă.
Primul lucru pe care îl observă oamenii într-o transcriere live este că cele mai noi cuvinte se mișcă. O expresie apare, se schimbă și apoi se stabilizează. Asta este etapa de ciornă în acțiune, iar ea există dintr-un motiv care se aplică la orice sistem de recunoaștere a vorbirii.
Un sistem de recunoaștere a vorbirii stabilește un cuvânt uitându-se la ce urmează după el. „I scream” și „ice cream” sună la fel până când vine următorul cuvânt; un „s” final poate aparține acestui cuvânt sau celui următor. Până când există audio în dreapta unui cuvânt, scrierea lui este o presupunere, așa că cuvintele cele mai noi dintr-o transcriere live sunt mereu cele mai nesigure. O ciornă este pur și simplu această presupunere, arătată devreme în loc să fie ascunsă.
Fiecare ciornă înlocuiește complet coada live: cuvintele auzite de la ultimul commit, care încă se schimbă. Un commit este final. Nu se mai schimbă, poartă marcaje de timp la nivel de cuvânt, iar commit-urile sunt numerotate fără goluri, astfel încât un cititor să poată observa dacă i-a scăpat unul.
Pentru un dezvoltator, aceasta este singura regulă pe care API-ul realtime o impune: afișează fiecare segment comis, apoi ciorna cea mai recentă după ele, și golește ciorna când sosește un commit. Adăugarea ciornelor una după alta, în loc de înlocuirea lor, produce text dublat și care pâlpâie; commit-ul pur și simplu consumă coada. Tutorialul WebSocket construiește un cititor exact pe această idee.
Pentru o gazdă, mutarea textului este prețul întârzierii mici. Arătarea cuvintelor înainte ca fraza să fie terminată face transcrierea să pară vie. Traducerea, în schimb, nu își permite acest truc, pentru că un cuvânt poate fi ghicit dintr-o jumătate de frază, dar o traducere nu.
Ordinea cuvintelor este motivul pentru care traducerea nu poate ține pasul cu ciorna. Un verb german poate sta la sfârșitul clauzei, iar japoneza pune verbul la final. Orice traducător are nevoie de întreaga clauză înainte să o redea fidel. Traducerea cuvânt cu cuvânt îi dă ascultătorului fragmente care trebuie să rămână nedescifrate până se închide clauza. Germanii îi fac pe interpreți să aștepte verbul de mult timp, înainte ca software-ul să încerce asta.
VocalStack traduce, deci, propoziții, nu segmente. Propozițiile sunt activate implicit, iar cu ele pornite, serverul asamblează commit-urile într-o propoziție și traduce propoziția întreagă. Cât timp propoziția este deschisă, traducerea ei este provizorie; odată închisă, traducerea devine finală. Un cititor ține o singură intrare pentru fiecare propoziție și o înlocuiește pe măsură ce sosesc actualizările.
Vorbirea așteaptă și mai mult. Doar o propoziție închisă este rostită, pentru că o propoziție care încă se schimbă ar fi resintetizată la fiecare revizuire. O propoziție lungă este rostită pe bucăți, astfel încât prima poate fi redată cât timp restul sunt pregătite.
Cu propozițiile dezactivate, fiecare commit primește propriul cadru de traducere. Calea aceasta nu așteaptă nimic, dar propozițiile întregi se citesc mult mai bine.
Toate aceste așteptări sunt măsurate din momentul în care audio-ul ajunge la VocalStack. Pentru multe transmisiuni, audio-ul era deja întârziat când a ajuns acolo.
Când sursa este un flux și nu un microfon, audio-ul este deja în urmă înainte ca vreun cuvânt să fie transcris. Rămâne în urma marginii live, adică a celui mai recent moment pe care fluxul l-a publicat.
Un flux HTTP audio simplu, de tipul celor pe care le publică majoritatea posturilor de radio pe internet, rămâne de obicei în urmă cu una până la trei secunde. Serverul păstrează un buffer de rafală: câteva secunde de audio recent, trimise deodată, ca playerul unui ascultător nou să poată porni fără poticniri. Fiecare ascultător, inclusiv VocalStack, se alătură de atât de departe. HLS este mai rău: playlist-urile sale pornesc un client cu trei segmente în urma marginii live, ceea ce înseamnă în practică câteva secunde până la o jumătate de minut, în funcție de lungimea segmentelor. DASH standard se încadrează de obicei în același interval cu HLS; doar varianta sa cu latență mică coboară mult sub el. Fluxul „live” al unui post poate fi live în același fel în care o scrisoare poate fi „actuală”.
Aceste cifre sunt aproximative și țin de flux, nu de transcriere: nicio setare de pe partea VocalStack nu le poate recupera. Dacă acele secunde contează pentru un eveniment, alimentează etapa cu audio dintr-un microfon sau dintr-un encoder, nu dintr-un flux public. Întârzierea fluxului este fixată înainte ca VocalStack să audă un cuvânt; modul de latență este ceea ce poți chiar muta.
Modul de latență face un singur lucru: stabilește echilibrul dintre întârziere și acuratețe. Setarea se află sub Advanced când este creată o transcriere live, iar în tab-ul Speed cât timp rulează. Acolo, indicatorul afișează AUTO, SPEED sau ACCURACY (Fast apare ca SPEED). Prin API, session.update îl schimbă în mijlocul fluxului.
Compromisul este cel sugerat de nume. Fast trimite textul mai devreme, dar îl revizuiește mai mult; Accuracy așteaptă puțin mai mult și revizuiește mai puțin. Un public așezat, care citește subtitrări traduse, observă rareori o secundă în plus, dar observă cuvintele care tot se schimbă. Accuracy este, așadar, deseori setarea mai binevoitoare, atâta timp cât graficul întârzierii rămâne plat. Auto își arată cartea: o linie pe care a accelerat-o ca să închidă un decalaj poartă o insignă FAST MODE în transcrierea gazdei, cu o notă că acuratețea poate fi mai mică acolo.
Indiferent de mod, transcrierea trebuie să fie pregătită înainte de primul cuvânt, iar pregătirea ei este singura întârziere pe care lanțul o plătește o singură dată.
Pe unele planuri, o transcriere live are nevoie de câteva secunde ca să pornească. Cât durează depinde de plan: rândul Start-up speed de pe pagina de prețuri merge de la o pornire la rece de până la 15 secunde pe Pay as you go până la always warm pe Enterprise.
Prin API, așteptarea apare ca cadre session.loading cât timp sesiunea pornește, apoi un session.ready; clientul trimite audio abia după aceea. Un ascultător care deschide linkul între timp vede "Live. The first line appears in a moment." Odată ce transcrierea rulează, această întârziere este în urma ta, iar singura întrebare rămasă este cât din întârzierea rămasă porți cu tine.
Cât timp rulează o transcriere live, tab-ul Speed al gazdei arată cât adună toate acestea: decalajul actual dintre vorbitor și text, cu indicatorul modului alături, și un grafic al acestui decalaj de-a lungul înregistrării, cu media și vârful. În transcrierea propriu-zisă, o linie care a ajuns târziu la ascultători poartă o insignă cu numărul de secunde dintre momentul rostirii și cel al sosirii.
Un grafic care rămâne jos și plat înseamnă că modul se potrivește audio-ului. Un grafic care urcă înseamnă că procesarea rămâne în urmă. Pe Accuracy, poate fi momentul să treci pe Auto, care schimbă puțină acuratețe pentru viteză, până când decalajul se închide.
Dezvoltatorii primesc în schimb o singură cifră. Când se încheie o sesiune realtime, session.done conține stats.realtimeFactor, adică audio-ul transcris împărțit la timpul cheltuit pentru transcrierea lui. O avertizare de convenție: în literatura despre recunoașterea vorbirii, real-time factor înseamnă de obicei inversul, adică timpul de procesare împărțit la timpul audio, unde mai mic este mai bine. VocalStack îl raportează invers, deci aici mai mare este mai bine: o sesiune live stă aproape de 1, iar sub 1 înseamnă că audio-ul a sosit mai repede decât îl putea transcrie procesarea.
Niciuna dintre aceste secunde nu este misterioasă. Unele aparțin fluxului, altele unui cuvânt care așteaptă cuvântul următor, altele propoziției de care are nevoie o traducere, iar restul modului de latență pe care l-ai ales. Referința API are detaliul cadru cu cadru, iar demonstrația de pe pagina principală arată lanțul în funcțiune.
