По-голямата част от забавянето при превода на живо е чакане: за потока, за следващата дума, за изречението. Единствената част, която контролирате, е режимът на закъснение: по-малко забавяне или по-малко корекции.
Слушател, който чете превод на живо, вижда всеки ред няколко секунди след като говорителят го е изрекъл. Това закъснение не е едно, а няколко, които се натрупват по веригата, и повечето от тях са форма на чакане. Ако знаете кое чакане къде се случва, изборът на режим на закъснение става лесен, а разработчикът, който изгражда четец, знае какво да визуализира и кога.
Преди цифрите е полезен един ориентир: човешкият синхронен преводач обикновено изостава от говорителя с две до четири секунди. Преводачите наричат този интервал ear-voice span („интервал ухо–глас“) и се справят с езици, в които глаголът стои в края, не като чакат глагола, а като го предвиждат или разделят изречението на части, които могат да стоят самостоятелно. Секунда-две закъснение не е дефект на софтуера; това е приблизително това, което прави много добър човек.
Всяка транскрипция на живо във VocalStack минава през едни и същи етапи, в същия ред, и всеки чака предходния.
Оригиналният текст стига до четеца почти както е изречен. Преводът идва една-две секунди по-късно, а изреченият на глас идва след превода, затова клипът с глас винаги пристига последен. Първият видим ефект на веригата обаче идва много преди гласа: самият текст се движи.
Първото, което хората забелязват в транскрипт на живо, е, че най-новите думи се местят. Една фраза се появява, променя се и се уталожва. Това е етапът на черновата в действие и съществува по причина, която важи за всеки разпознавател на реч.
Разпознавателят уталожва дума, като гледа какво следва след нея. „I scream“ и „ice cream“ звучат еднакво, докато не пристигне следващата дума; крайното „s“ може да принадлежи на тази дума или на следващата. Докато няма звук вдясно от дума, правописът ѝ е предположение, затова най-новите думи във всеки транскрипт на живо са винаги най-несигурните. Черновата е просто това предположение, показано по-рано, вместо да бъде скрито.
Всяка чернова заменя напълно живия край: думите, чути след последното потвърждение, които още се променят. Потвърждението е окончателно. Никога не се променя, носи времена на ниво дума, а редовете са номерирани без пропуски, така че четецът да види, ако е пропуснал някой.
За разработчика това е единственото правило, което realtime API-то изисква: визуализирайте всеки потвърден сегмент, след него последната чернова, и изчистете черновата, когато пристигне потвърждение. Добавянето на чернови една след друга дава дублиран, мигащ текст; потвърждението просто поглъща края. Урокът за WebSocket изгражда четец точно около това.
За домакина движещият се текст е цената на ниското забавяне. Показването на думи, преди фразата да е завършила, е това, което прави транскрипта да изглежда жив. Преводът обаче не може да си позволи този трик, защото една дума може да се отгатне от половин фраза, но превод – не.
Редът на думите е причината преводът да не може да следва черновата. Немският глагол може да стои в края на клаузата, а японският поставя глагола най-накрая. Всеки преводач има нужда от цялата клауза, за да я предаде вярно. Превеждането дума по дума предава на слушателя фрагменти, които трябва да бъдат осмислени, когато клаузата приключи. Немският отдавна кара преводачите да чакат глагола, много преди софтуерът да е опитал.
VocalStack затова превежда изречения, не сегменти. Изреченията са включени по подразбиране, и при тях сървърът събира потвърдените редове в изречение и превежда цялото. Докато изречението е отворено, преводът му е предварителен; след като се затвори, преводът е окончателен. Четецът държи по един запис на изречение и го заменя, когато пристигнат актуализации.
Говоренето чака още повече. Озвучава се само затворено изречение, защото изречение, което още се променя, би се синтезирало наново при всяка промяна. Дълго изречение се озвучава на части, така че първата част може да се пусне, докато останалите се създават.
При изключени изречения всеки потвърден ред получава собствен превод. Този път не чака нищо, но цели изречения се четат много по-добре.
Всички тези чакания се измерват от момента, в който звукът достигне до VocalStack. При много излъчвания звукът вече е закъснял, когато пристигне.
Когато източникът е поток, а не микрофон, звукът е зад времето още преди да бъде транскрибиран. Той изостава от живата точка – най-новия момент, който потокът е публикувал.
Обикновеният HTTP аудио поток, какъвто публикуват повечето интернет радиостанции, обикновено изостава с една до три секунди. Сървърът държи буфер при пускане: няколко секунди скорошен звук, изпратен наведнъж, за да може плейърът на новия слушател да стартира без спиране. Всеки слушател, включително VocalStack, се включва толкова назад. HLS е по-зле: плейлистите започват клиента три сегмента зад живата точка, което на практика означава няколко секунди до половин минута в зависимост от дължината на сегмента. Стандартният DASH обикновено е в същия диапазон като HLS; само нискоабатовият му вариант слиза значително под него. „Живият“ поток на една станция може да е жив по същия начин, по който едно писмо е „актуално“.
Тези стойности са приблизителни и принадлежат на потока, а не на транскрипцията: никоя настройка от страна на VocalStack не може да ги върне назад. Ако тези секунди имат значение за събитие, подайте звука на етапа от микрофон или енкодер, а не от публичен поток. Забавянето на потока е фиксирано, преди VocalStack да е чул дума; режимът на закъснение е това, което наистина можете да преместите.
Режимът на закъснение прави едно нещо: определя баланса между забавяне и точност. Настройката се намира под Advanced при създаване на транскрипция на живо, а в раздела Speed – по време на работа. Там чипът показва AUTO, SPEED или ACCURACY (Fast се показва като SPEED). През API session.update я променя по време на потока.
Размяната е тази, която подсказват имената. Fast изважда текста по-бързо, но прави повече корекции; Accuracy отнема малко повече време и коригира по-малко. Публика, която седи и чете преведени субтитри, рядко забелязва допълнителна секунда, но забелязва думи, които се променят непрекъснато. Затова Accuracy често е по-добрата настройка, докато графиката на забавянето остава равна. Auto не крие действията си: ред, който е ускорен, за да затвори разлика, носи значка FAST MODE в транскрипта на домакина, с бележка, че точността там може да е по-ниска.
Във всеки режим транскрипцията трябва да е готова преди първата дума, а подготовката ѝ е единственото забавяне, което веригата плаща само веднъж.
При някои планове транскрипцията на живо отнема няколко секунди, за да стартира. Колко точно зависи от плана: редът Start-up speed на страницата с цени варира от студен старт до 15 секунди при Плащане при ползване до винаги топла при Enterprise.
През API чакането се показва като кадри session.loading, докато сесията стартира, след това session.ready; клиентът изпраща звук едва след това. Слушател, който отвори линка през това време, вижда „На живо. Първият ред ще се появи всеки момент.“ След като транскрипцията работи, това забавяне остава назад и остава само въпросът колко от останалото забавяне носите.
Докато транскрипцията на живо работи, разделът Speed показва на домакина какво прави всичко това заедно: текущата разлика между говорителя и текста, с чипа на режима до нея, и графика на тази разлика през целия запис, със средната и най-голямата стойност. В самия транскрипт ред, който е стигнал до слушателите късно, носи значка с броя секунди между момента, в който е бил изречен, и момента, в който е пристигнал.
Графика, която остава ниска и равна, означава, че режимът пасва на звука. Растяща графика означава, че конвейерът изостава. При Accuracy това може да е моментът да преминете към Auto, който разменя част от точността за скорост, докато разликата се затвори.
Разработчиците получават едно число вместо това. Когато realtime сесия приключи, session.done носи stats.realtimeFactor – транскрибираното аудио, разделено на времето, което е отнело транскрибирането му. Едно предупреждение за конвенцията: в литературата за разпознаване на реч real-time factor обикновено означава обратното – времето за обработка спрямо аудиото, като по-ниското е по-добро. VocalStack го отчита в обратна посока, така че тук по-високото е по-добро: жива сесия е близо до 1, а под 1 означава, че звукът е пристигнал по-бързо, отколкото конвейерът може да го транскрибира.
Нито една от тези секунди не е загадъчна. Някои принадлежат на потока, някои на дума, която чака следващата, някои на изречението, от което се нуждае преводът, а останалите на режима на закъснение, който сте избрали. API справката има подробностите кадър по кадър, а демото на началната страница показва веригата в действие.
