Het grootste deel van de vertraging bij live vertaling is wachten: op de stream, op het volgende woord, op de zin. Het enige deel dat je zelf in de hand hebt, is de latentiemodus: minder vertraging, of minder revisies.
Een luisteraar die een live vertaling leest, ziet elke regel een paar seconden nadat de spreker hem heeft uitgesproken. Die kloof is niet één vertraging maar meerdere, opgeteld langs een keten, en de meeste daarvan zijn een vorm van wachten. Wie weet welk wachten bij welke vertraging hoort, maakt de keuze van de latentiemodus eenvoudig, en weet een ontwikkelaar die een lezer bouwt wat die moet weergeven, en wanneer.
Een nuttige maatstaf vooraf: een menselijke simultaanvertaler spreekt meestal twee tot vier seconden achter de spreker aan. Tolken noemen die kloof de ear-voice span, en bij werkwoordfinale talen lossen ze het niet op door op het werkwoord te wachten, maar door te anticiperen of door de zin op te delen in stukken die op zichzelf kunnen staan. Een seconde of twee vertraging is geen gebrek van software; het is ongeveer wat een zeer goede mens ook doet.
Elke live transcriptie op VocalStack doorloopt dezelfde fasen, in dezelfde volgorde, en elke fase wacht op de fase ervoor.
De tekst in de brontaal bereikt een lezer bijna terwijl hij wordt uitgesproken. De vertaling volgt een seconde of twee later, en de gesproken zin komt na zijn vertaling, waarom een spraakfragment altijd als laatste aankomt. Het eerste zichtbare effect van de keten komt echter lang vóór elke stem: de tekst zelf beweegt.
Het eerste wat mensen opmerken in een live transcript is dat de nieuwste woorden bewegen. Een zin verschijnt, verandert en valt op zijn plaats. Dat is de conceptfase aan het werk, en die bestaat om een reden die voor elke spraakherkenner geldt.
Een spraakherkenner bepaalt de spelling van een woord aan de hand van wat erna komt. "I scream" en "ice cream" klinken hetzelfde tot het volgende woord komt; een slot-s kan bij dit woord horen of bij het volgende. Zolang er geen audio rechts van een woord is, is de spelling een gok. De nieuwste woorden in elk live transcript zijn dus altijd de meest onzekere. Een concept is simpelweg die gok, vroeg getoond in plaats van verborgen.
Elk concept vervangt volledig de live staart: de woorden die sinds de laatste vastlegging zijn gehoord en nog veranderen. Een vastlegging is definitief. Ze verandert nooit, ze draagt woordniveau-tijden, en vastleggingen zijn doorlopend genummerd zodat een lezer kan zien of er een is gemist.
Voor een ontwikkelaar is dit de ene regel die de realtime-API consequent eist: render elk vastgelegd segment, daarna het laatste concept erachter, en wis het concept zodra een vastlegging binnenkomt. Concepten toevoegen in plaats van vervangen geeft gedupliceerde, flikkerende tekst; de vastlegging verbruikt simpelweg de staart. De WebSocket-tutorial bouwt een lezer precies rond dit principe.
Voor een host is tekst die verschuift de prijs van lage vertraging. Woorden tonen voordat de zin af is, is wat het transcript levend laat aanvoelen. De vertaling kan die truc echter niet betalen, want een woord kan uit een halve zin worden geraden, maar een vertaling niet.
Woordvolgorde is de reden dat vertaling niet gelijk kan blijven met het concept. Een Duits werkwoord kan aan het eind van zijn bijzin staan, en in het Japans staat het werkwoord altijd laatst. Elke vertaler heeft de hele bijzin nodig om die getrouw weer te geven. Woord voor woord vertalen levert een luisteraar fragmenten op die nog niet te lezen zijn als de zin afsluit. Duitse tolken moesten al lang voordat software het probeerde op het werkwoord wachten.
VocalStack vertaalt daarom zinnen, niet segmenten. Zinnen staan standaard aan, en met zinnen aan zet de server de vastleggingen om in een zin en vertaalt die in zijn geheel. Zolang de zin open is, is de vertaling voorlopig; zodra hij sluit, is de vertaling definitief. Een lezer houdt één item per zin aan en vervangt dat bij elke update.
Spraak wacht nog langer. Alleen een gesloten zin wordt uitgesproken, omdat een zin die nog verandert bij elke revisie opnieuw gesynthetiseerd zou moeten worden. Een lange zin wordt in stukken uitgesproken, zodat het eerste stuk kan worden afgespeeld terwijl de rest nog wordt gemaakt.
Met zinnen uit krijgt elke vastlegging in plaats daarvan een eigen vertaalframe. Dat pad wacht op niets, maar hele zinnen lezen veel beter.
Alle wachttijden worden gemeten vanaf het moment dat de audio VocalStack bereikt. Bij veel uitzendingen was de audio al te laat toen hij binnenkwam.
Wanneer de bron een stream is en geen microfoon, loopt de audio al achter voordat er iets is getranscribeerd. Hij loopt achter op de live-rand, het nieuwste moment dat de stream heeft gepubliceerd.
Een gewone HTTP-audiostream, het soort dat de meeste internetradiozenders uitzenden, loopt meestal één tot drie seconden achter. De server houdt een burst-buffer aan: een paar seconden recente audio, in één keer verstuurd zodat de speler van een nieuwe luisteraar kan starten zonder te haperen. Elke luisteraar, VocalStack inbegrepen, komt zo ver terug binnen. HLS is erger: de afspeellijsten starten een client drie segmenten achter de live-rand, wat in de praktijk enkele seconden tot een halve minuut betekent, afhankelijk van de segmentlengte. Standaard DASH zit meestal in dezelfde orde als HLS; alleen de low-latency-variant komt er ruim onder. Het "live"-signaal van een zender is live zoals een brief actueel is.
Deze cijfers zijn indicatief, en ze horen bij de stream, niet bij de transcriptie: geen instelling aan de kant van VocalStack kan ze terughalen. Als die seconden voor een evenement tellen, voer de audio dan via een microfoon of een encoder aan in plaats van via een publieke stream. De streamvertraging is vastgelegd voordat VocalStack ook maar één woord hoort; de latentiemodus is wat je wél kunt verplaatsen.
De latentiemodus doet één ding: hij bepaalt de balans tussen vertraging en nauwkeurigheid. De instelling staat onder Advanced wanneer een live transcriptie wordt aangemaakt, en op het tabblad Speed terwijl hij loopt. Daar leest de chip AUTO, SPEED of ACCURACY (Fast verschijnt als SPEED). Via de API wijzigt session.update de modus middenin de stream.
De afweging is die waar de namen op wijzen. Fast brengt tekst sneller naar buiten maar herziet er meer van; Accuracy doet er iets langer over en herziet minder. Een zittend publiek dat vertaalde ondertitels leest, merkt een extra seconde zelden op, maar merkt wel woorden die blijven veranderen. Accuracy is daarom vaak de vriendelijkere instelling, zolang de vertragingsgrafiek vlak blijft. Auto laat zien wat hij doet: een regel die hij heeft versneld om een achterstand dicht te lopen, krijgt in het transcript van de host een badge FAST MODE, met een notitie dat de nauwkeurigheid daar lager kan zijn.
In elke modus moet de transcriptie klaar zijn vóór het eerste woord, en dat klaarzetten is de enige vertraging die de keten maar één keer betaalt.
Bij sommige abonnementen duurt het een paar seconden voordat een live transcriptie start. Hoe lang dat duurt, hangt af van het abonnement: de rij Start-up speed op de prijspagina loopt van een koude start van maximaal 15 seconden bij Pay as you go tot altijd warm bij Enterprise.
Via de API verschijnt de wachttijd als session.loading-frames terwijl de sessie start, gevolgd door een session.ready; de client stuurt pas audio daarna. Een luisteraar die in de tussentijd de link opent, ziet "Live. The first line appears in a moment." Zodra de transcriptie loopt, is deze vertraging voorbij, en blijft alleen de vraag hoeveel van de resterende vertraging je meedraagt.
Terwijl een live transcriptie loopt, toont het tabblad Speed van de host wat dit alles bij elkaar optelt: de huidige kloof tussen spreker en tekst, met de modus-chip ernaast, en een grafiek van die kloof over de hele opname, met het gemiddelde en de piek. In het transcript zelf krijgt een regel die luisteraars laat bereikte een badge met het aantal seconden tussen het moment dat hij werd uitgesproken en het moment dat hij aankwam.
Een grafiek die laag en vlak blijft, betekent dat de modus bij de audio past. Een stijgende grafiek betekent dat de pipeline achterloopt. Op Accuracy kan dat het moment zijn om naar Auto over te schakelen, dat een deel van de nauwkeurigheid inruilt voor snelheid totdat de kloof dicht is.
Ontwikkelaars krijgen in plaats daarvan één getal. Wanneer een realtime-sessie eindigt, bevat session.done stats.realtimeFactor: de getranscribeerde audio gedeeld door de tijd die het kostte om die te transcriberen. Een waarschuwing over de conventie: in de spraakherkenningsliteratuur betekent realtime factor meestal het omgekeerde, verwerkingstijd gedeeld door audiotijd, waarbij lager beter is. VocalStack rapporteert hem andersom, dus hier is hoger beter: een live sessie zit rond 1, en onder 1 betekent dat de audio sneller binnenkwam dan de pipeline hem kon transcriberen.
Geen van deze seconden is mysterieus. Sommige horen bij de stream, sommige bij een woord dat op het volgende woord wacht, sommige bij de zin die een vertaling nodig heeft, en de rest bij de latentiemodus die je koos. De API-referentie bevat het detail frame voor frame, en de demo op de homepage laat de keten in werking zien.
