AI डबिंग पाइपलाइन आर्किटेक्चर: प्रोडक्शन से मिले सबक
प्रोडक्शन में AI डबिंग पाइपलाइन कैसे काम करती है: चार मॉडल चरण, फ़ारसी की मुश्किलें, और वह प्रोवाइडर फ़ॉलबैक जिसने आउटेज के बाद ख़ामोशी की जगह ली।
AI डबिंग पाइपलाइन चार मॉडल-आधारित चरणों की शृंखला है: स्पीकर की पहचान के साथ ट्रांसक्रिप्शन, ऐसा अनुवाद जो मूल टाइमिंग में समा जाए, हर स्पीकर के लिए अलग आवाज़, और फ़ाइनल मिक्स के साथ टाइमिंग का मिलान। मॉडल वह हिस्सा हैं जिसे आप किराये पर ले सकते हैं। डब लगातार डिलीवर होते रहेंगे या नहीं, यह उनके इर्द-गिर्द के प्लेटफ़ॉर्म पर निर्भर करता है: हर AI प्रोवाइडर के लिए अलग गेटवे, जिसमें अपने-आप फ़ॉलबैक हो, ड्यूरेबल क्यू, ऐसा काम जो क्रैश के बाद वहीं से फिर शुरू हो जाए, जॉब चलने से पहले दिखाई गई क़ीमत, और जॉब विफल होने पर रिफ़ंड। Booq में, जहाँ मैं CTO हूँ, एक बार एक स्पीच प्रोवाइडर के आउटेज की वजह से ऐसे डब बने जिनमें छूटी हुई लाइनों की जगह ख़ामोशी थी। अब स्पीच, प्रोवाइडरों की एक शृंखला से होकर फ़ॉलबैक करती है: थोड़ी अलग आवाज़ ख़ामोशी से बेहतर है।
AI डबिंग पाइपलाइन कैसे काम करती है: चार चरण
ऑटोमैटिक डबिंग पर हुए शोध में भी ऐसी ही शृंखला का वर्णन मिलता है। Federico और साथियों (2020) ने एक speech-to-speech translation पाइपलाइन से शुरुआत की और उसमें वह जोड़ा जिसकी डबिंग को ज़रूरत होती है:
मशीनी अनुवाद, जो वांछित लंबाई का आउटपुट दे।
प्रोसोडिक अलाइनमेंट (prosodic alignment): अनुवाद के वाक्यांशों और ठहरावों का मूल स्पीच के सेगमेंट से मिलान।
टेक्स्ट-टू-स्पीच (TTS), जिसमें हर utterance की अवधि बारीकी से ट्यून की जाती है।
ऑडियो रेंडरिंग, जो मूल ऑडियो से निकाला गया बैकग्राउंड नॉइज़ और रिवर्बरेशन (गूँज) जोड़ती है।
जिस वीडियो में कई लोग हों, उसे डब करने वाली पाइपलाइन को यह भी पता होना चाहिए कि कौन बोल रहा है।
शृंखला का डायग्राम पूरे आकार में खोलें
आगे के चरण-वार सेक्शन शोध और डिज़ाइन स्पेस का वर्णन करते हैं: हर चरण को क्या हल करना होता है और वह कहाँ टूटता है। वे किसी भी प्रोडक्ट की अंदरूनी व्यवस्था का वर्णन नहीं करते, Booq की भी नहीं। उनमें Booq जहाँ आता है, वहाँ सिर्फ़ उतना ही है जितना उसकी केस स्टडी कहती है, और फ़ारसी उच्चारण वाला हिस्सा मेरे अपने टेक्स्ट-टू-स्पीच शोध पर आधारित है। प्लेटफ़ॉर्म वाले सेक्शन प्रत्यक्ष अनुभव से हैं।
चरण 1: ट्रांसक्रिप्शन और स्पीकर की पहचान
आगे के हर चरण को ट्रांसक्रिप्ट विरासत में मिलता है। रिकग्नाइज़र का ख़ुद गढ़ा हुआ शब्द भी उतने ही भरोसे से अनूदित होता है, आवाज़ पाता है और टाइमलाइन पर बैठता है, जितना स्पीकर का बोला हुआ शब्द। फ़ारसी के लिए, ऑटोमैटिक स्पीच रिकग्निशन (ASR) कहाँ ग़लती करता है, इस पर सबसे उपयोगी सार्वजनिक साक्ष्य PSRB है, जो 2025 में प्रकाशित एक बेंचमार्क है।
फ़ारसी स्पीच रिकग्निशन कहाँ विफल होता है
PSRB दस ASR सिस्टम का मूल्यांकन करता है, कमर्शियल भी और ओपन-सोर्स भी। उसका सार यह है कि मॉडल आम तौर पर मानक फ़ारसी पर अच्छा प्रदर्शन करते हैं, लेकिन क्षेत्रीय लहजों, बच्चों की बोली और कुछ ख़ास भाषाई चुनौतियों पर लड़खड़ाते हैं। ब्योरा पढ़ें तो लगता है मानो उसी ऑडियो का वर्णन हो जिसे लोग डब करवाना चाहते हैं:
लहजे। जिन 12 लहजों का मूल्यांकन हुआ, उनमें पहचान की सटीकता मशहदी और यज़्दी के लिए सबसे कम रही।
बच्चे। बोलने वाले बच्चों की पहचान सबसे ख़राब रही।
कई स्पीकर। हर मॉडल ने एक स्पीकर वाले ऑडियो की तुलना में कई स्पीकर वाले ऑडियो पर ज़्यादा ग़लतियाँ कीं। लेखक ऐसे ऑडियो की सबसे बड़ी चुनौती एक-दूसरे पर चढ़ती (overlapping) स्पीच को बताते हैं, हालाँकि बेंचमार्क में ओवरलैप कम से कम रखा गया था, और कुछ मॉडलों ने कभी-कभी किसी पूरे स्पीकर को ही ट्रांसक्रिप्ट से ग़ायब कर दिया।
कंटेंट का प्रकार। ऑडियोबुक पर एरर रेट सबसे कम रहा। टॉक शो, एनिमेशन और फ़िल्मों में, जहाँ स्वाभाविक संवाद, ओवरलैप होती स्पीच और बैकग्राउंड नॉइज़ आम हैं, नतीजे काफ़ी ख़राब रहे।
औपचारिकता का स्तर। बेंचमार्क की 71.3% स्पीच अनौपचारिक है।
पेपर उन एरर-प्रकारों का भी नाम लेता है जो फ़ारसी लिपि और बोली के लिए ख़ास हैं:
शब्द-सीमाएँ। बहुवचन درختها (“पेड़”) zero-width non-joiner (ZWNJ) के साथ लिखा जाता है। जब ZWNJ छूट जाता है या उसकी जगह कुछ और आ जाता है, तो ग़लतियाँ दिखती हैं: درختها या درخت ها।
औपचारिकता का उलट जाना। अनौपचारिक میخوام برم (“मैं जाना चाहता हूँ”) औपचारिक میخواهم بروم बनकर लौट सकता है, या इसका उलटा।
He-Kasreh। स्वामित्व या संबंध दिखाने वाला छोटा /e/ स्वर अक्षर he (ه) के रूप में लिख दिया जा सकता है: کتاب او (“उसकी किताब”) का ट्रांसक्रिप्शन کتابه او हो सकता है। यह इज़ाफ़त का लिखित रूप में आ जाना है — वही अलिखित ध्वनि, जिस पर चरण 3 फिर लौटता है।
पैराफ़्रेज़। خوش میگذره (“मज़ा आ रहा है”) बदलकर حال میده (“अच्छा लग रहा है”) हो सकता है। अर्थ बच जाता है; शब्द नहीं।
हैलुसिनेशन। धाराप्रवाह, सुसंगत टेक्स्ट, जो ऑडियो पर बिल्कुल आधारित नहीं है।
सामान्य वर्ड एरर रेट (WER) हर प्रतिस्थापन (substitution) को एक पूरा ग़लत शब्द मानता है, इसलिए ZWNJ की एक चूक की क़ीमत किसी दूसरे शब्द जितनी, या उससे भी ज़्यादा, हो सकती है: अगर ZWNJ की जगह स्पेस आ जाए, तो एक शब्द दो शब्द बन जाता है, जिसे एक प्रतिस्थापन और एक insertion, दोनों के रूप में गिना जाता है। PSRB प्रतिस्थापन के हिसाब से वज़न देने वाला एक रूप, SW-WER, प्रस्तावित करता है: हर प्रतिस्थापन के लिए कैरेक्टर एरर रेट निकाला जाता है और उसे उस अलाइनमेंट के शब्दों की संख्या से गुणा किया जाता है, ताकि स्पेसिंग की चूक की क़ीमत किसी दूसरे शब्द से कम रहे। फ़ारसी टेक्स्ट पर रिट्रीवल को भी इन्हीं कैरेक्टर को नॉर्मलाइज़ करना पड़ता है, जैसा फ़ारसी RAG के लिए हाइब्रिड सर्च में समझाया गया है।
मेरी समझ में डिज़ाइन के लिए इसका नतीजा यह है: लोग जिस ऑडियो को डब करवाना चाहते हैं, पहचान वहीं सबसे कमज़ोर है, और हैलुसिनेट या पैराफ़्रेज़ की गई लाइन ट्रांसक्रिप्ट में ही नहीं रुकती। वह पूरे भरोसे के साथ डब की गई लाइन बन जाती है। रेंडरिंग से पहले समीक्षा का एक पड़ाव रखने का तर्क यही है। Booq दोनों मोड देता है: बिना हाथ लगाए पूरा चलाना, या कुछ भी रेंडर होने से पहले रुककर सबटाइटल की समीक्षा और संपादन करना।
स्पीकर डायराइज़ेशन: किसने कब बोला
Park और साथी स्पीकर डायराइज़ेशन (speaker diarization) को “किसने कब बोला” पहचानने का काम बताते हैं। डब में यही तय करता है कि किस लाइन को कौन-सी आवाज़ मिलेगी। Third DIHARD Diarization Challenge ने 11 विविध डोमेन में सिस्टम का मूल्यांकन किया और निष्कर्ष निकाला कि उनमें से कई में, वेब वीडियो समेत, यह समस्या “अब भी हल होने से बहुत दूर है”।
किसी भी पाइपलाइन में डायराइज़ेशन के बाद मैं जो जाँच रखूँगा, वह सीधी है: क्या हर पहचाने गए स्पीकर के पास लाइनें हैं, और क्या हर लाइन का कोई स्पीकर है? PSRB में कुछ सिस्टम ने पूरे स्पीकर को ही ट्रांसक्रिप्ट से छोड़ दिया, और छूटा हुआ स्पीकर ग़ायब वॉइस ट्रैक बन जाता है।
चरण 2: ऐसा अनुवाद जो समय में समा जाए
डब अनुवाद पर एक शर्त जोड़ देता है: नई लाइन लगभग उतने ही समय में बोली जानी चाहिए जितना मूल लाइन में लगा था। खुलकर अनुवाद करें, तो सिंथेटिक आवाज़ को जल्दबाज़ी करनी पड़ती है, या लाइन अगली लाइन में घुस जाती है।
आइसोक्रोनी: लंबाई और अवधि एक ही समस्या हैं
शोध में इसे आइसोक्रोनी (isochrony) कहते हैं। Chronopoulou और साथी (2023) इसे ऐसी नई स्पीच बताते हैं जो मूल वीडियो के साथ समय में मेल खाए, “मुँह की हरकतों, ठहरावों, हाथ के इशारों समेत”। वे एक ऐसा मॉडल ट्रेन करते हैं जो अनुवाद और उसकी स्पीच की अवधि को एक साथ ऑप्टिमाइज़ करता है, और रिपोर्ट करते हैं कि इससे बनी स्पीच पिछले काम की तुलना में मूल टाइमिंग से बेहतर मेल खाती है, और आर्किटेक्चर भी सरल रहता है।
पहले के काम लंबाई को टेक्स्ट में ही नियंत्रित करते थे। Isometric MT (Lakew और साथी, ICASSP 2022) उदाहरण के तौर पर ऐसा लक्ष्य लेता है जिसमें अनुवाद, कैरेक्टर की गिनती में, स्रोत की लंबाई के ±10% के भीतर रहे, और इसकी क़ीमत के बारे में साफ़ बात करता है: आउटपुट की लंबाई नियंत्रित करने से अनुवाद की गुणवत्ता घटती है, और इसकी भरपाई का आम तरीक़ा है कई संभावित अनुवाद (N-best hypotheses) बनाना और फिर उन्हें दोबारा रैंक करना। ±10% एक पेपर का उदाहरण है, इंडस्ट्री का नियम नहीं, और कैरेक्टर की गिनती बस इसका एक अनुमान (proxy) है कि लाइन बोलने में कितना समय लगेगा।
जब रफ़्तार बिगड़ती है, तो नतीजा सुनाई देता है। YouTube का automatic dubbing सहायता पेज स्पीच की रफ़्तार (speech pacing) को उन कारणों में गिनाता है जिनकी वजह से कोई वीडियो इसके योग्य न हो: बहुत तेज़ मूल स्पीच “ऐसे तेज़ किए गए डब में बदल जाएगी जिसे सुना नहीं जा सकता”।
टाइमिंग कितनी सख़्त होनी चाहिए?
स्क्रीन पर दिखते स्पीकर के लिए ऑफ़-स्क्रीन आवाज़ से ज़्यादा सख़्त, और पेशेवर डबिंग के चलन को देखें तो उतनी निरपेक्ष नहीं जितना शोध अक्सर मान लेता है। Brannon, Virkar और Thompson (TACL 2023) ने पेशेवर तौर पर प्रोड्यूस किए गए 54 टाइटल के 319.57 घंटे के वीडियो के ज़रिये अध्ययन किया कि लोग डबिंग कैसे करते हैं। उनके नतीजे मानवीय और ऑटोमैटिक, दोनों तरह की डबिंग पर लिखे साहित्य में आम कई धारणाओं को चुनौती देते हैं। उनका तर्क है कि आवाज़ की स्वाभाविकता और अनुवाद की गुणवत्ता उन isometric (कैरेक्टर-लंबाई) और लिप-सिंक शर्तों से ज़्यादा अहम हैं जिन पर आम तौर पर ज़ोर दिया जाता है, और यह कि टाइमिंग की शर्तें कितनी मायने रखती हैं, इस पर ज़्यादा सावधानी भरा नज़रिया चाहिए।
स्पीकर स्क्रीन पर है या नहीं, इससे भी फ़र्क़ पड़ता है। Virkar और साथियों (2022) ने वह prosodic alignment मॉडल, जो उन्होंने पहले स्क्रीन पर दिखने वाली डबिंग के लिए बनाया था, off-screen डबिंग तक बढ़ाया, जिसमें उस स्पीकर की डबिंग की तुलना में, जिसका मुँह दिख रहा हो, “कम सख़्त synchronization शर्तों की ज़रूरत होती है”। इसलिए टाइमिंग का बजट हर सीन के लिए अलग फ़ैसला है, कोई एक ग्लोबल सेटिंग नहीं।
Booq के बारे में प्रकाशित बात यह है कि टाइमिंग को मूल के साथ मिलाया जाता है। केस स्टडी टाइमिंग के बारे में बस इतना ही कहती है, और मैं भी यहाँ इससे ज़्यादा दावा नहीं करता।
चरण 3: हर स्पीकर के लिए अलग आवाज़
Booq पर हर पहचाने गए स्पीकर को अलग आवाज़ मिलती है। कई स्पीकर वाले किसी भी डब की आवाज़ों में दो गुण ज़रूरी हैं: दो स्पीकर एक जैसे न सुनाई दें, और एक स्पीकर की आवाज़ पहली लाइन से आख़िरी लाइन तक वही रहे। दूसरे गुण को याद रखिए; आगे का पोस्ट-मॉर्टम इसी के बारे में है कि वह कैसे हार गया।
फ़ारसी का ओपन स्पीच डेटा बहुत कम है। ParsVoice के लेखक लिखते हैं कि ओपन स्पीच-टेक्स्ट संसाधनों में फ़ारसी का “प्रतिनिधित्व अब भी काफ़ी कम है”। उनके कॉर्पस में 2,200 घंटे का TTS के लिए तैयार उपसमूह है, जो पहले उपलब्ध सबसे बड़े ओपन फ़ारसी TTS डेटासेट से 25 गुना से ज़्यादा बड़ा है। डेटा एक बाधा है। दूसरी बाधा किसी भी ऑडियो के बनने से पहले आती है: यह तय करना कि टेक्स्ट का उच्चारण कैसे होगा।
फ़ारसी उच्चारण: ह्रस्व स्वर, इज़ाफ़त और होमोग्राफ़
जून 2021 से सितंबर 2022 के बीच मैंने फ़ारसी टेक्स्ट-टू-स्पीच शोध पर काम किया। यह शोध ईरान के सबसे बड़े मोबाइल ऑपरेटर MCI (Hamrah-e Aval) ने करवाया था और उसी की निगरानी में हुआ, और इसका प्रबंधन National Elites Foundation ने अपने Shahid Ahmadi Roshan कार्यक्रम के तहत किया। मुश्किल हिस्सा भाषाई था। उस पाइपलाइन में लिखा हुआ टेक्स्ट पहले ग्राफ़ीम-टू-फ़ोनीम रूपांतरण (G2P) से गुज़रता है, जो तय करता है कि उसका उच्चारण कैसे होगा। फिर एक टेक्स्ट-टू-स्पीच मॉडल और एक वोकोडर स्पीच बनाते हैं; वोकोडर वह घटक है जो मॉडल के ध्वनिक (acoustic) आउटपुट को ऑडियो वेवफ़ॉर्म में बदलता है। फ़ारसी लिपि पहले ही क़दम को तीन तरह से अस्पष्ट बना देती है:
ह्रस्व स्वर लिखे नहीं जाते, इसलिए सिर्फ़ टेक्स्ट से उच्चारण तय नहीं होता।
इज़ाफ़त (ezāfe) की बनावट भी लिखी नहीं जाती, और उसका अनुमान लगाना पड़ता है।
होमोग्राफ़ में अलग-अलग शब्दों की वर्तनी एक ही होती है, और संदर्भ के बिना उनमें फ़र्क़ नहीं किया जा सकता।
प्रकाशित शोध भी यही कहता है। GE2PE (Findings of EMNLP 2024) के लेखक इज़ाफ़त को एक /e/ ध्वनि बताते हैं जो संज्ञाओं को विशेषणों और वर्णनात्मक संज्ञाओं से जोड़ती है, और होमोग्राफ़ का एक उदाहरण देते हैं: /kerm/, /kerem/ और /karam/ लिखित रूप में एक जैसे हैं, کرم। उनका निष्कर्ष है कि स्वीकार्य नतीजों के लिए फ़ारसी G2P को वाक्यांश-स्तर या वाक्य-स्तर का इनपुट चाहिए। Doostmohammadi और साथी (2020) जोड़ते हैं कि फ़ारसी लिपि में इज़ाफ़त लगभग कभी चिह्नित नहीं की जाती, जिससे जटिल वाक्य पढ़ने में ग़लतियाँ और भाषा-प्रोसेसिंग में त्रुटियाँ होती हैं। इस प्रोजेक्ट का ब्योरा फ़ारसी टेक्स्ट-टू-स्पीच केस स्टडी में है।
डिज़ाइन के लिए इसका नतीजा मेरा निष्कर्ष है, उन पेपरों की खोज नहीं: फ़ारसी TTS को वे टुकड़े न दें जिनमें सबटाइटल ट्रैक काटा जाता है। सबटाइटल का एक ब्रेक इज़ाफ़त की शृंखला को बीच से तोड़ सकता है, या किसी होमोग्राफ़ को उन शब्दों से अलग कर सकता है जिनसे उसका अर्थ साफ़ होता है। पूरे वाक्य सिंथेसाइज़ करें, फिर ऑडियो को टाइमलाइन में फ़िट करें।
चरण 4: टाइमिंग का मिलान और फ़ाइनल मिक्स
आख़िरी चरण क्लिपों को ऐसे साउंडट्रैक में बदलता है जो वीडियो का ही हिस्सा लगे। Federico की पाइपलाइन में रेंडरिंग मूल ऑडियो से निकाला गया बैकग्राउंड नॉइज़ और रिवर्बरेशन जोड़ती है, ताकि नई आवाज़ उसी ध्वनि-परिवेश में बैठे जिसमें तस्वीर है।
Booq पर फ़ाइनल आउटपुट में वर्टिकल और वाइडस्क्रीन वीडियो के लिए स्टाइल किए गए बर्न-इन सबटाइटल शामिल हो सकते हैं, और मूल ऑडियो या बैकग्राउंड म्यूज़िक डब के नीचे धीमे स्वर में बना रहता है। बर्न-इन सबटाइटल तस्वीर का ही हिस्सा होते हैं, इसलिए उनका लेआउट रेंडरिंग से पहले हर aspect ratio के लिए तय करना पड़ता है; बाद में कोई प्लेयर उसे ठीक नहीं कर सकता।
इस चरण से डिज़ाइन के दो सवाल जुड़े हैं। पहला यह कि उस लाइन का क्या करें जिसका सिंथेसाइज़ किया गया ऑडियो अनुवाद के बाद भी लंबा खिंच रहा हो। शोध और व्यवहार, दोनों मिलाकर तीन उपाय देते हैं, और इनमें से चुनना डिज़ाइन का फ़ैसला है, कोई शोध-निष्कर्ष नहीं:
अनुवाद के समय ही लाइन छोटी करें। Isometric MT और अनुवाद व अवधि को एक साथ ऑप्टिमाइज़ करने वाले मॉडल यहीं काम करते हैं।
TTS में हर utterance की अवधि ट्यून करें। Federico की पाइपलाइन हर utterance की अवधि बारीकी से ट्यून करती है।
आवाज़ तेज़ करें, एक हद के भीतर। यह उपाय शोध से नहीं, व्यवहार से आता है, और एक हद तक ही काम करता है: YouTube का सहायता पेज चेतावनी देता है कि तेज़ किया गया डब सुनने लायक नहीं रह सकता।
दूसरा सवाल यह है कि जहाँ लाइन ग़ायब हो, वहाँ श्रोता क्या सुनता है। यह सवाल आख़िरकार ऑडियो का नहीं, आर्किटेक्चर का निकला।
मॉडलों के इर्द-गिर्द का प्लेटफ़ॉर्म
ऊपर का सब कुछ ऐसा शोध है जिसे आप पढ़ सकते हैं, और ऐसे मॉडल हैं जिन्हें आप किराये पर ले सकते हैं। Booq पर हर क्षमता बाहरी AI प्रोवाइडरों पर निर्भर है, और उनमें से हर एक स्वतंत्र रूप से विफल हो सकता है या बदल सकता है। CTO के रूप में मैंने Booq का आर्किटेक्चर तय किया और उसे पहले commit से प्रोडक्शन तक पहुँचाया; Booq केस स्टडी इस प्लेटफ़ॉर्म का वर्णन करती है। उसके पोस्ट-मॉर्टम का हर सबक मॉडलों के इर्द-गिर्द है, उनके भीतर नहीं।
प्लेटफ़ॉर्म का डायग्राम पूरे आकार में खोलें
हर AI प्रोवाइडर के लिए एक गेटवे
Booq एक वेब ऐप के पीछे स्वतंत्र सर्विसों का समूह है, जिसमें हर AI प्रोवाइडर के लिए अलग गेटवे है। यही एक फ़ैसला मॉडल बदलने, key रोटेट करने या विफल हो रहे प्रोवाइडर को अपने-आप बायपास करने देता है, प्रोडक्ट के बाक़ी हिस्से को छुए बिना। मॉडल और प्रोवाइडर keys एडमिन पैनल से बदली जाती हैं, दोबारा deploy किए बिना। केस स्टडी हर गेटवे के साथ ऑटोमैटिक फ़ॉलबैक का ज़िक्र करती है, और आगे का पोस्ट-मॉर्टम दिखाता है कि स्पीच को इसकी ज़रूरत क्यों पड़ी।
ड्यूरेबल प्रायोरिटी क्यू और चेकपॉइंट
लंबे वीडियो की डबिंग वेब रिक्वेस्ट के भीतर नहीं होनी चाहिए। Booq पर भारी प्रोसेसिंग इसके बजाय ड्यूरेबल प्रायोरिटी क्यू में इंतज़ार करती है, जिनमें हर सर्विस की अपनी सीमा है। हर सर्विस की अलग सीमा ही एक व्यस्त सर्विस को बाक़ी सर्विसों को संसाधनों से वंचित करने से रोकती है।
अनुवाद चेकपॉइंट सेव करते हैं और क्रैश के बाद वहीं से आगे बढ़ते हैं जहाँ रुके थे। चेकपॉइंट के बिना, लंबे ट्रांसक्रिप्ट के आख़िरी हिस्से के पास हुआ क्रैश उससे पहले किए गए हर प्रोवाइडर कॉल को दोहराता है, और उनमें से हर कॉल का भुगतान फिर से होता है।
अस्थिर कनेक्शन पर रिज़्यूमेबल अपलोड
बड़ी वीडियो फ़ाइलें Booq तक अस्थिर कनेक्शनों से पहुँचती हैं, और अपलोड, कई गीगाबाइट वाले भी, कमज़ोर नेटवर्क पर शुरू से दोबारा होने के बजाय वहीं से आगे बढ़ते हैं।
इसका सामान्य तरीक़ा मानकीकरण की प्रक्रिया में है। Resumable Uploads for HTTP, IETF के HTTP working group में एक सक्रिय Internet-Draft है, अभी RFC नहीं: अगर सर्वर बता सके कि रुकावट से पहले उसने कितना डेटा प्रोसेस कर लिया था, तो क्लाइंट सब कुछ दोबारा भेजने के बजाय उसी बिंदु से आगे भेजता है। यह अभी तैयार हो रहा काम है, Booq के implementation का वर्णन नहीं।
जॉब से पहले क़ीमत, विफलता पर रिफ़ंड
बिलिंग भी पाइपलाइन का हिस्सा है। Booq पर हर जॉब चलने से पहले अपनी क़ीमत, या शुरुआती अनुमान, दिखाता है। वॉलेट तोमान में प्रीपेड है और VAT पहले ही दिखा दिया जाता है, हर लेन-देन एक स्थायी लेजर में दर्ज होता है, और विफल जॉब का पैसा अपने-आप लौट आता है। रिफ़ंड को दो बार भुगतान होने से सुरक्षित रखा गया है।
इस आख़िरी गुण की सबसे कड़ी टेस्टिंग होनी चाहिए: timeout के बाद retry ठीक वही मौक़ा है जब सीधा-सादा रिफ़ंड दो बार भुगतान कर देता है।
रिलीज़ नहीं, स्विच
Booq पर प्रोडक्ट के हिस्से बिना रिलीज़ के चालू या बंद किए जाते हैं। Pete Hodgson के feature toggles वर्गीकरण में यह ops toggle के क़रीब है: ऐसा toggle जो ऑपरेटरों को प्रोडक्शन में किसी फ़ीचर को जल्दी से बंद करने या उसका स्तर घटाने देता है।
इसी सोच से एक्सेस भी अलग रखा गया है। ग्राहक, एडमिनिस्ट्रेटर और सपोर्ट स्टाफ़, हर कोई अलग से deploy किया गया ऐप इस्तेमाल करता है, एक ऐप का साइन-इन दूसरे में काम नहीं करता, और कंसोल के लिए रोल-आधारित अनुमतियों के साथ दूसरा फ़ैक्टर ज़रूरी है।
पोस्ट-मॉर्टम: जब आवाज़ की एकरूपता ख़ामोशी से हार गई
Booq पर स्पीच को शुरू में जान-बूझकर एक ही प्रोवाइडर से बाँधा गया था, क्योंकि अलग प्रोवाइडर का मतलब है अलग आवाज़। डब में एकरूपता ही वह गुण लगती थी जिसकी रक्षा करनी थी। फिर उस प्रोवाइडर का आउटेज हुआ, और डब ऐसे जोड़े गए कि छूटी हुई लाइनों की जगह ख़ामोशी थी।
अब स्पीच, प्रोवाइडरों की एक शृंखला से होकर फ़ॉलबैक करती है, इस सिद्धांत पर कि थोड़ी अलग आवाज़ ख़ामोशी से बेहतर है।
फ़ॉलबैक शृंखला सोच-समझकर डिज़ाइन करना
पहला चुनाव लापरवाही नहीं था; वह एक असली गुण की रक्षा कर रहा था। प्रोडक्शन में प्लेटफ़ॉर्म चलाने से दिशा में जो बदलाव आए, केस स्टडी उनका सार यों देती है: हर बदलाव ने “एक आरामदेह धारणा के बदले ज़्यादा सुरक्षित डिफ़ॉल्ट लिया”। सबक यह है कि आप कौन-सी विफलता स्वीकार करेंगे, यह आउटेज के तय करने से पहले ख़ुद तय करें। जब पसंदीदा स्पीच प्रोवाइडर डाउन हो, तो पाइपलाइन ख़ाली जगह छोड़ सकती है, जॉब को विफल करके रिफ़ंड कर सकती है, या दूसरी आवाज़ इस्तेमाल कर सकती है। इनमें से सिर्फ़ ख़ाली जगह ही श्रोता के हाथ में छेदों वाला डब थमाती है।
इसके बाद दूसरा फ़ैसला आता है, और आगे जो लिखा है वह मेरा विश्लेषण है, Booq का वर्णन नहीं: फ़ॉलबैक कितना हिस्सा बदले। अगर सिर्फ़ ग़ायब लाइन का प्रोवाइडर बदलता है, तो उस स्पीकर की आवाज़ सीन के बीच में बदल जाती है। अगर स्पीकर का पूरा ट्रैक बदलता है, तो डब एकरूप रहता है, लेकिन ज़्यादा काम दोबारा करना पड़ता है।
Google की SRE किताब ओवरलोड हुई सर्विसों के लिए इससे जुड़ा एक विचार बताती है, graceful degradation: जवाबों की गुणवत्ता घटाकर कम काम करना। यहाँ जो बात लागू होती है, वह उसकी यह चेतावनी है कि “जिस code path का आप कभी इस्तेमाल नहीं करते, वही code path (अक्सर) काम नहीं करता”, और उसकी यह सलाह कि degraded मोड को नियमित रूप से चलाकर परखा जाए। किसी भी स्पीच फ़ॉलबैक शृंखला में मैं जो जोड़ूँगा — Booq का वर्णन नहीं, सिफ़ारिश के तौर पर — वह यह है कि आंतरिक क्लिपों पर निर्धारित टेस्ट जॉब शृंखला के हर प्रोवाइडर से होकर चलाए जाएँ, ताकि आउटेज में ज़रूरत पड़ने से पहले ही पता हो कि फ़ॉलबैक काम करता है।
सही विफलता प्रोडक्ट पर निर्भर करती है। इस साइट का सहायक इसका उलटा करता है: जब साइट पर किसी सवाल के समर्थन में कुछ नहीं होता, तो वह अंदाज़ा लगाने के बजाय तय शब्दों में इनकार कर देता है, और जब वह सवाल को मेरे बारे में नहीं मानता, तो भाषा मॉडल को कॉल ही नहीं किया जाता। सवाल-जवाब में कुछ न कहना सुरक्षित विफलता है, क्योंकि पूरे भरोसे से दिया गया ग़लत जवाब, जवाब न होने से बदतर है। यह डिज़ाइन RAG हैलुसिनेशन गार्डरेल में है, और लैब का RAG बनाम बिना रिट्रीवल पेज भी इसी नियम पर बना है। डब में ख़ामोशी ही विफलता है। कौन-सी विफलता स्वीकार्य है, यह प्रोडक्ट का फ़ैसला है, मॉडल का नहीं।
उपयोगकर्ता को इंतज़ार कराए बिना मॉडरेशन
Booq पर कंटेंट की जाँच पहले प्रोजेक्ट बनाने की प्रक्रिया के भीतर चलती थी, इसलिए उपयोगकर्ता अपलोड पूरा होने और अपने प्रोजेक्ट पेज तक पहुँचने के बीच इंतज़ार करते थे। अब यह बैकग्राउंड में चलती है। इमेज, वीडियो, ऑडियो और टेक्स्ट की जाँच होती है, अपील का रास्ता भी है, और तैयार नतीजा समीक्षा पूरी होने तक “कंटेंट की समीक्षा जारी है” स्थिति में रोका जाता है। जब तक समीक्षा चल रही हो, आउटपुट को तैयार के रूप में नहीं दिखाया जाता।
यह पैटर्न मीडिया पाइपलाइन की किसी भी धीमी जाँच पर लागू होता है: उसे रिक्वेस्ट पाथ से बाहर निकालें, और बीच की स्थिति को स्पष्ट रूप से दिखाएँ।
रिलीज़ गेट, और ऐसे बैकअप जिन्हें किसी ने पढ़ा हो
Booq पर प्रोडक्शन deploy ऑटोमैटिक से बदलकर मैनुअल मंज़ूरी पर आ गए, जो स्टेजिंग की जाँचें पास होने के बाद ही खुलती है। हर रिलीज़, किसी व्यक्ति के प्रोडक्शन के लिए मंज़ूरी देने से पहले, build, tests, स्टेजिंग deployment और smoke test से गुज़रती है, और पिछले वर्ज़न पर इमरजेंसी रोलबैक हाथ से शुरू किया जा सकता है। प्लेटफ़ॉर्म एक ऐसे container cluster पर चलता है जो कोड के रूप में परिभाषित है।
बैकअप हर घंटे होने लगे, और सबसे नया बैकअप शुरू से अंत तक पढ़ा गया, क्योंकि जिस बैकअप को कभी किसी ने पढ़ा ही नहीं, वह बैकअप नहीं है। Google की SRE किताब यह बात और दो टूक कहती है: “कोई भी असल में बैकअप बनाना नहीं चाहता; लोग असल में जो चाहते हैं, वह है restore।” वह इससे ऊँचा पैमाना भी रखती है: आप हाल की स्थिति वापस पा सकते हैं, यह आपको तभी पता चलता है जब आप सचमुच ऐसा करते हैं, इसलिए रिकवरी टेस्ट जहाँ भी संभव हो ऑटोमेट किए जाने चाहिए और लगातार चलने चाहिए। बैकअप को शुरू से अंत तक पढ़ना न्यूनतम शर्त है, मंज़िल नहीं।
ख़ुद बनाएँ या ख़रीदें: किसी भी AI डबिंग पाइपलाइन के लिए चेकलिस्ट
विफलता और फ़ॉलबैक
जब स्पीच प्रोवाइडर जॉब के बीच में विफल हो, तो श्रोता को क्या मिलता है: ख़ामोशी, अलग आवाज़, या विफल जॉब और रिफ़ंड? आउटेज के तय करने से पहले ख़ुद तय करें।
जब फ़ॉलबैक सचमुच चालू होता है, तो क्या वह एक लाइन बदलता है या स्पीकर का पूरा ट्रैक?
क्या फ़ॉलबैक पाथ को निर्धारित टेस्ट जॉब के साथ जान-बूझकर चलाया जाता है, या सिर्फ़ आउटेज के दौरान?
प्लेटफ़ॉर्म और बिलिंग
क्या हर AI प्रोवाइडर अपने गेटवे के पीछे है, ताकि मॉडल बदलना, key रोटेट करना या बायपास करना रिलीज़ न बने?
क्या भारी काम वेब रिक्वेस्ट के बाहर, हर सर्विस की सीमा वाली ड्यूरेबल क्यू से चलता है?
क्या लंबा अनुवाद चेकपॉइंट से आगे बढ़ सकता है, और क्या कनेक्शन टूटने के बाद बड़ा अपलोड वहीं से फिर शुरू हो सकता है?
क्या जॉब चलने से पहले क़ीमत या अनुमान दिखाया जाता है, और क्या यह पक्का है कि रिफ़ंड कभी दो बार नहीं होगा?
क्या मॉडरेशन रिक्वेस्ट पाथ से बाहर है, और क्या उसकी “समीक्षा में” जैसी स्पष्ट स्थिति है?
पहचान, टाइमिंग और आवाज़ें
क्या पहचान (recognition) को आपके अपने ऑडियो पर टेस्ट किया गया है: लहजे, बच्चे, अनौपचारिक बोली, कई स्पीकर, फ़िल्म और टॉक शो की आवाज़, सिर्फ़ ऑडियोबुक नहीं?
क्या आपकी WER स्कोरिंग ZWNJ की स्पेसिंग-चूक को पूरा ग़लत शब्द मानती है? पहले नॉर्मलाइज़ करें, या SW-WER जैसा weighted मेट्रिक इस्तेमाल करें।
डायराइज़ेशन के बाद, क्या हर पहचाने गए स्पीकर के पास लाइनें और आवाज़ है?
क्या रेंडरिंग से पहले सबटाइटल की समीक्षा और संपादन का कोई पड़ाव है?
इस कंटेंट के लिए टाइमिंग कितनी सख़्त होनी चाहिए: स्क्रीन पर चेहरे, या ऑफ़-स्क्रीन नैरेशन?
क्या फ़ारसी TTS को पूरे वाक्य मिलते हैं, न कि सबटाइटल के ऐसे टुकड़े जो इज़ाफ़त की शृंखला काट दें?
रिलीज़ और रिकवरी
क्या स्टेजिंग और smoke जाँचों के बाद कोई व्यक्ति प्रोडक्शन को मंज़ूरी देता है, और क्या आप हाथ से रोलबैक कर सकते हैं?
क्या किसी ने कभी कोई बैकअप शुरू से अंत तक पढ़ा है?
अगर आप स्पीच या डबिंग सिस्टम बनाने पर विचार कर रहे हैं, तो स्पीच AI सेवा TTS, ASR और डबिंग पाइपलाइन को कवर करती है, फ़ारसी के कठिन मामलों समेत।
अक्सर पूछे जाने वाले सवाल
AI डबिंग कैसे काम करती है?
AI डबिंग पाइपलाइन मूल स्पीच को ट्रांसक्राइब करती है और पहचानती है कि कौन बोल रहा है, हर लाइन का ऐसा अनुवाद करती है कि वह लगभग मूल समय में बोली जा सके, हर स्पीकर को एक अलग सिंथेटिक आवाज़ देती है, फिर टाइमिंग मिलाती है और नई स्पीच को मूल बैकग्राउंड के साथ मिक्स करती है। प्रोडक्शन में ये चरण एक ऐसे प्लेटफ़ॉर्म के भीतर चलते हैं जिसमें क्यू, फ़ॉलबैक वाले प्रोवाइडर गेटवे और, आदर्श रूप से, रेंडरिंग से पहले समीक्षा का एक पड़ाव होता है।
क्या AI अंग्रेज़ी वीडियो को फ़ारसी में डब कर सकता है?
तकनीकी रूप से, हाँ: किसी भी भाषा-जोड़ी के लिए शृंखला वही है। फ़ारसी में डबिंग आवाज़ वाले चरण में एक भाषा-विशेष समस्या जोड़ती है, क्योंकि लिपि ह्रस्व स्वर और इज़ाफ़त को लिखती ही नहीं, इसलिए उच्चारण का अनुमान संदर्भ से लगाना पड़ता है। मुख्यधारा की सेवाओं में समर्थन एक-सा नहीं है: सितंबर 2026 की स्थिति में, YouTube के automatic dubbing सहायता पेज पर फ़ारसी (Farsi) ऐसी स्रोत भाषा के रूप में दर्ज है जिसे अंग्रेज़ी में डब किया जाता है, और अंग्रेज़ी वीडियो जिन भाषाओं में डब किए जा सकते हैं, उनकी सूची में फ़ारसी नहीं है।
क्या AI डबिंग होंठों की हरकत से मेल खाती है?
ज़रूरी नहीं, और हमेशा इसकी ज़रूरत भी नहीं होती। आइसोक्रोनी पर शोध यही लक्ष्य रखता है: ऐसी नई स्पीच जो मूल वीडियो के साथ समय में मेल खाए, मुँह की हरकतों, ठहरावों और इशारों समेत। मेल कितना कसा हुआ हो, यह डिज़ाइन का चुनाव है। ऑफ़-स्क्रीन डबिंग को उस स्पीकर की डबिंग से कम सख़्त synchronisation चाहिए जिसका मुँह दिख रहा हो, और पेशेवर मानवीय डबिंग का एक बड़ा अध्ययन तर्क देता है कि आवाज़ की स्वाभाविकता और अनुवाद की गुणवत्ता उन लिप-सिंक शर्तों से ज़्यादा मायने रखती हैं जिन पर आम तौर पर ज़ोर दिया जाता है।
AI डब में कभी-कभी ख़ामोशी या अलग आवाज़ क्यों होती है?
एक कारण है जॉब के बीच में स्पीच प्रोवाइडर का विफल होना। एक ही प्रोवाइडर से बँधी पाइपलाइन आवाज़ों को एकरूप रखती है, पर आउटेज के दौरान ख़ाली जगहें छोड़ सकती है; फ़ॉलबैक शृंखला वाली पाइपलाइन लाइन को थोड़ी अलग आवाज़ से भर देती है। Booq पहले डिज़ाइन से दूसरे पर तब गया, जब एक आउटेज की वजह से ऐसे डब बने जिनमें छूटी हुई लाइनों की जगह ख़ामोशी थी। ख़ामोशी पहले के चरणों से भी शुरू हो सकती है, जब पहचान (recognition) किसी स्पीकर को छोड़ दे और अनुवाद के लिए कुछ बचे ही नहीं।
फ़ारसी स्पीच रिकग्निशन का मूल्यांकन कैसे करें?
अपने ख़ुद के ऑडियो पर, सिर्फ़ साफ़ पढ़ी गई स्पीच पर नहीं। क्षेत्रीय लहजे, बच्चों की आवाज़ें, कई स्पीकर और फ़िल्म या टॉक शो की आवाज़ शामिल करें, ये सभी ऐसी स्थितियाँ हैं जिनमें PSRB को ज़्यादा ग़लतियाँ मिलीं, और साथ में अनौपचारिक बोली भी। स्कोरिंग से पहले ZWNJ और Yeh व Kaf अक्षरों के अरबी और फ़ारसी रूपों को नॉर्मलाइज़ करें, या SW-WER जैसा substitution-weighted मेट्रिक इस्तेमाल करें, और सिर्फ़ दर नहीं, ग़लतियाँ भी पढ़ें: एक संख्या स्पेसिंग की चूक और उस धाराप्रवाह वाक्य में फ़र्क़ नहीं करती जो स्पीकर ने कभी कहा ही नहीं।
स्रोत
Booq: फ़ारसी-प्रथम AI वीडियो अनुवाद और डबिंग, इसी साइट पर केस स्टडी
MCI के लिए फ़ारसी टेक्स्ट-टू-स्पीच शोध, इसी साइट पर केस स्टडी
Sedghiyeh et al., PSRB: A Comprehensive Benchmark for Evaluating Persian ASR Systems, arXiv, 2025 (पूरा टेक्स्ट)
Federico et al., From Speech-to-Speech Translation to Automatic Dubbing, arXiv, 2020
Chronopoulou et al., Jointly Optimizing Translations and Speech Timing to Improve Isochrony in Automatic Dubbing, arXiv, 2023
Lakew et al., Isometric MT: Neural Machine Translation for Automatic Dubbing, ICASSP 2022
Virkar et al., Prosodic Alignment for off-screen automatic dubbing, arXiv, 2022
Brannon, Virkar और Thompson, Dubbing in Practice: A Large Scale Study of Human Localization With Insights for Automatic Dubbing, TACL, 2023
YouTube Help, Use automatic dubbing, सितंबर 2026 में जाँचा गया
Park et al., A Review of Speaker Diarization: Recent Advances with Deep Learning, Computer Speech & Language, 2022
Ryant et al., The Third DIHARD Diarization Challenge, arXiv, 2020
Rahmati और Sameti, GE2PE: Persian End-to-End Grapheme-to-Phoneme Conversion, Findings of EMNLP 2024
Doostmohammadi et al., Persian Ezafe Recognition Using Transformers and Its Role in Part-Of-Speech Tagging, arXiv, 2020
Ranjbar Kalahroodi, Faili और Shakery, ParsVoice: A Large-Scale Multi-Speaker Persian Speech Corpus for Text-to-Speech Synthesis, EMNLP 2026 (स्वीकृत; arXiv v4, सितंबर 2026)
Google, Site Reliability Engineering: Addressing Cascading Failures
Google, Site Reliability Engineering: Data Integrity: What You Read Is What You Wrote
IETF HTTP Working Group, Resumable Uploads for HTTP, Internet-Draft
Pete Hodgson, Feature Toggles (aka Feature Flags), martinfowler.com, 2016, संशोधित 2017