सबटाइटल लाइन एंडिंग बदलें
या सबटाइटल टेक्स्ट पेस्ट करें
विकल्प
फ़ाइल की हर पंक्ति या तो एक अदृश्य अक्षर (LF) पर या दो (CRLF) पर खत्म होती है। प्लेयर, एडिटर और सबटाइटल टूल सभी दोनों पढ़ते हैं, इसलिए सबटाइटल फ़ाइल के बिगड़ने की वजह लगभग कभी यह नहीं होती — जब होती है तो दो वजहें: कोई बिल्ड पाइपलाइन या सख़्त पार्सर जो दूसरी अस्वीकार करता है, और कोई तुलना टूल जो अंत अलग होने से हर पंक्ति बदली हुई दिखाता है। यहाँ डिफ़ॉल्ट LF है क्योंकि Unix, macOS और वेब इसी का इस्तेमाल करते हैं, और जिस फ़ाइल में पहले से यह है वह अछूती रहती है। CRLF चुनने पर मौजूद दोनों तरह के अंत बदलते हैं, इसलिए मिली-जुली फ़ाइल एक जैसी बनकर निकलती है।
टाइमिंग किस फ़्रेम रेट में गिनी गई है। फ़ॉर्मैट पेजों पर यही MicroDVD को चाहिए, क्योंकि वह टाइमिंग फ़्रेम संख्याओं में रखता है। फ़्रेम रेट पेजों पर यह वह रेट है जिसके हिसाब से फ़ाइल की टाइमिंग की गई थी — वह संस्करण जिसके लिए सबटाइटल बने थे — और पेज का दूसरा बॉक्स उस वीडियो का रेट लेता है जिसके साथ आप इन्हें इस्तेमाल करेंगे। 23.976, 24, 25, 29.97, 30, 50, 59.94 और 60 आम हैं। गलत होने पर पूरी टाइमलाइन खिसक जाती है, और फ़्रेम रेट पेजों पर वह एक अनुपात से खिसकती है, तय मात्रा से नहीं।
यह पेज सबटाइटल फ़ाइल के लाइन एंडिंग बदलता है — LF और CRLF के बीच — ताकि फ़ाइल उस सिस्टम पर ठीक खुले जिसके लिए वह जा रही है। पाठ, टाइमकोड, क्यू का क्रम और एनकोडिंग वैसे ही रहते हैं; केवल वह बाइट-जोड़ी बदलती है जो हर पंक्ति के अंत को बताती है। यह उन फ़ाइलों के लिए है जो एक प्लेटफ़ॉर्म पर बनीं और दूसरे पर पढ़ी जा रही हैं।
फ़र्क़ छोटा दिखता है पर असर साफ़ होता है। LF यानी एक बाइट, जो यूनिक्स, मैक और अधिकतर आधुनिक टूल इस्तेमाल करते हैं। CRLF यानी दो बाइट, जो विंडोज़ और कुछ प्रसारण तंत्र मानते हैं। जो टूल दोनों नहीं पढ़ता वह पूरी फ़ाइल को एक पंक्ति मान सकता है — क्यू-नंबर, टाइमकोड और टेक्स्ट सब एक ही पंक्ति में — या हर पंक्ति के अंत में अदृश्य चिह्न दिखा सकता है। दोनों ही हालत में फ़ाइल का अर्थ नहीं बदलता, पर उसका पढ़ा जाना बदल जाता है।
यह पेज मिश्रित एंडिंग को भी सामान्य करता है। जो फ़ाइल आधी किसी दौर से और आधी किसी और से गुज़री हो, उसमें LF और CRLF दोनों हो सकते हैं, और कुछ जगह अकेला CR भी; सबको एक ही चुनी हुई एंडिंग में बदल दिया जाता है। खाली पंक्तियाँ — जो क्यू के बीच के विराम हैं — भी उसी नियम से बदलती हैं, क्योंकि वे भी पंक्ति हैं; उन्हें छोड़ देने से फ़ाइल में दो तरह की एंडिंग बच जाती और समस्या आधी रह जाती।
एनकोडिंग इस पेज पर नहीं बदलती — अगर फ़ाइल UTF-8 थी तो UTF-8 ही रहेगी — और BOM भी जस का तस रहता है। कुछ अपलोड नहीं होता, और जिस फ़ाइल में पहले से वही एंडिंग है जो आपने चुनी वह बाइट-दर-बाइट वैसी ही लौटती है।
उदाहरण
LF फ़ाइल को CRLF में बदलना
इनपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
आउटपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
हर पंक्ति के अंत में एक अतिरिक्त बाइट जुड़ता है, इसलिए फ़ाइल थोड़ी बड़ी हो जाती है और विंडोज़-केंद्रित टूल उसे ठीक पढ़ते हैं। पाठ और टाइमकोड में कुछ नहीं बदलता; पाठक में दोनों फ़ाइलें एक जैसी दिखती हैं, क्योंकि पाठक एंडिंग को दिखाता नहीं।
CRLF फ़ाइल को LF में बदलना
इनपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
आउटपुट
1
00:00:01,000 --> 00:00:02,000
The room is dark.
हर पंक्ति के अंत से एक बाइट हटता है और फ़ाइल थोड़ी छोटी हो जाती है। यह वही बदलाव है जो यूनिक्स, मैक और अधिकतर आधुनिक टूल मानते हैं। अगर पहले टूल फ़ाइल को एक ही लंबी पंक्ति दिखा रहा था, तो अब वह सही ढाँचे में खुलेगी।
मिश्रित एंडिंग वाली फ़ाइल
इनपुट
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
आउटपुट
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
जहाँ CRLF थे वहाँ LF बनते हैं और जहाँ अकेला CR था वहाँ भी LF — पूरी फ़ाइल एक ही एंडिंग पर आ जाती है, जिससे आगे के टूल को दो व्यवहारों से नहीं लड़ना पड़ता। यही मिश्रित फ़ाइल का असली इलाज है: किसी एक हिस्से को बदलना बाकी समस्या को छिपा देता है।
अक्सर पूछे जाने वाले सवाल
सबटाइटल के लाइन एंडिंग बदलने वाला यह पेज LF और CRLF में से क्या चुनने देता है?
दोनों। आप या तो LF चुन सकते हैं, या CRLF; फ़ाइल का हर पंक्ति अंत उसी में बदल जाता है। LF एक बाइट है और यूनिक्स, मैक तथा अधिकतर आधुनिक टूल का मानक है; CRLF दो बाइट हैं और विंडोज़ तथा कुछ प्रसारण तंत्र का। पाठ, टाइमकोड, क्यू का क्रम और एनकोडिंग नहीं बदलते — केवल पंक्ति अंत का बाइट-रूप बदलता है।
मिश्रित एंडिंग वाली फ़ाइल का क्या होता है?
सब एक ही चुनी हुई एंडिंग में बदल जाती हैं। अगर फ़ाइल में कहीं LF, कहीं CRLF और कहीं अकेला CR था, तो नतीजे में तीनों एक जैसे हो जाते हैं। यह जानबूझकर है: मिश्रित फ़ाइलें अक्सर कई दौरों से गुज़रने पर बनती हैं और कुछ टूल उन्हें अलग-अलग पढ़ते हैं, जिससे कुछ क्यू ठीक और कुछ बिगड़े दिखते हैं। एकरूपता वह आधार है जिस पर आगे के दौर भरोसा कर सकते हैं।
क्या यह पेज एनकोडिंग भी बदलता है?
नहीं। लाइन एंडिंग और कैरेक्टर एनकोडिंग अलग-अलग चीज़ें हैं; यह पेज केवल पहली छूता है। फ़ाइल जिस एनकोडिंग में थी उसी में रहेगी, और BOM भी जस का तस रहेगा — अगर फ़ाइल UTF-8 BOM वाली थी तो वह बनी रहेगी। दोनों बदलने के लिए दोनों पेज अलग-अलग चलाएँ; क्रम मायने नहीं रखता, पर अलग चलाने से हर बदलाव का नतीजा देखा जा सकता है।
लाइन एंडिंग बदलने से फ़ाइल का आकार कितना बदलता है?
हर पंक्ति पर एक बाइट का फ़र्क़: LF से CRLF में हर पंक्ति पर एक बाइट जुड़ती है, CRLF से LF में एक बाइट हटती है। इसलिए फ़ाइल जितनी पंक्तियों की है उतनी बाइट बढ़ेगी या घटेगी, जिसमें क्यू के बीच की खाली पंक्तियाँ भी शामिल हैं। यह छोटा बदलाव है, पर चेकसम या आकार पर निर्भर तंत्रों के लिए असली फ़र्क़ है।
क्या खाली पंक्तियाँ भी बदलती हैं?
हाँ। क्यू के बीच की खाली पंक्तियाँ भी पंक्तियाँ हैं, इसलिए उनके अंत भी उसी एंडिंग में बदलते हैं। अगर उन्हें छोड़ दिया जाए तो फ़ाइल में दो तरह की एंडिंग बच जाती और कुछ टूल फिर भी पूरी फ़ाइल को अलग तरह पढ़ सकते थे। यही वजह है कि नतीजे में फ़ाइल पूरी तरह एकरूप होती है, न कि केवल दिखने वाली पंक्तियों पर।
मुझे LF चुनना चाहिए या CRLF?
जो आपका अगला टूल माँगता है। अगर फ़ाइल किसी वेब प्लेटफ़ॉर्म, मैक या लिनक्स टूल में जा रही है तो LF सामान्य है; अगर विंडोज़-केंद्रित सॉफ़्टवेयर या कुछ प्रसारण तंत्र में जा रही है तो CRLF। अगर पता न हो तो LF आज सबसे व्यापक रूप से पढ़ा जाता है, और अधिकतर आधुनिक टूल दोनों पढ़ लेते हैं — समस्या अधिकतर उन पुराने टूल पर आती है जो केवल एक ही मानते हैं।