Karamihan ng delay sa live na pagsasalin ay paghihintay: sa stream, sa susunod na salita, sa pangungusap. Ang isang bahaging ikaw ang may kontrol ay ang latency mode: mas kaunting delay, o mas kaunting revision.
Ang listener na nagbabasa ng live na pagsasalin ay nakikita ang bawat linya ilang segundo matapos sabihin ng nagsasalita. Ang agwat na iyon ay hindi iisang delay kundi marami, na nagsasama-sama sa isang chain, at karamihan sa mga ito ay anyo ng paghihintay. Kapag alam mo kung aling paghihintay ang alin, nagiging madali ang pagpili ng latency mode, at malalaman ng developer na gumagawa ng reader kung ano ang ire-render, at kailan.
Bago ang mga numero, may magandang panukat muna: karaniwang nasa dalawa hanggang apat na segundo sa likod ng nagsasalita ang isang tao na simultaneous interpreter. Tinatawag ng mga interpreter ang agwat na iyon na ear-voice span, at hinaharap nila ang mga wikang nasa huli ang pandiwa hindi sa pamamagitan ng paghihintay sa pandiwa, kundi sa pag-asam dito, o sa pagputol ng pangungusap sa mga piraso na kayang tumayo nang mag-isa. Ang isa o dalawang segundong delay ay hindi depekto ng software; halos iyon din ang ginagawa ng isang mahusay na tao.
Bawat live na transcription sa VocalStack ay dumadaan sa parehong mga yugto, sa parehong pagkakasunod, at bawat isa ay naghihintay sa nauna rito.
Halos kasabay ng pagsasalita ang pag-abot ng teksto sa orihinal na wika sa reader. Sumusunod ang pagsasalin pagkalipas ng isa o dalawang segundo, at ang binibigkas na pangungusap ay dumarating pagkatapos ng pagsasalin nito, kaya laging huli dumating ang voice clip. Ang unang nakikitang epekto ng chain, gayunpaman, ay dumarating nang matagal bago ang anumang boses: gumagalaw mismo ang teksto.
Ang unang napapansin ng mga tao sa live na transcript ay ang paggalaw ng pinakabagong mga salita. Lumilitaw ang isang parirala, nagbabago, at saka naaayos. Iyon ang yugto ng draft na gumagana, at umiiral ito dahil sa dahilan na naaangkop sa bawat speech recogniser.
Inaayos ng recogniser ang isang salita sa pamamagitan ng pagtingin sa kung ano ang kasunod nito. Magkatunog ang "I scream" at "ice cream" hanggang dumating ang susunod na salita; ang nakasabit na "s" ay maaaring kabilang sa salitang ito o sa susunod. Hangga't walang audio sa kanan ng isang salita, hula lamang ang baybay nito, kaya ang pinakabagong mga salita sa anumang live transcript ay laging ang pinaka-hindi tiyak. Ang draft ay simpleng hulang iyon na ipinapakita nang maaga sa halip na itago.
Ganap na pinapalitan ng bawat draft ang live na dulo: ang mga salitang narinig mula sa huling commit, na patuloy pang nagbabago. Final ang commit. Hindi ito nagbabago kailanman, may dalang word-level timings, at walang puwang ang pagnunumero ng mga commit para malaman ng reader kung may nalampasan siya.
Para sa developer, ito ang iisang tuntunin na mahigpit na hinihingi ng realtime API: i-render ang bawat committed segment, pagkatapos ang pinakabagong draft sa likod nila, at burahin ang draft kapag may dumating na commit. Ang pag-a-append ng mga draft sa halip na pagpapalit sa mga ito ay nagreresulta sa paulit-ulit at kumikislap na teksto; inaalis lang ng commit ang dulo. Ang WebSocket tutorial ay gumagawa ng reader batay mismo dito.
Para sa host, ang paggalaw ng teksto ang kapalit ng mababang delay. Ang pagpapakita ng mga salita bago pa matapos ang parirala ang nagpaparamdam na live ang transcript. Ang pagsasalin, gayunpaman, ay hindi kayang gamitin ang trick na iyon, dahil ang isang salita ay maaaring hulaan mula sa kalahati ng parirala, pero hindi ang isang pagsasalin.
Ang ayos ng mga salita ang dahilan kung bakit hindi makasabay ang pagsasalin sa draft. Maaaring nasa dulo ng sugnay ang pandiwa sa Aleman, at inilalagay ng Hapon ang pandiwa sa huli. Kailangan ng sinumang tagasalin ang buong sugnay bago ito tapat na maisalin. Ang pagsasalin nang salita-por-salita ay nagbibigay sa listener ng mga piraso na kailangang bawiin ang pagkaunawa kapag nagsara na ang sugnay. Matagal nang naghihintay ang mga interpreter sa pandiwang Aleman, bago pa sinubukan ito ng software.
Kaya isinasalin ng VocalStack ang mga pangungusap, hindi ang mga segment. Naka-on bilang default ang mga pangungusap, at kapag naka-on ang mga ito, binubuo ng server ang mga commit bilang isang pangungusap at isinasalin ang buo nito. Habang bukas pa ang pangungusap, pansamantala ang pagsasalin nito; kapag nagsara na ito, final na ang pagsasalin. Isang entry bawat pangungusap ang hawak ng reader, at pinapalitan ito habang dumarating ang mga update.
Mas matagal pa ang paghihintay ng boses. Tanging nakasarang pangungusap lamang ang binibigkas, dahil ang pangungusap na patuloy pang nagbabago ay muling isi-synthesise sa bawat revision. Ang mahabang pangungusap ay binibigkas nang pira-piraso, kaya maaaring tumugtog agad ang una habang ginagawa pa ang iba.
Kapag naka-off ang mga pangungusap, bawat commit ay may sariling translation frame. Walang hinihintay ang daang ito, pero mas maganda ang basa ng buong pangungusap.
Ang lahat ng paghihintay na ito ay sinusukat mula sa sandaling makarating ang audio sa VocalStack. Para sa maraming broadcast, huli na ang audio pagdating nito doon.
Kapag stream ang pinagmulan at hindi microphone, nasa likod na ang audio bago pa ma-transcribe ang anuman. Nahuhuli ito sa live edge, ang pinakabagong sandaling nailathala ng stream.
Ang karaniwang HTTP audio stream, ang uri na karamihan ng internet radio station ang naglalathala, kadalasang isa o tatlong segundo ang likod. Nagtatago ang server ng burst buffer: ilang segundo ng kamakailang audio, na ipinapadala nang sabay-sabay para makapagsimula ang player ng bagong listener nang hindi natitigil. Bawat listener, kasama ang VocalStack, ay sumasali nang ganoon kalayo sa likod. Mas masama ang HLS: nagsisimula ang mga playlist nito ng client na tatlong segment sa likod ng live edge, na sa praktika ay ibig sabihin ay ilang segundo hanggang kalahating minuto depende sa haba ng segment. Karaniwang nasa parehong saklaw ng HLS ang karaniwang DASH; tanging ang low-latency variant nito ang nakakababa nang malayo rito. Ang "live" na stream ng isang istasyon ay maaaring maging live sa paraang kung paanong ang isang liham ay "napapanahon" pa rin, kahit matagal nang naisulat.
Tinatayang lamang ang mga bilang na ito, at sa stream sila kabilang, hindi sa transcription: walang setting sa panig ng VocalStack ang makakabawi sa mga ito. Kung mahalaga ang mga segundong iyon para sa isang event, ipasok ang audio ng stage mula sa microphone o encoder sa halip na public stream. Naayos na ang stream delay bago pa makarinig ng salita ang VocalStack; ang latency mode ang tunay mong mababago.
Isa lang ang ginagawa ng latency mode: itinatakda nito ang balanse sa pagitan ng delay at katumpakan. Nasa ilalim ng Advanced ang setting kapag ginawa ang live na transcription, at sa Speed tab habang tumatakbo ito. Doon, ang chip ay nagbabasa ng AUTO, SPEED o ACCURACY (lumalabas bilang SPEED ang Fast). Sa API, binabago ito ng session.update habang umaandar ang stream.
Ang kapalit ay ang ipinahihiwatig ng mga pangalan. Mas mabilis lumabas ang teksto sa Fast pero mas maraming bahagi nito ang binabago; mas matagal nang kaunti ang Accuracy at mas kaunti ang binabago. Bihirang mapansin ng audience na nakaupo at bumabasa ng isinaling subtitles ang dagdag na isang segundo, pero napapansin nila ang mga salitang patuloy na nagbabago. Kaya madalas na mas magiliw na setting ang Accuracy, basta nananatiling patag ang delay chart. Ipinapakita ng Auto ang sarili nitong ginagawa: ang linyang pinabilis nito para punan ang agwat ay may badge na FAST MODE sa transcript ng host, kasama ang paalalang maaaring mas mababa ang katumpakan doon.
Anuman ang mode, dapat handa na ang transcription bago ang unang salita, at ang paghahanda rito ang iisang delay na binabayaran ng chain nang minsan lamang.
Sa ilang plan, ilang segundo bago magsimula ang live na transcription. Nakadepende sa plan kung gaano katagal: ang hilera ng Start-up speed sa pricing page ay mula sa cold start na hanggang 15 segundo sa Pay as you go hanggang sa laging warm sa Enterprise.
Sa API, lumilitaw ang paghihintay bilang mga session.loading frame habang nagsisimula ang session, pagkatapos ay session.ready; saka lamang nagpapadala ng audio ang client. Ang listener na bubuksan ang link sa pagitan ng panahong ito ay makikitang "Live. The first line appears in a moment." Kapag tumatakbo na ang transcription, nasa likod mo na ang delay na ito, at ang natitirang tanong na lang ay kung gaano karami sa natitirang delay ang dala mo pa.
Habang tumatakbo ang live na transcription, ipinapakita ng Speed tab ng host kung ano ang kabuuan ng lahat ng ito: ang kasalukuyang agwat sa pagitan ng nagsasalita at ng teksto, kasama ang mode chip sa tabi nito, at chart ng agwat na iyon sa buong recording na may average at peak nito. Sa mismong transcript, ang linyang huling nakarating sa mga listener ay may badge na nagpapakita ng bilang ng segundo sa pagitan ng pagkakasabi nito at ng pagdating nito.
Ang chart na nananatiling mababa at patag ay nangangahulugang angkop ang mode sa audio. Ang chart na tumataas ay nangangahulugang nahuhuli ang pipeline. Sa Accuracy, maaaring ito na ang sandaling lumipat sa Auto, na nagpapalit ng kaunting katumpakan para sa bilis hanggang sa magsara ang agwat.
Sa halip, isang numero lamang ang nakukuha ng mga developer. Kapag natapos ang realtime session, dala ng session.done ang stats.realtimeFactor, na ang na-transcribe na audio na hinati sa oras na ginugol sa pag-transcribe nito. Isang babala tungkol sa convention: sa literatura ng speech recognition, karaniwang kabaligtaran ang ibig sabihin ng real-time factor, ang oras ng pagproseso na hinati sa haba ng audio, kung saan mas mabuti ang mas mababa. Iba ang paraan ng VocalStack sa pag-uulat, kaya dito, mas mabuti ang mas mataas: nasa paligid ng 1 ang live na session, at ang mas mababa sa 1 ay nangangahulugang mas mabilis dumating ang audio kaysa sa kayang i-transcribe ng pipeline.
Walang misteryo sa alinman sa mga segundong ito. Ang iba ay kabilang sa stream, ang iba ay sa isang salitang naghihintay sa salitang kasunod nito, ang iba ay sa pangungusap na kailangan ng pagsasalin, at ang natitira ay sa latency mode na pinili mo. Nasa API reference ang detalye frame-by-frame, at ipinapakita ng demo sa home page ang takbo ng chain.
