स्कैन किए गए PDF से ऑडियोबुक तक: यह क्यों मुश्किल है और हमने कैसे हल किया

पाँच सेकंड की चुप्पी

चिली से एक पाठिका ने साइन अप किया, एक बच्चों के उपन्यास की 74-पन्नों की PDF अपलोड की — Angeles Durini की "¿Quién le tiene miedo a Demetrio Latov?" — और ऑडियोबुक जनरेट करें पर क्लिक किया। पंद्रह सेकंड बाद, एक ईमेल आया: "आपकी ऑडियोबुक तैयार है।"

लेकिन वह तैयार नहीं थी। फ़ाइल मात्र 5.6 सेकंड लंबी थी। उसमें कुछ भी नहीं था।

यह वैसा बग है जो केवल प्रोडक्शन में ही पकड़ में आता है, क्योंकि हम जिन टेस्ट PDF का इस्तेमाल कर रहे थे, उनमें एम्बेडेड टेक्स्ट था। उनका नहीं था। उस किताब को 2012 में Adobe Acrobat Pro से पन्ना-दर-पन्ना स्कैन किया गया था — और हर पन्ना एक छवि के रूप में संग्रहीत था। हमारी पाइपलाइन के लिए, वह PDF 74 खाली पन्नों जैसी थी।

स्कैन किए गए PDF ऑडियोबुक पाइपलाइनों को क्यों तोड़ देते हैं

एक PDF टेक्स्ट को दो बिल्कुल अलग तरीकों से रख सकती है:

• टेक्स्ट PDF — शब्द असली अक्षरों के रूप में फ़ॉन्ट और स्थिति के साथ संग्रहीत होते हैं। कोई भी लाइब्रेरी (pypdf, pdfminer, pypdfium2) उन्हें मिलीसेकंड में निकाल सकती है।
• छवि PDF (स्कैन) — पन्ने JPEG या TIFF चित्र होते हैं जो PDF रैपर के अंदर एम्बेड किए जाते हैं। एक टेक्स्ट-निकालने वाली लाइब्रेरी के लिए, उन पन्नों में शून्य अक्षर होते हैं।

जो कुछ भी फ़्लैटबेड स्कैनर, फ़ोन कैमरे या किसी पुराने डिजिटाइज़ेशन प्रोजेक्ट से आया हो (सोचें Google Books, archive.org, सार्वजनिक डोमेन पुनर्मुद्रण, इस्तेमाल की गई बच्चों की किताबें) — वो दूसरी श्रेणी में आता है। इंसानी आँख को वे एक जैसे लगते हैं। सॉफ़्टवेयर के लिए वे ज़मीन-आसमान का फ़र्क हैं।

जब हमने विफल अपलोड की जाँच की, तो हमारे PDF पार्सर ने पूरी 74-पन्नों की किताब के लिए ठीक 17 अक्षर का कचरा — कंट्रोल बाइट्स, अक्षर नहीं — लौटाया था। फिर हमारी पाइपलाइन ने आज्ञाकारी ढंग से उन 17 बाइट्स को टेक्स्ट-टू-स्पीच में डाल दिया और 5 सेकंड की बुदबुदाहट पैदा कर दी। फिर पाठिका को ईमेल भेज दिया कि उसकी ऑडियोबुक तैयार है।

हमने क्या बनाया

समाधान सिद्धांत में सरल है: पता लगाएँ कि कब किसी PDF में इस्तेमाल लायक टेक्स्ट नहीं है, फिर हर पन्ने पर OCR चलाएँ। कार्यान्वयन के कुछ हिस्से बताने लायक हैं।

1. कम-टेक्स्ट डिटेक्टर

हर अपलोड के लिए सीधे OCR में कूदने से पहले, हम नेटिव एक्सट्रैक्शन का नतीजा देखते हैं। अगर पूरी PDF ने 200 से कम अक्षर लौटाए, या अगर औसत 4+ पन्नों पर प्रति पन्ना 30 अक्षर से कम है, तो हम उसे स्कैन मान लेते हैं और OCR की तरफ़ बढ़ जाते हैं। सामान्य टेक्स्ट PDF — 90%+ मामले — कभी धीमे रास्ते पर नहीं जाते।

2. pypdfium2 + tesseract (पूरी तरह Apache 2.0)

हम हर पन्ने को pypdfium2 (Google के PDFium इंजन के चारों ओर एक Python रैपर, Apache 2.0) से 2.5× स्केल पर रेंडर करते हैं — लगभग 180 DPI, जो भरोसेमंद अक्षर पहचान के लिए काफ़ी है। हर छवि tesseract के माध्यम से जाती है, जिसमें बहु-भाषा मॉडल लोड होता है: eng+spa+por+fra+deu+pol+ita+tur। Tesseract अक्षरों के आकार से असली भाषा खुद पहचान लेता है।

हमने जान-बूझकर PyMuPDF छोड़ दिया — सबसे लोकप्रिय Python PDF लाइब्रेरी — क्योंकि उसका AGPL लाइसेंस होस्टेड सेवा के लिए असुविधाजनक है। pypdfium2 पर स्विच करने में एक दोपहर लगी और कानूनी ख़तरा पूरी तरह ख़त्म हो गया। यह जानने लायक है अगर आप किसी व्यावसायिक उत्पाद के लिए PDF से जुड़ी कोई चीज़ बना रहे हैं।

3. भाषा का स्वतः पता लगाना

पाठिका की किताब स्पैनिश थी, लेकिन उसकी UI लोकेल अंग्रेज़ी थी — इसलिए हमारी मरम्मत से पहले, अगर OCR काम भी करता, तो भी पाइपलाइन स्पैनिश टेक्स्ट को अंग्रेज़ी आवाज़ में संश्लेषित करती (मशीनी, ग़लत उच्चारण)। अब भाषा पहचान खुद OCR किए गए टेक्स्ट का इस्तेमाल करती है। 3 नमूना पन्नों के बाद, langdetect सामग्री को वर्गीकृत कर सही आवाज़ चुन लेता है — इस मामले में, स्पैनिश-लैटिन-अमेरिकन।

4. ईमानदार विफलता मार्ग

अगर OCR तब भी 100 से कम अक्षर ही उबार पाए (केवल सजावटी PDF, टूटी हुई फ़ाइलें), तो अब हम चुप्पी पैदा करने के बजाय एक स्पष्ट त्रुटि उठाते हैं: "इस PDF में निकाला जा सकने वाला टेक्स्ट नहीं है। कृपया एक EPUB, TXT, या टेक्स्ट-आधारित PDF अपलोड करें।" ऑडियोबुक जॉब विफल चिह्नित होती है, कोई ईमेल नहीं भेजा जाता, कोई क्रेडिट नहीं काटा जाता।

नतीजा

हमने पाठिका की PDF को फिर से बनाई गई पाइपलाइन से गुज़ारा। पाँच मिनट के OCR ने उसके 74 स्कैन किए गए पन्नों से 1,44,710 अक्षर साफ़ स्पैनिश निकाला। फिर पाइपलाइन ने उसे 1,127 खंडों में विभाजित किया और एक 2 घंटे 43 मिनट की ऑडियोबुक रीड-अलॉन्ग सिंक के साथ बना दी — शब्द-दर-शब्द हाइलाइट ऑडियो से जुड़े हुए। हमने उसे स्पैनिश में, अपने ख़र्च पर, ईमेल भेजा और पहली कोशिश के लिए माफ़ी माँगी।

पूरी पुनर्जनन में लगभग 90 मिनट का वॉल-क्लॉक समय लगा: OCR के लिए लगभग 5 मिनट, टेक्स्ट-टू-स्पीच के लिए 80 मिनट, ऑडियो सामान्यीकरण (EBU R128) और M4A अंतिम रूप देने के लिए कुछ मिनट। यह एक टेक्स्ट PDF से धीमा है — लेकिन यह काम करता है। पहले यह बिल्कुल भी काम नहीं करता था।

अगर आपके पास स्कैन का ढेर है तो इसका क्या मतलब है

अगर आप स्कैन की गई किताबें इकट्ठा करते आ रहे हैं — पुराने पुनर्मुद्रण, आउट-ऑफ़-प्रिंट उपन्यास, archive.org से सार्वजनिक-डोमेन डिजिटाइज़ेशन, दादी की रेसिपी बुक के अपने ख़ुद के स्कैन — वे अब काग़ज़ पर अटके हुए नहीं हैं। उन्हें अपलोड करें। OCR हम कर देंगे।

फ़िलहाल हम 12 भाषाओं में OCR करते हैं: अंग्रेज़ी, स्पैनिश, पुर्तगाली, फ़्रेंच, जर्मन, पोलिश, इतालवी, तुर्की, अरबी, जापानी, कोरियाई, हिंदी। ऑडियोबुक खुद 23 आवाज़ भाषाओं में से किसी में भी बनाई जा सकती है। अगर आपकी स्कैन की हुई किताब किसी ऐसी भाषा में है जिसे हम अभी तक OCR नहीं करते, तो हमें बताएँ — एक tesseract भाषा पैक जोड़ने में कुछ मिनट लगते हैं।

व्यावसायिक लाइसेंसिंग पर एक नोट

हम जो पूरा OCR स्टैक इस्तेमाल करते हैं — tesseract, pypdfium2, pytesseract — सब Apache 2.0 है। यह मायने रखता है अगर आप कुछ ऐसा बना रहे हैं: PyMuPDF Python में PDF रेंडरिंग का आसान विकल्प है, लेकिन उसका AGPL लाइसेंस आपसे प्रोडक्शन में इस्तेमाल करने पर अपने पूरे SaaS को ओपन-सोर्स करने की माँग करता है। pypdfium2 + tesseract आपको वही क्षमताएँ बिना किसी लाइसेंस के बोझ के देता है।

वह बग जिसने हमें बेहतर बनाया

ज़्यादातर प्रोडक्शन बग टेस्ट में पकड़े जाते हैं। यह नहीं पकड़ा गया, क्योंकि यह धारणा — "PDF में टेक्स्ट होता है" — हर उस डेव फ़ाइल पर सही उतरी जो हमने कभी इस्तेमाल की थी। इसे उजागर करने के लिए चिली की एक असली पाठिका को, प्लेटफ़ॉर्म पर अपने पहले घंटे में, आना पड़ा।

तो धन्यवाद, असली पाठकों। आप वो बग ढूँढ निकालते हैं जो हम नहीं ढूँढ सकते।