ASS को SRT में बदलें

दो चीज़ें बचती हैं: हर डायलॉग लाइन का टेक्स्ट और वह पल जब वह शुरू और ख़त्म होती है। बाक़ी सब उस फ़ॉर्मेट की चीज़ है जिसे आप छोड़ रहे हैं। स्टाइल टेबल, फ़ॉन्ट नाम, primary और outline रंग, alignment, margins, per-line override, fade, move और karaoke टाइमिंग — इनमें से किसी के लिए SubRip में जगह ही नहीं है।

रजिस्ट्री इस जोड़ी को lossless नहीं बल्कि approximate कहती है, और यह सही लेबल है। ASS एक ऐसा फ़ाइल फेंकता है जिसकी वजह से किसी ने वह फ़ॉर्मेट चुना था, और यह काम मूल की एक नक़ल पर करना चाहिए, सीधे उस पर नहीं।

घुँघराली ब्रैकेट के बीच सब कुछ हटा दिया जाता है। पोज़िशनिंग टैग, बीच वाक्य में रंग बदलाव, fade, rotation, blur — सब साफ़ ग़ायब हो जाते हैं, बजाय इसके कि स्क्रीन पर अक्षरों के रूप में दिखें, जो तब होता जब फ़ाइल का सिर्फ़ नाम बदला जाता।

दो एस्केप हटाए नहीं, अनुवादित होते हैं। हार्ड लाइन ब्रेक — बैकस्लैश और बड़ा N — असली नई पंक्ति बन जाता है ताकि दो-लाइन वाली सबटाइटल दो लाइन ही रहे। हार्ड स्पेस साधारण स्पेस बन जाता है।

Typesetters ASS में आकृतियाँ बनाते हैं — अनूदित साइन के पीछे एक बॉक्स, मास्क, या तीर। ड्रॉइंग एक ब्रैकेट वाले टैग से चालू होती है, और उसके बाद के coordinates डायलॉग टेक्स्ट में साधारण अक्षरों की तरह बैठे रहते हैं। सिर्फ़ टैग ब्रैकेट में है, सिर्फ़ वही हटता है।

SRT में जो पहुँचता है वह अक्षरों और अंकों की एक लड़ी जैसा दिखता है — ड्रॉइंग कमांड्स ख़ुद। जब दिखे तो पहचानना आसान है। ऐसी कतारें ढूँढकर हटा दीजिए — भारी typeset किए release पर कई दर्जन हो सकती हैं।

ASS में karaoke हर syllable से पहले एक टैग है जो बताता है वह कितनी देर टिकेगी, जिससे प्लेयर गाते-गाते लाइन हाइलाइट कर सके। टैग ब्रैकेट में हैं, इसलिए हटते हैं, और बीच के syllable एक साधारण लाइन में जुड़ जाते हैं।

नतीजा सही और निराशाजनक दोनों है — पूरा गीत लाइन के शुरू में दिखता है और अंत में ग़ायब होता है, किसी दूसरी सबटाइटल की तरह। कुछ भी ग़लत टाइम नहीं होता, बस effect ही नहीं रहता। अगर karaoke ही मक़सद था तो यह जवाब नहीं है।

ASS फ़ाइल में अक्सर एक साथ कई लाइनें दिखती हैं, अलग-अलग layer पर — नीचे डायलॉग और उसके ऊपर वह चीज़ अनुदित करता साइन। यह सामान्य है और यही फ़ॉर्मेट का काम है।

SubRip में न layer है न position, इसलिए दोनों लाइनें एक ही सेकंड को ढकती कतारें बन जाती हैं। ओवरलैपिंग कतारें अवैध नहीं, पर व्यवहार अलग-अलग प्लेयर में अलग होता है। किसी प्लेटफ़ॉर्म को डिलीवर करते समय डायलॉग ही रखना बेहतर है।

events section में Dialogue लाइनें होती हैं और अक्सर Comment भी — संरचनात्मक रूप से एक जैसी पर बंद। सिर्फ़ Dialogue पढ़ी जाती है, इसलिए Comment SRT तक नहीं पहुँचती। अगर कोई लाइन कम मिल रही है, ASS खोलकर देखिए कि वह Comment तो नहीं है।

यह भी वजह है कि बदली गई फ़ाइल कभी-कभी सोचे से छोटी होती है। समीक्षा से गुज़रा अनुवाद उतने ही कमेंटेड विकल्प रख सकता है जितनी live लाइनें, और Dialogue लाइनों की गिनती करना असली संकेत देता है।

events section अपना कॉलम क्रम एक Format लाइन में घोषित करता है, और असली फ़ाइलें सच में अलग-अलग होती हैं — क्रम एक निश्चित नियम नहीं, एक परंपरा है। कॉलम इसी नाम से ढूँढे जाते हैं, इसलिए असामान्य लेआउट वाली फ़ाइल भी सही पढ़ी जाती है।

टेक्स्ट कॉलम को उसकी जगह से लाइन के अंत तक माना जाता है, जो मायने रखता है क्योंकि कॉमा वाला डायलॉग वरना पहले कॉमा पर कट जाता।

कतारें events section में जिस क्रम में हैं उसी हिसाब से एक से गिनी जाती हैं। Aegisub अक्सर उस सेक्शन को समय के अनुसार क्रमबद्ध रखता है, इसलिए ज़्यादातर फ़ाइलें कालानुक्रमिक निकलती हैं।

भारी typeset की गई स्क्रिप्ट अपवाद है। कोई साइन दृश्य पर काम करते वक़्त उससे जुड़ी लाइन के पास जुड़ जाता है, न कि टाइमलाइन में अपनी जगह पर, और SRT में कतारें उलटे क्रम में दिखती हैं। Aegisub में events को शुरुआती समय से क्रमबद्ध करना यह टाल देता है।

जो हटाया गया वह आउटपुट से वापस नहीं मिल सकता। SRT को नहीं पता कौन-सी लाइनें साइन थीं, स्पीकर का रंग क्या था, कैप्शन कहाँ बैठा था या syllable कैसे टाइम हुआ, और बाद का कोई काम इसे दोबारा नहीं बना सकता।

काम करने का तरीक़ा वही है जो release group पहले से इस्तेमाल करते हैं — ASS प्रोजेक्ट है, हर सादी फ़ाइल एक निर्यात। अनुवाद बदले तो ASS में बदलिए और फिर बदलिए; समानांतर बदली दो फ़ाइलें जल्दी अलग हो जाती हैं।