बिना खुद कुछ रिकॉर्ड किए किसी लिखे हुए आर्टिकल को नैरेटेड ऑडियो में बदलें, फिर उसे उसी लेख के साथ एपिसोड के रूप में पब्लिश करें। Picasso IA में 488 मॉडल हैं, तो नैरेशन, वॉइस क्लीनअप और वीडियो कैप्शन सब एक ही जगह मिलते हैं।
आपके ब्लॉग पर पहले से मौजूद हर आर्टिकल एक ऐसा पॉडकास्ट एपिसोड है जो अभी तक रिकॉर्ड नहीं हुआ। दलील पहले ही बन चुकी है, रिसर्च पहले ही हो चुका है, बस एक आवाज़ की कमी है जो उसे ज़ोर से पढ़ सके। AI नैरेशन इस जमा हुए बैकलॉग को बिना माइक्रोफोन, बिना रिकॉर्डिंग बूथ और बिना एडिटर के ऑडियो में बदल देता है, ताकि वही शब्द उन लोगों तक पहुंचें जो सफर में हैं, कुत्ते को टहला रहे हैं, या बस स्क्रॉल करने की बजाय सुनना पसंद करते हैं।
पढ़ने के लिए लिखा गया वाक्य तीन पंक्तियों तक फैल सकता है और फिर भी समझ में आ सकता है, क्योंकि आंख उस उपवाक्य की शुरुआत तक वापस जा सकती है जिसे वह भूल गई थी। सुनने वाले को सिर्फ एक ही मौका मिलता है। वही वाक्य, सामान्य गति से ज़ोर से पढ़ा जाए, तो बिना सांस लेने की जगह वाली उपवाक्यों की दीवार बनकर आता है, और दूसरे "जो" तक आते-आते बात खो जाती है। लंबे, आपस में गुंथे वाक्य जो स्क्रीन पर बिल्कुल ठीक काम करते हैं, आमतौर पर किसी के कान में काम करने से पहले दो या तीन छोटे वाक्यों में बांटने पड़ते हैं।
लिखे हुए टेक्स्ट की तीन और आदतें यही दिक्कत पैदा करती हैं। इनलाइन लिंक ("जैसा यहां बताया गया है") बिना क्लिक करने वाली अंडरलाइन के कुछ मतलब नहीं रखते, इसलिए या तो उन्हें हटाना पड़ता है या बोले जाने वाले संदर्भों में बदलना पड़ता है, जैसे "जैसा मैंने पहले के एक आर्टिकल में बताया था।" बुलेट लिस्ट बिना जोड़ने वाली क्रिया के टुकड़ों की सपाट सीरीज़ की तरह सुनाई देती है, तो पांच टिप्स की लिस्ट पांच डैश की जगह पांच छोटे वाक्य बन जाती है। और हेडिंग्स, जिन्हें पाठक पेज नेविगेट करने के लिए नज़र से देखता है, या तो छोटे बोले जाने वाले ट्रांज़िशन बनने चाहिए या पूरी तरह हटा देने चाहिए, क्योंकि "सेक्शन तीन: इम्प्लीमेंटेशन" ऐसा कुछ नहीं है जो कोई असली बातचीत में ज़ोर से कहता है।
आप जो पहला आर्टिकल सुनाते हैं वह बिना चाहे भी एक स्टैंडर्ड तय कर देता है। एक आवाज़, एक गति और एक एनर्जी लेवल चुनें, और उसके बाद हर एपिसोड वही वॉइस प्रोफाइल दोबारा इस्तेमाल करते ही वह चुनाव अपने आप अपना लेता है। यह स्टेप छोड़ें और हर पोस्ट पर आवाज़ बदलें, तो आर्काइव एक शो जैसा लगना बंद कर देता है; यह ऐसा लगने लगता है जैसे दस अलग-अलग रिकॉर्डिंग हों जो संयोग से एक ही फीड शेयर कर रही हों, और यही उस सुनने वाले को खोने का सबसे तेज़ तरीका है जिसे एपिसोड एक पसंद आया लेकिन एपिसोड चार पहचान में नहीं आया।
आवाज़ के चुनाव को अपने ब्रांड के रंग की तरह समझें: एक बार तय करें, लिख लें, और उसे लगातार लागू करें। एक छोटा स्टाइल नोट, आवाज़ का नाम, टारगेट गति, और नंबर अंकों में पढ़े जाएं या शब्दों में, यह तय होने से हर नई पोस्ट पर डेडलाइन के दबाव में इन डिटेल्स को दोबारा तय नहीं करना पड़ता। यह लगातारपन जमा भी होता है। जो सुनने वाला एक ही आवाज़ में तीन एपिसोड पूरे कर लेता है वह आपकी शैली को उसी तरह पहचानने लगता है जैसे किसी जाने-पहचाने पॉडकास्ट होस्ट को, और यही जान-पहचान कभी-कभार की सुनवाई को सब्सक्रिप्शन में बदल देती है।
हर आर्टिकल को सुनाने लायक बनने से पहले उतने ही बदलाव की ज़रूरत नहीं होती। एक सीधा-सादा नैरेटिव निबंध लगभग वैसे ही तैयार है जैसे लिखा गया है। एक बुलेट लिस्ट, एक टेक्निकल हाउ-टू या इंटरव्यू ट्रांसक्रिप्ट, हर एक अपनी अलग स्ट्रक्चरल आदतें साथ लाता है जिन्हें ऑडियो के अपने आप समझ आने से पहले ठीक करना पड़ता है।
| कंटेंट टाइप | सुनने वाले को क्या उलझाता है | ज़रूरी बदलाव |
|---|---|---|
| नैरेटिव निबंध या राय | लंबे वाक्य, कभी-कभी इनलाइन लिंक | हल्का, ज़्यादातर वाक्य तोड़ना और लिंक दोबारा लिखना |
| बुलेट पॉइंट लिस्ट | जोड़ने वाली क्रिया के बिना टुकड़े | हर बुलेट को पूरा बोला जाने वाला वाक्य बनाना |
| कोड या लिंक वाला टेक्निकल हाउ-टू | कोड ब्लॉक, फाइल पाथ, क्लिक संदर्भ | स्टेप्स को शब्दों में बताना, कोड को संक्षेप में समझाना |
| पब्लिश किया गया इंटरव्यू | स्पीकर लेबल, बातचीत का ओवरलैप | कौन बोल रहा है इसके बोले जाने वाले संकेत जोड़ना, बातचीत कसना |
किसी भी चीज़ को सुनाने से पहले हर आर्टिकल को इस फिल्टर से गुज़ारें: अगर देखने वाले पाठक को फॉलो करने के लिए पेज पर कुछ देखना पड़ता है, तो सुनने वाले को उस देखने की जगह लेने वाला एक वाक्य चाहिए। यह अकेला नियम कॉपी-पेस्ट नैरेशन में ज़्यादातर गड़बड़ी को सुलझा देता है।
प्रो टिप: पब्लिश हुए HTML को नहीं, बदले हुए स्क्रिप्ट को सुनाएं। पहले आर्टिकल को एक प्लेन टेक्स्ट ड्राफ्ट में पेस्ट करें, कैप्शन, हाइलाइट किए गए कोट्स और लिंक टेक्स्ट हटाएं, और ऑडियो जनरेट करने से पहले उस ड्राफ्ट को एक बार खुद धीमी आवाज़ में पढ़ें। जो ज़ोर से बोलने पर अजीब लगे वह फाइनल एपिसोड में भी अजीब ही लगेगा।
नैरेशन जनरेट करना एक कदम है; उसे किसी पॉडकास्ट ऐप के ढूंढने लायक चीज़ में बदलना दूसरा कदम है। पॉडकास्ट ऐप्स एक एपिसोड फीड पढ़ते हैं, ऑडियो फाइलों का फोल्डर नहीं, और वह फीड हर एपिसोड पर एक जैसी फाइल नेमिंग और बेसिक मेटाडेटा पर निर्भर करता है: कम से कम एक टाइटल, एक छोटा डिस्क्रिप्शन, एक एपिसोड नंबर और पब्लिश की तारीख। यह कदम छोड़ें तो आपके पास सर्वर पर एक बढ़िया ऑडियो फाइल रह जाती है जिसे कोई भी पॉडकास्ट ऐप कभी लिस्ट नहीं करेगा।
व्यावहारिक हल एक बार तय की गई नेमिंग कन्वेंशन है, जो पहला एपिसोड पब्लिश करने से पहले तय हो, हर नए सुनाए गए आर्टिकल पर इम्प्रोवाइज़ न की जाए। एक सीक्वेंशियल नंबर के साथ एक छोटा स्लग जितनी सरल चीज़ भी फीड को एक साल बाद नेविगेट करने लायक रखती है, जब छह की जगह साठ एपिसोड हों और कोई ठीक उसी एपिसोड को खोज रहा हो जो किसी खास टॉपिक पर था। पब्लिशिंग को अपना अलग चेकलिस्ट आइटम मानें, स्क्रिप्ट लिखने से अलग और ऑडियो जनरेट करने से अलग, तभी पूरा वर्कफ़्लो हर बार अलग प्रोजेक्ट बनने की बजाय दोहराने लायक बना रहता है।
किसी टूल के बारे में एक ईमानदार पेज यह बताता है कि वह कहां चूकता है। AI नैरेशन एक स्क्रिप्ट को सटीक तरीके से पढ़ता है; यह किसी ऐसे आर्टिकल को नहीं बचा सकता जो कभी सुनने के लिए लिखा ही नहीं गया, और पांच सीमाएं बार-बार सामने आती हैं।
पहले आर्टिकल को एक टेम्प्लेट टेस्ट की तरह समझें, अलग-थलग मामला नहीं। एक बार आवाज़, नेमिंग कन्वेंशन और एडाप्टेशन की आदतें तय हो जाएं, तो अगली पोस्ट सुनाने में पहली पोस्ट जितने समय का बस एक हिस्सा लगता है।
हां। एक टेक्स्ट टू स्पीच मॉडल एक स्क्रिप्ट पढ़ता है और एक ऑडियो फाइल बनाता है, जो पॉडकास्ट एपिसोड का मूल हिस्सा है। जिस हिस्से में समझ लगती है वह है पढ़ने के इर्द-गिर्द की हर चीज़: टेक्स्ट को इस तरह बदलना कि वह पढ़े जाने की बजाय सुने जाने पर समझ आए, ऐसी आवाज़ चुनना जिसे आप दोबारा इस्तेमाल करेंगे, और नतीजे को उन मेटाडेटा के साथ पैक करना जो पॉडकास्ट ऐप उम्मीद करता है। स्क्रिप्ट तैयार होते ही नैरेशन खुद लगभग तुरंत हो जाता है।
आप उसे जैसा है वैसा पेस्ट कर सकते हैं, लेकिन नतीजा अक्सर बिल्कुल वैसा ही सुनाई देता है, एक पेज ज़ोर से पढ़ा गया, सुनने के लिए लिखी गई स्क्रिप्ट नहीं। एक हल्का बदलाव, लंबे वाक्य तोड़ना, बुलेट्स को पूरे वाक्यों में दोबारा लिखना, और इनलाइन लिंक्स काटना या दोबारा लिखना, इस गैप का ज़्यादातर हिस्सा भर देता है। किसी आर्टिकल को कितना बदलाव चाहिए यह उसकी स्ट्रक्चर पर निर्भर करता है; ऊपर दी गई कंटेंट टाइप टेबल को एक सामान्य गाइड की तरह देखें।
लंबे नैरेशन के लिए बने टेक्स्ट टू स्पीच मॉडल सही परिवार हैं, क्योंकि वे एक वाक्य की बजाय कई पैराग्राफ की स्क्रिप्ट में एक जैसी आवाज़ और गति बनाए रखते हैं। Picasso IA अपने 488 मॉडलों के कैटलॉग में इनमें से कई रखता है। अपने बदले हुए स्क्रिप्ट के उसी पैराग्राफ पर दो टेस्ट करें और जिसे कई मिनट लगातार सुनना आसान लगे उसे रखें, क्योंकि यह किसी छोटे सैंपल से ज़्यादा असली सुनने के अनुभव के करीब है।
एक आवाज़ चुनें, पहली बार इस्तेमाल करते समय उसका नाम और सेटिंग्स नोट करें, और हर बार नए सिरे से चुनने की बजाय हर अगले आर्टिकल के लिए ठीक वही प्रोफाइल दोबारा इस्तेमाल करें। यही स्थिरता है जो सुनाए गए आर्टिकल्स की सीरीज़ को एक शो जैसा बनाती है, न कि आपस में असंबंधित रिकॉर्डिंग्स का ढेर। अगर आप बाद में आवाज़ बदलना चाहें, तो इसे चुपचाप हुई ड्रिफ्ट की बजाय एक जान-बूझकर किया गया रीलॉन्च मानें, क्योंकि आपके आर्काइव के बीच में मौजूद सुनने वाले को अचानक हुआ बदलाव नज़र आ जाएगा।
ऑडियो फाइल जनरेट करना बस आधा काम है। पॉडकास्ट ऐप एक एपिसोड फीड पढ़ता है, जिसे हर एपिसोड पर एक जैसी फाइल नेमिंग के साथ बेसिक मेटाडेटा चाहिए: एक टाइटल, एक छोटा डिस्क्रिप्शन, एक एपिसोड नंबर और पब्लिश की तारीख। बाद में इम्प्रोवाइज़ करने की बजाय अपने पहले एपिसोड से पहले ही नेमिंग कन्वेंशन तय कर लें, क्योंकि असंगत तरीके से शुरू हुआ फीड जब उसमें दर्जनों एपिसोड आ जाएं तो ठीक करना उबाऊ हो जाता है।
हां, अपने ऑडियंस के प्रति ईमानदारी के तौर पर, चाहे कोई कानून इसे ज़रूरी न बनाए। आपका आर्टिकल पढ़ने वाली सिंथेटिक आवाज़ को एपिसोड नोट्स में AI नैरेशन के रूप में लेबल करना चाहिए, यह जताने की बजाय कि यह आपकी खुद की रिकॉर्ड की गई आवाज़ है, खासकर किसी पर्सनल या बाईलाइन वाले ब्लॉग पर जहां सुनने वाले सही तौर पर मान लेते हैं कि वे लेखक को ही सुन रहे हैं।
कोई भी ऐसा आर्टिकल जो पाठक के कुछ देखने पर निर्भर करता है: स्क्रीनशॉट्स, चार्ट्स, नंबरों की टेबल्स, या कोड ब्लॉक जिन्हें समझ आने के लिए कैरेक्टर-दर-कैरेक्टर पढ़ना पड़े। ये आर्टिकल्स पूरी तरह फेल नहीं होते, लेकिन आसपास के टेक्स्ट का सीधा नैरेशन उस हिस्से को छोड़ देगा जो असल में जानकारी ले जा रहा था। एक दोबारा लिखी स्क्रिप्ट जो बताए कि विज़ुअल एलिमेंट क्या दिखा रहा था, आमतौर पर उसके इर्द-गिर्द नैरेट करने से बेहतर काम करती है।
एक सामान्य आर्टिकल पर एडाप्टेशन का काम, यह पता होने पर कि क्या देखना है, दस से बीस मिनट लेता है, और नैरेशन जनरेट करने में खुद कुछ मिनट लगते हैं। उच्चारण की गलतियों के लिए नतीजे को रिव्यू करना सुनने के कुछ और मिनट जोड़ देता है। पहले दो या तीन आर्टिकल्स के बाद, यह समय काफी कम हो जाता है, क्योंकि एडाप्टेशन की आदतें जानी-पहचानी हो जाती हैं और आवाज़ का चुनाव पहले से तय होता है।
नए अकाउंट्स को फ्री क्रेडिट्स मिलते हैं, जो किसी भी चीज़ के लिए कमिट करने से पहले एक पूरा आर्टिकल सुनाने और यह तय करने के लिए काफी हैं कि यह वर्कफ़्लो आपके पब्लिशिंग प्रोसेस में फिट बैठता है या नहीं। उसके बाद, जनरेट करने पर क्रेडिट्स लगते हैं, और मौजूदा प्लान प्राइसिंग पेज पर लिस्टेड हैं। नैरेशन के लिए कोई अलग टियर नहीं है; वही क्रेडिट्स टेक्स्ट टू स्पीच, इमेज, वीडियो और 3D मॉडल्स में काम करते हैं।
हां। नैरेशन बन जाने के बाद, उसे किसी स्टैटिक इमेज या सिंपल बैकग्राउंड क्लिप के साथ जोड़ा जा सकता है और फिर उसी कंटेंट का छोटा वीडियो वर्ज़न बनाने के लिए कैप्शनिंग वर्कफ़्लो से गुज़ारा जा सकता है, जो उन प्लेटफॉर्म्स के लिए काम का है जो सिर्फ ऑडियो फीड की बजाय वीडियो को तरजीह देते हैं। यह कैप्शनिंग स्टेप खुद कैसे काम करता है यह जानने के लिए ऑटोमैटिक सबटाइटल वर्कफ़्लो देखें।
आपका अगला आर्टिकल पहले से लिखा हुआ है, तो इस वर्कफ़्लो का सबसे मुश्किल हिस्सा पहले ही पीछे छूट चुका है। टेक्स्ट बदलें, एक आवाज़ चुनें, और यह सुनने के लिए कि आपकी अपनी लेखनी ज़ोर से पढ़े जाने पर कैसी लगती है, Toolkit में नैरेशन जनरेट करें।
