लाइभ अनुवादको अधिकांश ढिलाइ प्रतीक्षा हो: स्ट्रिमको, अर्को शब्दको, वाक्यको। तपाईंले नियन्त्रण गर्न सक्ने एउटै भाग लेटेन्सी मोड हो: कम ढिलाइ, वा कम संशोधन।
लाइभ अनुवाद हेर्ने श्रोताले वक्ताले बोलेको हरेक पङ्क्ति केही सेकेन्डपछि मात्र देख्छन्। त्यो अन्तर एउटै ढिलाइ होइन, एउटा श्रृंखलामा जोडिएका धेरै ढिलाइहरूको योग हो, र तिनमध्ये धेरैजसो एक प्रकारको प्रतीक्षा नै हो। कुन प्रतीक्षा कुन हो भनी थाहा हुँदा लेटेन्सी मोड छान्न सजिलो हुन्छ, र रिडर बनाउने विकासकर्तालाई के र कहिले रेन्डर गर्ने भनी बुझाउँछ।
संख्या हेर्नुअघि एउटा उपयोगी मापदण्ड: मानव सिमल्टेनियस दोभाषी सामान्यतया वक्ताभन्दा दुई देखि चार सेकेन्ड पछाडि बोल्छन्। दोभाषीहरूले यस अन्तरलाई ear-voice span भन्छन्, र क्रियापद अन्त्यमा आउने भाषाहरूमा उनीहरू क्रियापद आउनको लागि कुर्दैनन्, बरु त्यसको अनुमान गर्छन्, वा वाक्यलाई स्वतन्त्र रूपमा उभिन सक्ने टुक्राहरूमा बाँड्छन्। एक वा दुई सेकेन्डको ढिलाइ सफ्टवेयरको दोष होइन; यो लगभग एउटा राम्रो मानिसले पनि गर्ने कुरा हो।
VocalStack मा हरेक लाइभ ट्रान्सक्रिप्शन एउटै क्रममा, एउटै चरणहरूबाट गुज्रिन्छ, र प्रत्येक चरणले अघिल्लोको लागि प्रतीक्षा गर्छ।
मूल भाषाको पाठ लगभग बोलिएजस्तै रिडरसम्म पुग्छ। अनुवाद एक वा दुई सेकेन्ड पछि आउँछ, र बोलिएको वाक्य अनुवादपछि आउँछ, जसका कारण आवाज क्लिप सधैँ सबैभन्दा अन्त्यमा आउँछ। तर श्रृंखलाको पहिलो दृश्य प्रभाव कुनै पनि आवाजभन्दा धेरै अघि आउँछ: पाठ आफैँ सर्न थाल्छ।
लाइभ ट्रान्सक्रिप्टमा मानिसहरूले पहिले ध्यान दिने कुरा के हो भने सबैभन्दा नयाँ शब्दहरू सर्छन्। एउटा वाक्यांश देखिन्छ, बदलिन्छ, र अन्तमा स्थिर हुन्छ। यो ड्राफ्ट चरणको काम हो, र यो हरेक स्पिच रेकग्नाइजरमा लागू हुने कारणले हुन्छ।
रेकग्नाइजरले शब्दलाई त्यसपछि आउने शब्द हेरेर स्थिर गर्छ। “I scream” र “ice cream” अर्को शब्द नआउन्जेल एउटै सुनिन्छन्, र शब्दको अन्त्यको “s” यही शब्दको वा अर्कोको हुन सक्छ। शब्दको दायाँ तर्फ अडियो नआएसम्म त्यसको हिज्जे अनुमान मात्र हो, त्यसैले कुनै पनि लाइभ ट्रान्सक्रिप्टका सबैभन्दा नयाँ शब्दहरू सधैँ सबैभन्दा कम निश्चित हुन्छन्। ड्राफ्ट भनेको त्यही अनुमान लुकाएर नभई चाँडै देखाइएको रूप हो।
हरेक ड्राफ्टले लाइभ टेल, अर्थात् अन्तिम कमिटपछि सुनिएका र अझै परिवर्तन भइरहेका शब्दहरूलाई पूरै बदल्छ। कमिट अन्तिम हुन्छ। यो कहिल्यै परिवर्तन हुँदैन, यसमा शब्द-स्तरका समय हुन्छन्, र कमिटहरू अन्तरबिना क्रमाङ्कित हुन्छन्, ताकि रिडरले कुनै एउटा छुटेको छ कि छैन भनी थाहा पाउन सकोस्।
विकासकर्ताका लागि रियलटाइम 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 पङ्क्तिले प्रयोग अनुसार भुक्तानीमा १५ सेकेन्डसम्मको कोल्ड स्टार्टदेखि Enterprise मा सधैँ तातो अवस्थासम्म देखाउँछ।
API मा, सत्र सुरु हुँदा प्रतीक्षा session.loading फ्रेमको रूपमा देखिन्छ, त्यसपछि session.ready आउँछ; क्लाइन्टले त्यसपछि मात्र अडियो पठाउँछ। त्यसबीचमा लिङ्क खोल्ने श्रोताले “लाइभ। पहिलो पङ्क्ति एक क्षणमा देखिन्छ।” भन्ने सन्देश देख्छ। ट्रान्सक्रिप्शन चलिरहेपछि यो ढिलाइ पछाडि छुट्छ, र बाँकी एउटै प्रश्न हुन्छ: बाँकी ढिलाइमध्ये तपाईंले कति बोकिरहनुभएको छ।
लाइभ ट्रान्सक्रिप्शन चल्दा, होस्टको Speed ट्याबले यी सबैको योगफल देखाउँछ: वक्ता र पाठबीचको हालको अन्तर, छेउमा मोड चिप सहित, र रेकर्डिङभरिको अन्तरको चार्ट, त्यसको औसत र उच्चतमसहित। ट्रान्सक्रिप्टमा नै, श्रोतासम्म ढिलो पुगेको पङ्क्तिमा बोलिएको र पुगेको समयबीचका सेकेन्डको सङ्ख्या देखाउने ब्याज हुन्छ।
चार्ट कम र स्थिर रहनु भनेको मोड अडियोसँग मेल खान्छ भन्ने हो। चार्ट माथि चढ्नु भनेको पाइपलाइन पछाडि परिरहेको हो। Accuracy मा हुँदा, त्यो Auto मा सर्ने क्षण हुन सक्छ, जसले अन्तर बन्द नहुन्जेल केही शुद्धता छोडेर गति बढाउँछ।
विकासकर्ताले भने एउटै सङ्ख्या पाउँछन्। रियलटाइम सत्र समाप्त हुँदा, session.done ले stats.realtimeFactor बोक्छ: ट्रान्सक्राइब गरिएको अडियो, त्यसलाई ट्रान्सक्राइब गर्न लागेको समयले भाग गरेको। एउटा सम्मेलनको चेतावनी: स्पीच-रेकग्निसनको साहित्यमा real-time factor ले सामान्यतया उल्टो अर्थ जनाउँछ, अर्थात् प्रशोधन समय अडियो समयको अनुपातमा, जहाँ कम हुनु राम्रो हो। VocalStack ले यसलाई उल्टो तरिकाले रिपोर्ट गर्छ, त्यसैले यहाँ बढी हुनु राम्रो हो: लाइभ सत्र लगभग 1 मा रहन्छ, र 1 भन्दा कम भए अडियो पाइपलाइनले ट्रान्सक्राइब गर्न सक्नेभन्दा छिटो आएको भन्ने हो।
यी कुनै सेकेन्ड रहस्यमय छैनन्। केही स्ट्रिमका हुन्, केही एउटा शब्दले त्यसपछिको शब्दको लागि कुर्ने क्रमका हुन्, केही अनुवादलाई चाहिने वाक्यका हुन्, र बाँकी तपाईंले छानेको लेटेन्सी मोडका हुन्। API सन्दर्भ मा फ्रेम-फ्रेमको विवरण छ, र गृहपृष्ठ मा रहेको डेमोले श्रृंखला चलिरहेको देखाउँछ।
