शुरू से पहले खत्म होने वाले सबटाइटल
या सबटाइटल टेक्स्ट पेस्ट करें
विकल्प
टाइमिंग किस फ़्रेम रेट में गिनी गई है। फ़ॉर्मैट पेजों पर यही MicroDVD को चाहिए, क्योंकि वह टाइमिंग फ़्रेम संख्याओं में रखता है। फ़्रेम रेट पेजों पर यह वह रेट है जिसके हिसाब से फ़ाइल की टाइमिंग की गई थी — वह संस्करण जिसके लिए सबटाइटल बने थे — और पेज का दूसरा बॉक्स उस वीडियो का रेट लेता है जिसके साथ आप इन्हें इस्तेमाल करेंगे। 23.976, 24, 25, 29.97, 30, 50, 59.94 और 60 आम हैं। गलत होने पर पूरी टाइमलाइन खिसक जाती है, और फ़्रेम रेट पेजों पर वह एक अनुपात से खिसकती है, तय मात्रा से नहीं।
शुरू से पहले खत्म होता क्यू ऐसा टाइमकोड है जो सच हो ही नहीं सकता: 00:00:03,000 --> 00:00:03,000, या उससे भी बुरा, शुरू से पहले वाला अंत। यह पेज उन फ़ाइलों की रिपोर्ट देता है जिनमें ऐसा था, उन मरम्मतों से गिनकर जो पाठक को करनी पड़ीं, क्योंकि इस आकार का टाइमकोड मेमोरी में रखा ही नहीं जा सकता और बाकी कुछ होने से पहले उसे असली टाइमकोड से बदल दिया जाता है। नतीजा रिपोर्ट है, बदली हुई फ़ाइल कभी नहीं।
इसीलिए रिपोर्ट पहले यह बताती है कि पढ़ते समय क्या खोया, और उसके बाद निष्कर्ष दिखाती है। जिस क्यू का अंत उसके शुरू के बाद नहीं है उसे एक मिलीसेकंड दिया जाता है ताकि बाकी फ़ाइल पढ़ी, देखी और निर्यात की जा सके; उन मरम्मतों की गिनती रिपोर्ट हेडर में बैठती है, और नीचे का निष्कर्ष बिना क्यू नंबर के एक त्रुटि कहता है, क्योंकि मरम्मतें सूची में रखने की जगह पढ़ते समय गिनी जाती हैं। दोनों पंक्तियाँ उसी टूटे टाइमकोड का दो तरफ़ से वर्णन हैं, इसीलिए उन्हें दो में नहीं, एक ही रिपोर्ट में होना चाहिए।
इस पेज को जिस जाल के इर्द-गिर्द लिखना पड़ा वह यह है कि जायज़ एक-मिलीसेकंड क्यू मरम्मत किए गए क्यू जैसा ही दिखता है। इसलिए जाँच अवधि को देखती ही नहीं — वह मरम्मतों के रिकॉर्ड को देखती है — और सचमुच एक मिलीसेकंड चलने वाला क्यू अछूता रहता है। ऋणात्मक अवधि और शून्य-लंबाई एक ही दोष हैं और साथ गिने जाते हैं। दो फ़ॉर्मैट बिल्कुल स्वीकार नहीं हैं, और इस बार वजह दोनों तरफ़ एक ही है: LRC हर अंत अगले टाइमस्टैम्प से निकालता है, इसलिए वहाँ जोड़ी कभी उलटी नहीं निकल सकती, और plain text में क्यू समय ही नहीं। किसी की भी जाँच करना उस क्षेत्र के बारे में साफ़ रिपोर्ट देता जो फ़ॉर्मैट में है ही नहीं, और यह जवाब के न होने से भी बुरा जवाब है।
उदाहरण
बिना अवधि वाला क्यू
सबटाइटल
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
रिपोर्ट क्या पाती है
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
अंत अपने शुरू के बराबर। पाठक क्यू को एक मिलीसेकंड देता है ताकि फ़ाइल रखी जा सके, मरम्मत दर्ज करता है, और रिपोर्ट दोनों आधे छापती है: हेडर में खोने वाली पंक्ति और नीचे एक त्रुटि। मरम्मत सबूत है; मिलीसेकंड सिर्फ़ वह आकार है जो सबूत लेता है।
सचमुच एक मिलीसेकंड चलने वाला क्यू
सबटाइटल
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
रिपोर्ट क्या पाती है
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
हाथ से एक-मिलीसेकंड क्यू के रूप में लिखा गया और सूचीबद्ध नहीं। यही फ़ैसला जाँच का आकार बनाता है: मरम्मत किया गया शून्य-लंबाई क्यू भी एक मिलीसेकंड के रूप में निकलता है, इसलिए यहाँ छोटी अवधियों को चिह्नित करने वाला नियम टूटे टाइमकोड वाली हर फ़ाइल को असंभव-रूप से छोटे क्यू से भरी फ़ाइल कह देता।
अंत शुरू से पहले है
सबटाइटल
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
रिपोर्ट क्या पाती है
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
पाँच सेकंड से दो सेकंड: शून्य-लंबाई वाले मामले का ही दोष, उसी नियम से गिना गया, और बिल्कुल वैसे ही सूचीबद्ध। फ़ाइल में कुछ भी दोबारा नहीं लिखा जाता — मरम्मत किए गए समय पाठक की प्रति में हैं ताकि बाकी फ़ाइल संसाधित हो सके, वे कोई ऐसा सुधार नहीं जो यह पेज दे रहा हो।
अक्सर पूछे जाने वाले सवाल
शुरू से पहले खत्म होता क्यू किसे माना जाता है?
ऐसा अंत समय जो शुरू समय के बाद नहीं है: या तो उसके बराबर, जैसे 00:00:03,000 से 00:00:03,000, या उससे पहले, जैसे 00:00:05,000 से 00:00:02,000। दोनों एक ही दोष हैं और साथ गिने जाते हैं, और दोनों क्यू से नहीं, पाठक की मरम्मत से गिने जाते हैं, क्योंकि इस आकार का टाइमकोड मेमोरी में रखा ही नहीं जा सकता।
रिपोर्ट शामिल क्यू के नाम क्यों नहीं बताती?
क्योंकि ये मरम्मतें फ़ाइल पढ़ते समय गिनी जाती हैं, सूची में इकट्ठी नहीं की जातीं। रिपोर्ट गिनती देती है — एक त्रुटि, हेडर की खोई-पंक्ति में एक मद — और दोनों आधे उसी तथ्य को हेडर से और निष्कर्षों से देखते हैं। अगर ठीक क्यू चाहिए, तो क्यू नंबर की जगह उसके टाइमकोड की गिनती के लिए फ़ाइल खोजें।
एक मिलीसेकंड चलने वाला क्यू समस्या है?
यहाँ नहीं, और जानबूझकर नहीं। हाथ से लिखा एक-मिलीसेकंड क्यू जायज़ है और सूचीबद्ध नहीं होता; जो सूचीबद्ध होता है वह मरम्मत करना पड़ा टाइमकोड है, जो बाद में एक मिलीसेकंड के रूप में रखा जाता है। मरम्मत की जगह अवधि जाँचना शून्य-लंबाई क्यू वाली हर फ़ाइल को असंभव-रूप से छोटे क्यू से भरी फ़ाइल बता देता, जो दो बार ग़लत निष्कर्ष है।
क्या यह पेज मिले टाइमकोड ठीक कर देता है?
नहीं। मरम्मत किए गए समय सिर्फ़ ब्राउज़र के अंदर हैं ताकि बाकी फ़ाइल पढ़ी और उसकी रिपोर्ट दी जा सके। आपने जो फ़ाइल डाउनलोड की या डाली वह अपरिवर्तित है, और इस पेज से मरम्मत किया संस्करण सहेजने का कोई रास्ता नहीं — टूटे टाइमकोड को बदलना ऐसा ऑपरेशन है जिसका उत्पाद सबटाइटल फ़ाइल होता है, जाँच नहीं।
शुरू से पहले खत्म होते क्यू की जाँच किन सबटाइटल फ़ॉर्मैट पर हो सकती है?
बारह में से दस पर: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON और CSV। दो ग़ायब हैं और कोई भी चूक नहीं। LRC हर पंक्ति पर एक समय रखता है और पाठक हर अंत अगले टाइमस्टैम्प से निकालता है, इसलिए वहाँ जोड़ी कभी उलटी नहीं हो सकती — जाँच उस क्षेत्र को आँक रही होगी जो फ़ॉर्मैट में नहीं है। plain text में क्यू समय ही नहीं। अगर आपकी फ़ाइल उन दोनों में है तो पहले बदलें।
ये टूटे टाइमकोड कहीं ख़ास से आते हैं?
वे लगभग हमेशा बनते हैं, टाइप नहीं होते। ऐसा फ़्रेम-रेट रूपांतरण जो ग़लत दिशा में राउंड करता है, एक ही क्यू पर दो बार लगाया गया शिफ़्ट, ऐसा स्प्रेडशीट निर्यात जिसमें अंत वाला कॉलम खाली छूटा और शून्य पढ़ा गया, और ऐसी टाइम्ड-टेक्स्ट फ़ाइल से निकाला सबटाइटल जिसके मार्कर की शुरू से कोई अवधि ही नहीं थी।
क्या कई फ़ाइलें एक रन में जाँची जा सकती हैं?
हाँ। जितनी चाहें डालें और वे एक के बाद एक पढ़ी जाती हैं, हर एक अपनी रिपोर्ट बनाती है, और रिपोर्टें एक साथ zip में उतरती हैं। कतार हर फ़ाइल की प्रगति दिखाती है, रन बीच में रोका जा सकता है, और किसी भी समय कोई फ़ाइल अपलोड नहीं होती।