لائیو ترجمے میں زیادہ تر تاخیر انتظار کی وجہ سے ہوتی ہے: اسٹریم کا، اگلے لفظ کا، اور جملے کا۔ جس حصے پر آپ واقعی قابو رکھ سکتے ہیں وہ لیٹنسی موڈ ہے: کم تاخیر، یا کم ترمیمات۔
لائیو ترجمہ پڑھنے والا سامع ہر سطر کو اسپیکر کے بولنے کے چند سیکنڈ بعد دیکھتا ہے۔ یہ فاصلہ ایک نہیں بلکہ کئی تاخیروں کا مجموعہ ہے، جو ایک زنجیر کی صورت میں جمع ہوتی ہیں، اور ان میں سے زیادہ تر دراصل انتظار ہی کی ایک شکل ہیں۔ یہ جاننا کہ کون سا انتظار کس وجہ سے ہے، لیٹنسی موڈ کا انتخاب آسان بنا دیتا ہے، اور یہ بھی بتاتا ہے کہ ریڈر بنانے والا ڈیولپر کیا دکھائے اور کب دکھائے۔
اعداد سے پہلے ایک مفید پیمانہ: ایک ہم وقت ترجمان عموماً اسپیکر سے دو سے چار سیکنڈ پیچھے بولتا ہے۔ ترجمان اس فاصلے کو "ear-voice span" کہتے ہیں، اور فعل آخر میں آنے والی زبانوں سے وہ فعل کا انتظار کرنے کے بجائے اس کا اندازہ لگا کر، یا جملے کو ایسے ٹکڑوں میں بانٹ کر نمٹتے ہیں جو اپنے طور پر مکمل ہوں۔ ایک یا دو سیکنڈ کی تاخیر سافٹ ویئر کا کوئی نقص نہیں؛ یہ تقریباً وہی ہے جو ایک بہت اچھا انسان بھی کرتا ہے۔
VocalStack پر ہر لائیو ٹرانسکرپشن انہی مراحل سے، انہی کی ترتیب میں گزرتی ہے، اور ہر مرحلہ اپنے سے پہلے والے کا انتظار کرتا ہے۔
اصل زبان کا متن قاری تک تقریباً اسی وقت پہنچتا ہے جب وہ بولا جا رہا ہو۔ ترجمہ ایک یا دو سیکنڈ بعد آتا ہے، اور بولا گیا جملہ اپنے ترجمے کے بعد آتا ہے، اسی لیے آواز کا کلپ ہمیشہ سب سے آخر میں پہنچتا ہے۔ زنجیر کا پہلا نظر آنے والا اثر تاہم کسی بھی آواز سے بہت پہلے ظاہر ہوتا ہے: خود متن حرکت کرنے لگتا ہے۔
لائیو ٹرانسکرپٹ میں لوگ سب سے پہلے یہ نوٹ کرتے ہیں کہ تازہ ترین الفاظ حرکت کرتے ہیں۔ ایک فقرہ ظاہر ہوتا ہے، بدلتا ہے، اور پھر ٹھہر جاتا ہے۔ یہ ڈرافٹ مرحلے کا کام ہے، اور اس کا ایک ایسا سبب ہے جو ہر اسپیچ ریکگنائزر پر لاگو ہوتا ہے۔
ریکگنائزر کسی لفظ کو اس کے بعد آنے والی آواز دیکھ کر طے کرتا ہے۔ "I scream" اور "ice cream" اگلا لفظ آنے تک ایک جیسے سنائی دیتے ہیں؛ آخر میں آنے والا "s" اس لفظ کا بھی ہو سکتا ہے اور اگلے لفظ کا بھی۔ جب تک کسی لفظ کے دائیں جانب آواز موجود نہ ہو، اس کی ہجے محض اندازہ ہوتی ہے، اس لیے کسی بھی لائیو ٹرانسکرپٹ کے تازہ ترین الفاظ ہمیشہ سب سے کم یقینی ہوتے ہیں۔ ڈرافٹ دراصل وہی اندازہ ہے جو چھپانے کے بجائے جلدی دکھا دیا جاتا ہے۔
ہر ڈرافٹ لائیو ٹیل کو مکمل طور پر بدل دیتا ہے: یعنی آخری کمٹ کے بعد سنے گئے وہ الفاظ جو ابھی بدل رہے ہیں۔ کمٹ حتمی ہوتا ہے۔ وہ کبھی نہیں بدلتا، اس کے ساتھ لفظ سطح کے وقت ہوتے ہیں، اور کمٹس بغیر کسی خلا کے نمبر دیے جاتے ہیں تاکہ قاری پہچان سکے کہ اس نے کوئی کمٹ چھوڑ تو نہیں دیا۔
ڈیولپر کے لیے یہ وہ ایک اصول ہے جس پر ریئل ٹائم API اصرار کرتا ہے: ہر کمٹ شدہ حصہ دکھائیں، پھر اس کے بعد تازہ ترین ڈرافٹ، اور جب کوئی کمٹ آئے تو ڈرافٹ صاف کر دیں۔ ڈرافٹس کو بدلنے کے بجائے ان کے ساتھ جوڑتے جانے سے متن دہرا اور جھلملاتا ہوا بنتا ہے؛ کمٹ بس دُم کو کھا جاتا ہے۔ WebSocket ٹیوٹوریل ایک ریڈر اسی بنیاد پر بناتا ہے۔
میزبان کے لیے متن کا حرکت کرنا کم تاخیر کی قیمت ہے۔ فقرہ مکمل ہونے سے پہلے الفاظ دکھانا ہی ٹرانسکرپٹ کو لائیو محسوس کراتا ہے۔ تاہم ترجمہ یہ چال برداشت نہیں کر سکتا، کیونکہ ایک لفظ آدھے فقرے سے اندازہ کیا جا سکتا ہے، لیکن ترجمہ نہیں۔
الفاظ کی ترتیب ہی وجہ ہے کہ ترجمہ ڈرافٹ کے ساتھ قدم نہیں رکھ سکتا۔ جرمن میں فعل شق کے آخر میں آ سکتا ہے، اور جاپانی فعل کو آخر میں رکھتی ہے۔ کسی بھی مترجم کو امانت داری سے ترجمہ کرنے کے لیے پوری شق درکار ہوتی ہے۔ لفظ بہ لفظ ترجمہ سامع کو ایسے ٹکڑے دیتا ہے جنہیں شق مکمل ہونے پر ازسرِنو بدلنا پڑتا ہے۔ جرمن نے ترجمانوں کو سافٹ ویئر کی کوشش سے بہت پہلے سے فعل کا انتظار کرنے پر مجبور کیا ہے۔
اس لیے VocalStack حصوں کے بجائے جملوں کا ترجمہ کرتا ہے۔ Sentences بطور ڈیفالٹ آن ہوتے ہیں، اور ان کے آن ہونے پر سرور کمٹس کو ایک جملے میں جوڑ کر پورے جملے کا ترجمہ کرتا ہے۔ جب تک جملہ کھلا ہے، اس کا ترجمہ عارضی رہتا ہے؛ بند ہونے پر ترجمہ حتمی ہو جاتا ہے۔ ریڈر ہر جملے کے لیے ایک اندراج رکھتا ہے اور اپ ڈیٹس آنے پر اسے بدل دیتا ہے۔
آواز کا انتظار اور بھی طویل ہوتا ہے۔ صرف بند جملہ بولا جاتا ہے، کیونکہ وہ جملہ جو ابھی بدل رہا ہو، ہر ترمیم پر دوبارہ تیار کرنا پڑتا۔ لمبے جملے کو ٹکڑوں میں آواز دی جاتی ہے، تاکہ باقی ٹکڑے بنتے ہوئے پہلا ٹکڑا چل سکے۔
جملے بند ہونے پر ہر کمٹ کو اس کا اپنا ترجمے کا فریم ملتا ہے۔ یہ راستہ کسی چیز کا انتظار نہیں کرتا، لیکن پورے جملے کہیں بہتر پڑھے جاتے ہیں۔
یہ تمام انتظار اس لمحے سے ناپے جاتے ہیں جب آڈیو 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 پر چلے جائیں، جو فاصلہ بند ہونے تک کچھ درستگی کے بدلے رفتار دیتا ہے۔
ڈیولپرز اس کے بجائے ایک ہی عدد لیتے ہیں۔ جب ریئل ٹائم سیشن ختم ہوتا ہے تو session.done میں stats.realtimeFactor ہوتا ہے، یعنی ٹرانسکرائب شدہ آڈیو کو اس کی ٹرانسکرپشن پر صرف ہونے والے وقت سے تقسیم کیا گیا عدد۔ ایک کنونشن کی انتباہ: اسپیچ ریکگنیشن کے لٹریچر میں real-time factor عموماً اس کا الٹ ہوتا ہے، یعنی پروسیسنگ کا وقت آڈیو کے وقت پر، جہاں کم بہتر ہے۔ VocalStack اسے الٹے رخ پر رپورٹ کرتا ہے، اس لیے یہاں زیادہ بہتر ہے: لائیو سیشن 1 کے قریب رہتا ہے، اور 1 سے نیچے کا مطلب ہے کہ آڈیو اس سے تیز پہنچا جتنی تیزی سے پائپ لائن اسے ٹرانسکرائب کر سکتی تھی۔
ان میں سے کوئی سیکنڈ پراسرار نہیں۔ کچھ اسٹریم کے ہیں، کچھ ایک لفظ کے اگلے لفظ کا انتظار کرنے کے، کچھ اس جملے کے جس کا ترجمہ درکار ہوتا ہے، اور باقی آپ کے منتخب کردہ لیٹنسی موڈ کے۔ API ریفرنس میں فریم بہ فریم تفصیل ہے، اور ہوم پیج کا ڈیمو زنجیر کو چلتا ہوا دکھاتا ہے۔
