संगीत रिलीज़ मेटाडेटा: संपूर्ण तकनीकी संदर्भ

देवनागरी, नुक़्ता, और हिंदी–उर्दू लिपि-द्वैत के पूरे विवरण के साथ।

सीधा उत्तर

मेटाडेटा वह जानकारी नहीं है जो आपके संगीत के साथ जाती है — डिलीवरी चेन के हर सिस्टम के लिए वही आपका संगीत है। कोई भी स्ट्रीमिंग सेवा आपका मास्टर सुनकर फ़ैसला नहीं करती; वह आपकी भरी हुई फ़ील्ड पढ़ती है। हिंदी में काम करने वाले कलाकार के लिए इसका सबसे महँगा नतीजा यह है कि देवनागरी में एक ही नाम दो या तीन अलग-अलग बाइट-स्ट्रिंग हो सकता है और आँख से यह अंतर देखा ही नहीं जा सकता — नुक़्ता वाले अक्षर (क़ ख़ ग़ ज़ फ़ ड़ ढ़) यूनिकोड में दो-दो तरीक़ों से मौजूद हैं, अनुस्वार और चंद्रबिंदु और संयुक्त नासिक्य एक ही शब्द की तीन वर्तनियाँ बनाते हैं, और वही गायक अक्सर देवनागरी, नस्तालीक़ और रोमन — तीनों में मौजूद होता है। इसका असर यह होता है कि एक कलाकार के दो-तीन प्रोफ़ाइल बन जाते हैं, स्ट्रीम बँट जाते हैं, फ़ॉलोअर नए पेज पर नहीं आते, और फ़िल्मी रिपर्टवा में संगीतकार–गीतकार के खाने ख़ाली छूट जाने से पब्लिशिंग रॉयल्टी बरसों बिना मिलान के पड़ी रहती है। बचाव तकनीकी नहीं, अनुशासनात्मक है: नाम का एक कैननिकल रूप (सटीक कोड-पॉइंट सहित) एक बार तय कीजिए, उसे एक फ़ाइल में रखिए, और हर रिलीज़ में टाइप करने के बजाय पेस्ट कीजिए। यह दस्तावेज़ बताता है कि कौन-सा तथ्य किस परत पर दर्ज होता है, देवनागरी में क्या-क्या चुपचाप टूटता है, और डिलीवरी से पहले किन चीज़ों की जाँच होनी चाहिए।

मेटाडेटा वह काग़ज़ी काम नहीं है जो संगीत के साथ नत्थी होता है

भारतीय स्वतंत्र संगीत में मेटाडेटा को आम तौर पर वह फ़ॉर्म समझा जाता है जो अपलोड से ठीक पहले, जल्दबाज़ी में, स्टूडियो से निकलते वक़्त भरा जाता है। यह समझ ही मूल समस्या है। डाउनस्ट्रीम का कोई सिस्टम आपका मास्टर नहीं सुनता — वह आपकी डिलीवरी पढ़ता है। आपने जो फ़ील्ड भरी हैं वही तय करती हैं कि ट्रैक किस आर्टिस्ट पेज पर उतरेगा, आपके स्ट्रीम एक पहचान के नीचे जमा होंगे या तीन में बिखरेंगे, पब्लिशिंग-पक्ष किस पूल से भुगतान करेगा, रिलीज़ अपने श्रोताओं की भाषा में खोजी जा सकेगी या नहीं, और वह स्वीकार भी होगी या नहीं।

एक ऐसी रिकॉर्डिंग जिसका मास्टर निर्दोष है पर जिसका मेटाडेटा टूटा हुआ है, व्यावसायिक रूप से उस रिकॉर्डिंग जैसा बर्ताव करती है जो कभी रिलीज़ ही नहीं हुई: वह मौजूद है, वह बजती है, और सही व्यक्ति के खाते में कुछ नहीं जुड़ता। नुक़सान समय के साथ असममित है — डिलीवरी से पहले के दस मिनट में इसे रोकना सस्ता है, बाद में सुधारना धीमा और अक्सर असंभव, क्योंकि तब तक दर्जनों सिस्टम आपकी ग़लती की नक़ल बना चुके होते हैं।

मेटाडेटा रिलीज़ का एकमात्र हिस्सा है जिसे हर प्लेटफ़ॉर्म पढ़ता है और कोई श्रोता नहीं देखता — और ठीक इसीलिए यह चुपचाप विफल होता है।

1. तीन परतें: रिलीज़, रिकॉर्डिंग, कृति

एक रिलीज़ एक वस्तु नहीं, एक पदानुक्रम है। सबसे ऊपर रिलीज़ (उत्पाद — एल्बम, ईपी, सिंगल) है, उसके भीतर रिकॉर्डिंग (ट्रैक) हैं, और हर रिकॉर्डिंग किसी कृति (रचना, यानी वह गीत जो कोई और भी गा सकता है) को मूर्त करती है। हर परत की अपनी पहचान-संख्या है और अपनी आमदनी:

• UPC/EAN — रिलीज़ की पहचान। UPC-A बारह अंक का है, EAN-13 तेरह का; आगे एक शून्य लगाने से UPC-A, EAN-13 बन जाता है और चेक डिजिट नहीं बदलता।
• ISRC — रिकॉर्डिंग की पहचान। बारह वर्ण: दो देश, तीन रजिस्ट्रेंट, दो वर्ष-संदर्भ, पाँच पदनाम। हाइफ़न केवल प्रदर्शन की परंपरा है, कोड का हिस्सा नहीं, और ISRC में कोई चेक डिजिट नहीं होता।
• ISWC — कृति की पहचान।

अधिकांश महँगी ग़लतियाँ ग़लत तथ्य नहीं होतीं — वे सही तथ्य होती हैं जो ग़लत परत पर दर्ज कर दी गई हैं। "यह तबला किसने बजाया" रिकॉर्डिंग की बात है; "यह ठुमरी किसने लिखी" कृति की बात है; "यह संकलन कब बाज़ार में आया" रिलीज़ की बात है। यह जानकारी सेवाओं तक एक मानकीकृत रास्ते से पहुँचती है — DDEX का Electronic Release Notification Message Suite (ERN)।

ISRC कब दोबारा चाहिए, इस पर एक आम ग़लतफ़हमी है। रीमिक्स, एडिट, लाइव संस्करण और वाद्य-संस्करण — ये सब भौतिक रूप से अलग रिकॉर्डिंग हैं और इन्हें नया कोड चाहिए। उसी रिकॉर्डिंग का पुनःप्रकाशन नया कोड नहीं माँगता, और डिस्ट्रिब्यूटर बदलने पर ISRC रिकॉर्डिंग के साथ ही रहता है। रीमास्टर का मामला सबसे तंग है: IFPI की ISRC हैंडबुक (§A.10.1) के अनुसार नया कोड तभी चाहिए जब रीमास्टरिंग की प्रक्रियाओं में "the application of creative input to the recording itself" शामिल हो; हैंडबुक स्पष्ट रूप से साधारण स्तर-परिवर्तन, अपरिवर्ती EQ, अपरिवर्ती कम्प्रेशन, डी-नॉइज़िंग, डी-क्लिकिंग, गति/पिच सुधार, सैंपल-रेट परिवर्तन और डिदरिंग को बाहर रखती है — "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes." व्यावहारिक नियम जो सुरक्षित है: अगर रीमास्टर मूल ट्रैक के साथ-साथ एक अलग उत्पाद के रूप में बिक रहा है, तो वह अलग उत्पाद है और उसका अपना कोड चाहिए।

UPC का चेक डिजिट अपने आप जाँचा जा सकता है, और डिलीवरी से पहले जाँच लेना चाहिए। नियम यह है: दाईं ओर से शुरू करके, चेक डिजिट से पहले के अंकों पर बारी-बारी ×3 और ×1 लगाइए, जोड़िए, और चेक डिजिट वह अंक है जो कुल को अगले दस के गुणज तक पहुँचा दे। अगर आपका डिस्ट्रिब्यूटर UPC देता है तो यह जाँच अनावश्यक है; अगर आप किसी लेबल से मिला हुआ, या पुराने भौतिक रिलीज़ से उठाया हुआ कोड इस्तेमाल कर रहे हैं, तो यह दो मिनट का काम एक निश्चित अस्वीकृति बचा देता है।

एक और भेद जो लगातार गड्डमड्ड होता है: ISRC रिकॉर्डिंग की पहचान है, ISWC गीत की, और UPC उत्पाद की। "यह वही ग़ज़ल है जो 1998 में रिकॉर्ड हुई थी" — यह ISWC-स्तर का दावा है। "यह वही रिकॉर्डिंग है" — यह ISRC-स्तर का। "यह वही एल्बम है" — यह UPC-स्तर का। तीनों एक साथ सच हो सकते हैं, तीनों में से कोई भी अकेले सच हो सकता है।

अगर आप यह नहीं कह सकते कि कोई तथ्य किस परत का है, तो आप उसे अभी दर्ज करने लायक़ नहीं हैं।

2. फ़ील्ड-दर-फ़ील्ड: कौन-सा खाना क्या तय करता है

प्राथमिक कलाकार (Primary artist). यही, और केवल यही, फ़ील्ड तय करती है कि ट्रैक किस आर्टिस्ट पेज पर जाएगा और श्रोता-संख्या, फ़ॉलोअर तथा एल्गोरिद्मिक इतिहास किसके खाते में जुड़ेगा। Spotify का सार्वजनिक निर्देश दो-टूक है: "List each artist's name in a separate field." यानी "ज़ेबा क़ुरैशी और पंडित रघुवीर मिश्र" एक स्ट्रिंग में नहीं, दो अलग फ़ील्ड में।

फ़ीचर्ड आर्टिस्ट. उसी रिकॉर्डिंग पर एक अलग भूमिका, जो सह-कलाकार को श्रेय और उनके पेज तक लिंक देती है, पर प्राथमिक बिलिंग नहीं। Apple की स्टाइल गाइड के अनुसार फ़ीचर्ड आर्टिस्ट ट्रैक-स्तर पर Featuring या With भूमिका में जाने चाहिए, "not as Primary."

रीमिक्सर. यह भी एक भूमिका है। Apple: "Remix tracks...must list the original artist as Primary with the remixer assigned the remixer role." रीमिक्सर को प्राथमिक कलाकार बना देना वही तरीक़ा है जिससे किसी गायक का पेज दूसरों के रीमिक्स से भर जाता है।

संगीतकार (composer) और गीतकार (lyricist). ये कृति का वर्णन करते हैं, रिकॉर्डिंग का नहीं, और पब्लिशिंग तथा मैकेनिकल रॉयल्टी इन्हीं से ट्रेस होती है। भारतीय रिपर्टवा में यह सबसे ज़्यादा ख़ाली छूटने वाला खाना है — विस्तार से खंड 8 में।

निर्माता (producer). एक योगदानकर्ता भूमिका: श्रेय है, न आर्टिस्ट पेज है, न रिकॉर्डिंग-पक्ष का भुगतान।

संस्करण / उपशीर्षक (version/subtitle). वह कोष्ठक जो एक ही शीर्षक की दो रिकॉर्डिंगों को अलग करता है — लाइव, इंस्ट्रुमेंटल, रेडियो एडिट (खंड 7)।

एक्सप्लिसिट फ़्लैग. यह एक बूलियन है, शब्द नहीं। Apple: "Explicit content must be flagged Explicit with a parental advisory tag. Terms like (Explicit)...must not be used for album...or track titles." Spotify: "you shouldn't add it to your track title." उल्टा भी मना है — शीर्षक में "Clean" या "साफ़ संस्करण" लिखना भी ग़लत है।

कृति की भाषा (क्या गाया जा रहा है) और शीर्षक की भाषा (शीर्षक-स्ट्रिंग की भाषा और लिपि) अलग-अलग फ़ील्ड हैं और इनका अलग होना पूरी तरह वैध है — तबला एकल की कोई गीत-भाषा नहीं है, पर उसका शीर्षक "तीन ताल: विलंबित से द्रुत" हिंदी/देवनागरी में है। शीर्षक-भाषा फ़ील्ड ही स्टोर को बताती है कि आपके टेक्स्ट को कैसे छाँटना, अनुक्रमित करना और रेंडर करना है — ग़ैर-लैटिन डिलीवरी में यह सबसे परिणामकारी फ़ील्डों में से एक है, और सबसे ज़्यादा ग़लत भरी जाने वाली भी।

P-लाइन = वर्ष + ध्वनि-रिकॉर्डिंग का स्वामी, और वह वर्ष उस रिकॉर्डिंग के पहले प्रकाशन का है, आपके अपलोड का नहीं। C-लाइन = वर्ष + आर्टवर्क और पैकेजिंग का स्वामी। ये आपस में बदले नहीं जा सकते, फिर भी नियमित रूप से एक-दूसरे में कॉपी-पेस्ट होते हैं।

शैली (genre). यह आपकी रुचि का वर्णन नहीं, एक राउटिंग संकेत है। ग़ज़ल, भजन, ठुमरी, क़व्वाली, फ़िल्मी, सूफ़ी, शास्त्रीय — इनमें से जो चुनेंगे वही तय करेगा कि रिलीज़ किन संपादकीय और एल्गोरिद्मिक संदर्भों के योग्य है।

रिलीज़ तिथि = यह उत्पाद कब लाइव होता है; मूल रिलीज़ तिथि = यह रिकॉर्डिंग पहली बार कहीं भी कब प्रकाशित हुई। 2014 की एक ठुमरी रिकॉर्डिंग को 2026 की मूल रिलीज़ तिथि के साथ भेजना हर डाउनस्ट्रीम सिस्टम को यह बताता है कि वह नई है — और पुरानी रिकॉर्डिंग की पूरी ऐतिहासिक पहचान मिट जाती है।

3. कलाकार का नाम एक कुंजी है, लेबल नहीं

स्टोर के लिए कलाकार का नाम पढ़ने की चीज़ नहीं, मिलान की कुंजी है। जब कोई डिलीवरी ऐसी प्राथमिक-कलाकार स्ट्रिंग के साथ आती है जो किसी मौजूदा पहचान से बिल्कुल मेल नहीं खाती, तो मिलान-तर्क या तो उसे उसी कलाकार से जोड़ता है या एक नया कलाकार बना देता है; और जो कुछ भी आत्मविश्वास घटाता है — अलग वर्तनी, अलग नुक़्ता-रूप, अतिरिक्त स्पेस, अलग लिपि, या एक ही दिखने वाले अक्षर के लिए अलग बाइट — वह पलड़ा "नया कलाकार" की ओर झुका देता है।

तब एक कलाकार दो हो जाता है। कैटलॉग बँटता है, स्ट्रीम बँटते हैं, और फ़ॉलोअर दूसरी पहचान तक नहीं पहुँचते — यानी वह दूसरी पहचान बिना किसी एल्गोरिद्मिक इतिहास के शून्य से शुरू होती है। रॉयल्टी फिर भी मिलती है, पर दो अलग संचय-इतिहासों के विरुद्ध, और जो कुछ कैटलॉग-स्तर पर मापा जाता है — संपादकीय विचार, एनालिटिक्स, वेरिफ़िकेशन — वह अब आधे करियर पर मापा जा रहा है।

दोनों प्रमुख स्टाइल संदर्भ एकमत हैं। Music Biz: "Artist name spelling should remain consistent for all content for an artist, where possible." Spotify: वर्तनी और फ़ॉर्मैटिंग रिलीज़-दर-रिलीज़ एक जैसी रखिए, "including any punctuation, abbreviations, or acronyms."

हिंदी कैटलॉग में विफलता के ठेठ रूप बेहद सांसारिक हैं, और लगभग सब अदृश्य हैं:

• नुक़्ता का पूर्वरचित रूप एक रिलीज़ में, विघटित रूप अगली में — "फ़ैज़ान क़ुरैशी" बनाम "फ़ैज़ान क़ुरैशी" (खंड 4.1)।
• अनुस्वार बनाम चंद्रबिंदु — "साँझ म्यूज़िक" बनाम "सांझ म्यूज़िक"।
• देवनागरी में नाम एक रिलीज़ पर, रोमन में अगली पर, और नस्तालीक़ में तीसरी पर (खंड 4.8)।
• सम्मान-सूचक उपसर्ग जो कभी-कभी लगता है और कभी नहीं — "पंडित रघुवीर मिश्र" बनाम "रघुवीर मिश्र", या "उस्ताद" का आना-जाना। यह मिलान-प्रणाली के लिए दो नाम हैं।
• अंत में लगा हुआ अतिरिक्त स्पेस, जो किसी संपादक में नहीं दिखता।
• "&" एक रिलीज़ पर और "और" अगली पर।
• रोमन में "DJ" बनाम "Dj", या डायक्रिटिक की असंगति — Music Biz का अपना उदाहरण "Beyoncé vs. Beyoncè" है।

बाद में इसे ठीक करना संपादन नहीं, एक दावा है: आपका डिस्ट्रिब्यूटर हर स्टोर से दो पहचानों को मर्ज करने का अनुरोध करता है, हर स्टोर उसे अपनी क़तार और अपनी प्रमाण-शर्तों के साथ अलग से निपटाता है, कुछ जल्दी कर देते हैं और कुछ कभी नहीं करते। बँटा हुआ आर्टिस्ट पेज ऐसी ख़राबी नहीं है जिसे आप ठीक करते हैं; वह एक अर्ज़ी है जो आप स्टोर-दर-स्टोर दाख़िल करते हैं और उम्मीद करते हैं।

4. देवनागरी में जो चुपचाप टूटता है

यह इस दस्तावेज़ का केंद्र है, और इसका कोई ठीक समकक्ष किसी भाषा में उपलब्ध नहीं है। शुरू में ही एक ईमानदार सीमा दर्ज कर दें: देवनागरी मेटाडेटा त्रुटि-दर का कोई प्रकाशित माप उद्योग में कहीं मौजूद नहीं है, जहाँ तक हमें ज्ञात है — समस्या सार्वभौमिक रूप से भोगी जाती है और पूरी तरह अपरिमाणित है।

अच्छी ख़बर यह है कि हिंदी बाईं-से-दाईं लिखी जाती है, इसलिए अरबी/फ़ारसी/उर्दू लिपि वाली द्विदिश (bidi) गड़बड़ियाँ यहाँ लागू नहीं होतीं। देवनागरी की समस्याएँ अलग क़िस्म की हैं — और ज़्यादा कपटी, क्योंकि इनमें से किसी में भी स्क्रीन पर कुछ ग़लत नहीं दिखता।

4.1 नुक़्ता: क़ ख़ ग़ ज़ फ़ ड़ ढ़ — कैटलॉग का सबसे बड़ा अदृश्य विभाजक

हिंदी की सबसे आम धुनें और शैलियाँ ही इस जाल पर बैठी हैं: ग़ज़ल, क़व्वाली, फ़िल्मी — तीनों में नुक़्ता वाला अक्षर है।

यूनिकोड में इन अक्षरों को लिखने के दो वैध तरीक़े हैं:

1. पूर्वरचित (precomposed) एकल कोड-पॉइंट — U+0958 क़, U+0959 ख़, U+095A ग़, U+095B ज़, U+095C ड़, U+095D ढ़, U+095E फ़, U+095F य़
2. आधार अक्षर + नुक़्ता चिह्न — जैसे क (U+0915) + ़ (U+093C DEVANAGARI SIGN NUKTA)

स्क्रीन पर दोनों बिल्कुल एक जैसे दिखते हैं। मेमोरी में एक तीन बाइट का है और दूसरा छह बाइट का। किसी भी मिलान, छँटाई या खोज तंत्र के लिए ये दो अलग स्ट्रिंग हैं।

अब वह हिस्सा जो लगभग हर कोई ग़लत मानता है। आम धारणा यह है कि "NFC सब कुछ जोड़ देगा, NFD सब कुछ तोड़ देगा" — यानी NFC करने पर आपको एकल कोड-पॉइंट क़ (U+0958) मिलेगा। यह ग़लत है, और उलटा है। ये आठों अक्षर यूनिकोड की Composition Exclusion Table में हैं। हमने इसे लिखने से पहले Python के unicodedata (UCD 14.0.0) से और unicode.org की जीवित CompositionExclusions.txt से सत्यापित किया; परिणाम शब्दशः यह था:

0x958 DEVANAGARI LETTER QA  | decomposition: 0915 093C
      NFC  -> ['0x915', '0x93c']      NFD -> ['0x915', '0x93c']
      NFC(क़) == क़ ?  False
'क' + '़'  ->  NFC ['0x915', '0x93c']   (जुड़ता नहीं)
NFKC और NFKD भी वही देते हैं: ['0x915', '0x93c']

यानी: चारों सामान्यीकरण रूप — NFC, NFD, NFKC, NFKD — पूर्वरचित नुक़्ता अक्षर को तोड़ देते हैं, और कभी जोड़ते नहीं। UAX #15 इसे सीधे कहता है: "It is a notable characteristic of the Unicode Normalization Algorithm that no composition exclusion character can occur in any normalized form of Unicode text: NFD, NFC, NFKD, or NFKC." और वह अपना उदाहरण भी हिंदी से ही लेता है: "The character U+0958 (क़) DEVANAGARI LETTER QA is an example of a script-specific composition exclusion."

इसके दो व्यावहारिक निष्कर्ष हैं, और वे विपरीत दिशाओं में जाते हैं:

• अगर पाइपलाइन का हर पड़ाव सामान्यीकरण करता है, तो दोनों रूप एक ही परिणाम पर मिल जाते हैं (हमारी जाँच में NFC(आधार+नुक़्ता) == NFC(पूर्वरचित) → True), और समस्या हल है।
• अगर कोई पड़ाव सामान्यीकरण नहीं करता — और डिलीवरी चेन का कोई पड़ाव इसकी गारंटी नहीं देता — तो "ग़ज़ल" (आधार+U+093C) और "ग़ज़ल" (पूर्वरचित) दो अलग शीर्षक हैं, और "फ़रीद अहमद" तथा "फ़रीद अहमद" दो अलग कलाकार।

एक और बारीकी जो इसे और उलझाती है: देवनागरी के सभी नुक़्ता-अक्षर बहिष्कृत नहीं हैं। U+0929 ऩ, U+0931 ऱ और U+0934 ऴ के भी कैननिकल विघटन हैं, पर वे बहिष्करण-सूची में नहीं हैं — हमारी जाँच में NFC('न' + '़') ने U+0929 लौटाया, यानी वे जुड़ते हैं। इसलिए "देवनागरी में NFC नुक़्ता तोड़ देता है" भी पूरा सच नहीं है; सच यह है कि U+0958–U+095F टूटते हैं और U+0929/0931/0934 जुड़ते हैं। एक ही लिपि, एक ही चिह्न, दो विपरीत व्यवहार।

करने योग्य: एक रूप चुनिए — व्यवहार में आधार + U+093C चुनना बेहतर है, क्योंकि वही सामान्यीकृत रूप है और वही हर परिस्थिति में स्थिर रहता है — और उसे कैटलॉग भर में लागू कीजिए। कलाकार का नाम एक फ़ाइल में उसी रूप में रखिए और हर बार पेस्ट कीजिए। कभी भी "क़" को मोबाइल कीबोर्ड से और "क़" को डेस्कटॉप से मिलाकर मत टाइप कीजिए — दोनों कीबोर्ड अलग-अलग रूप देते हैं और आपको कभी पता नहीं चलेगा।

4.2 अनुस्वार ं बनाम चंद्रबिंदु ँ बनाम स्पष्ट संयुक्त नासिक्य

"हिंदी" शब्द को हिंदी में तीन तरह से लिखा जा सकता है, और तीनों प्रचलित हैं:

पहली में अनुस्वार (U+0902) है, दूसरी में न + हलंत का स्पष्ट संयुक्ताक्षर, तीसरी में चंद्रबिंदु (U+0901)। भाषिक दृष्टि से पहली दो एक ही शब्द की दो मान्य वर्तनियाँ हैं और तीसरी अनुनासिक उच्चारण दर्शाती है। मेटाडेटा की दृष्टि से ये तीन अलग कुंजियाँ हैं, और — यह अहम है — इनमें से कोई भी सामान्यीकरण से दूसरे में नहीं बदलती। हमने जाँचा: U+0901, U+0902 और U+0903 (विसर्ग) का कोई कैननिकल विघटन नहीं है (decomposition = ''), इसलिए NFC/NFD इनके साथ कुछ नहीं करते।

यही समस्या हर उस शीर्षक पर लागू होती है जिसमें अनुनासिक है, और भारतीय रिपर्टवा उनसे भरा है: बाँसुरी / बांसुरी, साँझ / सांझ, चाँद / चांद, संगीत / सङ्गीत, अंगना / अङ्गना। एक भजन एल्बम जिसका एक ट्रैक "साँवरे की धुन" है और जिसका आर्टवर्क पर "सांवरे की धुन" लिखा है, वह खंड 9 की जाँच-सूची में सीधे फ़ेल है — और खोज में भी, क्योंकि श्रोता जो टाइप करेगा वह ज़रूरी नहीं आपकी वर्तनी हो।

करने योग्य: प्रति कलाकार, प्रति शैली एक वर्तनी-नीति तय कीजिए — आमतौर पर आधुनिक मानक हिंदी की अनुस्वार-वाली वर्तनी (हिंदी, संगीत, अंगना) सबसे सुरक्षित है, और चंद्रबिंदु वहीं रखिए जहाँ वह वास्तव में उच्चारण का हिस्सा है (बाँसुरी, साँझ)। जो भी चुनें, आर्टवर्क, शीर्षक फ़ील्ड और आपके अपने प्रचार-सामग्री में वही रहे।

4.3 मात्रा-क्रम और वह ि जो बाद में टाइप होती है, पहले दिखती है

देवनागरी में इ की मात्रा (ि, U+093F) व्यंजन के बाद संचित होती है पर व्यंजन के बाईं ओर रेंडर होती है। "किताब" में स्मृति-क्रम है क, ि, त, ा, ब — पर आँख पहले ि देखती है। यह कोई ख़राबी नहीं; यूनिकोड टेक्स्ट को उच्चारण-क्रम (logical order) में रखता है और आकार-निर्माण (shaping) इंजन उसे प्रदर्शन-क्रम में बदलता है।

गड़बड़ तब होती है जब कोई सिस्टम स्ट्रिंग को अक्षरों की सूची मानकर काटता या छाँटता है:

• छँटाई: "किताब" का पहला कोड-पॉइंट क (U+0915) है, ि नहीं। इसलिए यह "कव्वाली" के पास सॉर्ट होगा, "इ" के पास नहीं — जो सही है, पर उस उपयोगकर्ता के लिए चौंकाने वाला है जो प्रदर्शन देख रहा है।
• कटाव (truncation): कोई स्टोर शीर्षक को n वर्णों पर काटता है और कट मात्रा और व्यंजन के बीच पड़ जाता है — तब स्क्रीन पर अनाथ ि या टूटा हुआ हलंत दिखता है। "क्या" को एक वर्ण पर काटने से क + अनाथ हलंत बचता है।
• उपस्ट्रिंग खोज: "दिल" खोजने पर "दिलबर" मिलेगा, क्योंकि स्मृति-क्रम में वे उपसर्ग-संबंध में हैं। पर जो उपयोगकर्ता प्रदर्शन देखकर सोचता है कि शीर्षक "ि" से शुरू होता है, वह कभी मेल नहीं पाएगा।
• मात्रा-क्रम और नुक़्ता: यहाँ एक असली फंदा है। नुक़्ता (U+093C) की कैननिकल कंबाइनिंग क्लास 7 है, जबकि मात्राओं की 0 है। इसका मतलब यह है कि सामान्यीकरण उन्हें आपस में पुनःक्रमित नहीं करता। हमने जाँचा: NFC('क' + 'ि' + '़') → [0915, 093F, 093C] और NFC('क' + '़' + 'ि') → [0915, 093C, 093F] — दोनों अलग रहते हैं, equal after NFC? False। सही क्रम व्यंजन + नुक़्ता + मात्रा है (क़ि), पर कुछ इनपुट विधियाँ उल्टा उत्पन्न करती हैं, और सामान्यीकरण आपको नहीं बचाएगा।

करने योग्य: देवनागरी टेक्स्ट को कभी वर्ण-गणना पर मत काटिए; अगर काटना ही है तो ग्राफ़ीम-क्लस्टर सीमा पर काटिए। और डिलीवरी से पहले नुक़्ता-मात्रा क्रम की जाँच कीजिए — यह वह त्रुटि है जो न दिखती है, न सामान्यीकरण से सुधरती है।

4.4 अंक: ०१२३ बनाम 0123

देवनागरी अंक U+0966–U+096F (०१२३४५६७८९) असली कोड-पॉइंट हैं, ASCII 0–9 की शैलीगत विविधता नहीं। यूनिकोड कैरेक्टर डेटाबेस उन्हें संख्यात्मक मान देता है (U+0968 का मान 2 है), पर वे ASCII "2" के बराबर नहीं हैं।

व्यवहार में यह शीर्षकों की छँटाई तोड़ देता है। हमने एक साधारण कोड-पॉइंट सॉर्ट चलाया:

sorted(['भाग 2', 'भाग १०', 'भाग 10'])
  ->  ['भाग 10', 'भाग 2', 'भाग १०']

तीन खंड, तीन जगह — और "भाग १०" सूची के अंत में चला गया क्योंकि U+0967 हर ASCII अंक से बड़ा है। एक ठुमरी संकलन जिसके खंड "भाग १", "भाग 2", "भाग ३" लिखे गए हों, वह किसी भी स्टोर पर सही क्रम में नहीं दिखेगा।

खोज में भी यही है: "भाग २" खोजने वाला श्रोता "भाग 2" से तब तक नहीं मिलेगा जब तक उस स्टोर की खोज-परत अंकों को फ़ोल्ड न करे — और कोई गंतव्य इसकी गारंटी नहीं देता।

करने योग्य: एक कैटलॉग के लिए एक अंक-समुच्चय चुनिए और कभी मिलाइए मत। मशीन द्वारा पढ़ी जाने वाली फ़ील्डों — खंड-संख्या, भाग-संख्या, वर्ष — में ASCII सबसे सुरक्षित डिफ़ॉल्ट है। देवनागरी अंक तभी रखिए जब वे कलात्मक पहचान का हिस्सा हों, और तब हर जगह रखिए।

4.5 विराम-चिह्न, हलंत, और ZWJ/ZWNJ की देवनागरी वाली भूमिका

• दंड (।, U+0964) और द्विदंड (॥, U+0965) देवनागरी के अपने विराम-चिह्न हैं। शीर्षक फ़ील्ड में दंड आम तौर पर अनावश्यक है और कुछ पाइपलाइनों में अजीब तरह से छँटता है; शीर्षक को बिना अंतिम दंड के लिखिए।
• अवग्रह (ऽ, U+093D) शास्त्रीय और भक्ति-रिपर्टवा में मिलता है। वह वैध है, पर इसे अपोस्ट्रॉफ़ी से मत बदलिए और अपोस्ट्रॉफ़ी को इससे मत बदलिए।
• ॐ (U+0950) का कोई विघटन नहीं है (हमने जाँचा: decomposition = ''), इसलिए यह सामान्यीकरण से नहीं बदलता — पर कई स्टोर सजावटी प्रतीकों को शीर्षक में स्वीकार नहीं करते, इसलिए भजन शीर्षकों में इसे केवल तब रखिए जब वह वास्तव में शीर्षक का शब्द हो।
• ZWJ (U+200D) और ZWNJ (U+200C) का देवनागरी में एक विशिष्ट काम है: संयुक्ताक्षर का रूप ज़बरदस्ती बदलना — यह तय करना कि क्ष आधे-क + ष के रूप में जुड़ेगा या क् (स्पष्ट हलंत) + ष के रूप में अलग दिखेगा। ये अदृश्य वर्ण हैं। बहुत सी फ़ॉर्म-फ़ील्ड और सैनिटाइज़र "अदृश्य" या "नियंत्रण" वर्णों को चुपचाप हटा देते हैं, और कुछ उन्हें स्पेस से बदल देते हैं — जो और बुरा है, क्योंकि इससे शब्द ही बदल जाता है। मेटाडेटा फ़ील्ड में इनसे बचिए; यदि अपरिहार्य हों, तो हर रिलीज़ में समान रूप से रखिए और आँख से नहीं, स्पष्ट जाँच से पुष्टि कीजिए।
• दोहरे स्पेस और ट्रेलिंग स्पेस देवनागरी में उतने ही घातक हैं जितने कहीं और, और उतने ही अदृश्य।

4.6 लीगेसी फ़ॉन्ट: वह देवनागरी जो देवनागरी है ही नहीं

यह भारतीय स्टूडियो और डिज़ाइन-वर्कफ़्लो की अपनी, बहुत ठोस समस्या है, और इसका ज़िक्र किसी अंतरराष्ट्रीय स्टाइल गाइड में नहीं मिलेगा।

यूनिकोड से पहले हिंदी टेक्स्ट लीगेसी ग्लिफ़-फ़ॉन्ट से लिखा जाता था — कृतिदेव, चाणक्य, शुषा, डीवी-टीटीयामिनी और उनके परिजन। इनमें कोई देवनागरी कोड-पॉइंट होता ही नहीं: फ़ाइल में साधारण ASCII बाइट होते हैं (d, k, र की जगह कुछ और), और फ़ॉन्ट उन बाइटों के ऊपर देवनागरी ग्लिफ़ चिपका देता है। स्क्रीन पर "ग़ज़ल" दिखता है; बाइटों में xtky जैसा कुछ पड़ा है।

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

पहचान का तरीक़ा सरल है: टेक्स्ट को किसी सादे टेक्स्ट एडिटर में या किसी ऐसी जगह चिपकाइए जहाँ आपका देवनागरी फ़ॉन्ट लागू न हो। अगर वह लैटिन अक्षरों में बदल जाता है, तो वह देवनागरी नहीं है। दूसरा तरीक़ा: उस टेक्स्ट में देवनागरी का कोई शब्द खोजिए — अगर खोज विफल होती है जबकि आँख शब्द देख रही है, तो आपके पास ग्लिफ़ हैं, वर्ण नहीं।

करने योग्य: मेटाडेटा कभी आर्टवर्क फ़ाइल से कॉपी मत कीजिए। उल्टा कीजिए — कैननिकल यूनिकोड टेक्स्ट पहले तय कीजिए, और आर्टवर्क उसी से बनवाइए। अगर पुराना टेक्स्ट लीगेसी फ़ॉन्ट में है तो उसे कन्वर्ट कीजिए (कृतिदेव→यूनिकोड कन्वर्टर आम हैं) और कन्वर्ज़न के बाद नुक़्ता तथा अनुस्वार/चंद्रबिंदु की अलग से जाँच कीजिए — यही दो चीज़ें कन्वर्टर सबसे ज़्यादा ग़लत करते हैं।

4.7 फ़ाइल-टैग बनाम डिलीवरी मेटाडेटा

यह भ्रम बहुत आम है: WAV या MP3 फ़ाइल के अंदर लिखे गए टैग वह मेटाडेटा नहीं हैं जो स्टोर पढ़ते हैं। स्टोर आपके डिस्ट्रिब्यूटर की भेजी हुई डिलीवरी (ERN) पढ़ते हैं। फ़ाइल-टैग आपके अपने संगठन के लिए उपयोगी हैं और कभी-कभी डिस्ट्रिब्यूटर के फ़ॉर्म को पहले से भरने के काम आते हैं — पर उन पर भरोसा नहीं किया जा सकता।

फिर भी दो बातें ध्यान देने योग्य हैं। पहली, ID3v1 टैग की कोई यूनिकोड क्षमता नहीं है — वे लैटिन-1 हैं, इसलिए उनमें देवनागरी लिखा ही नहीं जा सकता; अगर आपका DAW या टैगर ID3v1 लिख रहा है तो आपका हिंदी शीर्षक वहाँ प्रश्नचिह्नों में बदल जाएगा। दूसरी, ID3v2 में UTF-8/UTF-16 संभव है, पर एन्कोडिंग बाइट सही सेट होना ज़रूरी है; ग़लत एन्कोडिंग-घोषणा वही "मोजीबेक" पैदा करती है जिसे लोग "फ़ॉन्ट की समस्या" समझते हैं। और तीसरी, जो भारतीय स्टूडियो में लगातार होता है: फ़ाइल-नाम में देवनागरी। कई डिलीवरी पाइपलाइन ग़ैर-ASCII फ़ाइल-नामों पर ठोकर खाती हैं। ऑडियो फ़ाइलों के नाम ASCII में रखिए; देवनागरी फ़ील्डों में रखिए, फ़ाइल-नामों में नहीं।

4.8 हिंदी–उर्दू द्विलिपि समस्या: एक व्यक्ति, तीन प्रोफ़ाइल

यह भारतीय और पाकिस्तानी रिपर्टवा की अपनी समस्या है और इसका कोई तकनीकी हल नहीं है — केवल नीतिगत हल है।

हिंदी और उर्दू बोलचाल के स्तर पर काफ़ी हद तक एक ही भाषा हैं, पर दो लिपियों में लिखी जाती हैं: देवनागरी और नस्तालीक़ (अरबी-आधारित)। ग़ज़ल, क़व्वाली और फ़िल्मी रिपर्टवा दोनों तरफ़ समान रूप से मौजूद है। नतीजा यह होता है कि एक ही गीत और अक्सर एक ही कलाकार तीन रूपों में डिलीवर होता है:

• देवनागरी: फ़ैज़ अली — "साँझ की बाँसुरी"
• नस्तालीक़: فیض علی — "سانجھ کی بانسری"
• रोमन: Faiz Ali — "Saanjh Ki Baansuri"

तीनों वैध हैं। तीनों हर मिलान-प्रणाली के लिए तीन अलग कलाकार हैं। कोई भी स्वचालित प्रणाली यह नहीं जानती कि ये एक ही व्यक्ति हैं, क्योंकि इन स्ट्रिंगों में एक भी साझा बाइट नहीं है।

इसका ठेठ नतीजा वह है जिसे कलाकार "मेरे स्ट्रीम उतने नहीं हैं जितने होने चाहिए" कहकर वर्णित करता है और जिसका कारण उसे कभी नहीं मिलता — क्योंकि हर पेज अकेले देखने पर ठीक लगता है। भारत की देवनागरी रिलीज़ एक पेज पर, पाकिस्तान/खाड़ी की नस्तालीक़ रिलीज़ दूसरे पर, और प्लेलिस्ट-पिच के लिए रोमन में भेजी गई तीसरी रिलीज़ तीसरे पर।

नीति स्पष्ट है और उसे लिखकर रखना चाहिए:

1. एक प्राथमिक लिपि चुनिए — वह जिसमें आपके अधिकांश श्रोता खोजते हैं। यह भाषिक शुद्धता का नहीं, बाज़ार का फ़ैसला है।
2. दूसरी लिपियाँ स्थानीयकरण (localization) फ़ील्डों में रखिए, प्राथमिक फ़ील्ड में नहीं — जहाँ आपका डेटा मॉडल यह देता है। Apple ने यही ढाँचा सिरिलिक के लिए स्पष्ट रूप से लिखा है: "Content in languages that use the Cyrillic alphabet should not be submitted with transliterated titles. Use Cyrillic in the native title field, English in the English localization field, and transliteration in the available phonetic field." यही तर्क देवनागरी–नस्तालीक़–रोमन तिकड़ी पर लागू होता है।
3. एक रोमनीकरण तय कीजिए और कभी मत बदलिए। हिंदी-उर्दू रोमनीकरण व्यवहार में मानकीकृत नहीं है: फ़ैज़ = Faiz, Faez, Fayz, Faiez; ज़ेबा = Zeba, Zeeba; क़ुरैशी = Qureshi, Quraishi, Kureshi। हर रूप बचाव-योग्य है; हर रूप मिलान-प्रणाली के लिए एक अलग कलाकार है। प्राथमिकता-क्रम: कलाकार जो पहले से सार्वजनिक रूप से इस्तेमाल करता है (हैंडल, डोमेन, छपा हुआ कवर) — मौजूदा पदचिह्न के साथ संगति भाषिक शुद्धता से बड़ी है; उसके बाद, जो सबसे बड़ी मौजूदा रिलीज़ पर है; उसके बाद, जो श्रोता वास्तव में टाइप करेगा। शास्त्रीय शुद्धता के डायक्रिटिक (Faiẓ, Qurayshī) सही हैं और अखोज्य हैं।
4. अगर आप दोनों लिपियों में अलग-अलग रिलीज़ करते ही हैं, तो यह सचेत निर्णय होना चाहिए, दुर्घटना नहीं — और तब दोनों पहचानों को एक-दूसरे से जोड़ने का काम आपको प्रचार के स्तर पर करना होगा, क्योंकि सिस्टम नहीं करेंगे।

रोमनीकरण दूसरा कलाकार-नाम है, और जिस कलाकार ने एक नहीं चुना, उसने कई चुन लिए हैं।

4.9 जाँच के लिए

mazufa.com पर एक मुफ़्त मेटाडेटा चेकर उपलब्ध है जो पूरी तरह आपके अपने डिवाइस पर ब्राउज़र में चलता है, कुछ भी अपलोड नहीं करता, और ऊपर के कई अदृश्य मामलों को चिह्नित करता है — मिश्रित अंक-समुच्चय, पूर्वरचित बनाम विघटित नुक़्ता, भटके हुए ZWJ/ZWNJ, ट्रेलिंग स्पेस और ग़ैर-NFC स्ट्रिंग।

5. संकलन, एल्बम-प्रकार और "Various Artists"

भारतीय कैटलॉग में एक विशेष रूप से आम रचना है: कई गायकों वाला संकलन — "ग़ज़ल संध्या", "भजन संग्रह", किसी फ़िल्म का साउंडट्रैक। यहाँ दो नियम काम के हैं।

पहला, रिलीज़-स्तर का प्राथमिक कलाकार और ट्रैक-स्तर का प्राथमिक कलाकार अलग-अलग फ़ील्ड हैं। अगर एक संकलन में चार अलग गायक हैं, तो रिलीज़-स्तर पर "Various Artists" (यही अंग्रेज़ी रूप, अनुवाद नहीं) और हर ट्रैक पर उसका अपना गायक जाता है। रिलीज़-स्तर पर चारों नामों को एक स्ट्रिंग में जोड़ देना — "ज़ेबा क़ुरैशी, आरज़ू सिंह, फ़ैज़ अली और अन्य" — एक ऐसा कलाकार बना देता है जो मौजूद नहीं है, और चारों में से किसी के पेज पर कुछ नहीं जुड़ता।

दूसरा, एल्बम-प्रकार तथ्य है, विपणन नहीं। एक ट्रैक = सिंगल; कुछ ट्रैक = ईपी; पूर्ण-लंबाई = एल्बम। स्टोरों की अपनी सीमाएँ हैं और डिस्ट्रिब्यूटर उन्हें लागू करते हैं। तीन ट्रैक की ईपी को "एल्बम" घोषित करने से कोई लाभ नहीं मिलता और कुछ गंतव्यों पर अस्वीकृति मिलती है।

फ़िल्म साउंडट्रैक की एक अतिरिक्त बारीकी: फ़िल्म का नाम रिलीज़ का शीर्षक हो सकता है, पर वह ट्रैक-शीर्षकों में नहीं घुसना चाहिए। "गीत का नाम (फ़िल्म का नाम से)" जैसा निर्माण उसी श्रेणी में आता है जिसमें "ft." — यह प्रदर्शन-जानकारी है जो पहचान-फ़ील्ड में डाल दी गई है।

6. फ़ीचर्ड आर्टिस्ट: शीर्षक ग़लत जगह है

स्वतंत्र वितरण में सबसे आम नुक़सानदेह प्रविष्टि यह है: शीर्षक फ़ील्ड में आरज़ू सिंह ft. ज़ेबा क़ुरैशी टाइप कर देना और फ़ीचर्ड-आर्टिस्ट भूमिका ख़ाली छोड़ देना।

शीर्षक फ़ील्ड एक प्रदर्शन-स्ट्रिंग है; उसमें कोई पहचान नहीं होती। इसलिए फ़ीचर्ड कलाकार को न श्रेय-लिंक मिलता है, न अपने पेज पर उपस्थिति, न आपके रिकॉर्ड तक वापसी का रास्ता, न एनालिटिक्स में कुछ — जबकि स्टोर "ft. ज़ेबा क़ुरैशी" को गीत के नाम का हिस्सा मान लेता है, और ट्रैक हमेशा के लिए गीत का नाम ft. ज़ेबा क़ुरैशी कहलाता है। नतीजा वह दोहराव है जो पहली नज़र में शौक़िया डिलीवरी की पहचान है।

स्टोर यह साफ़ कहते हैं। Spotify: "You shouldn't include any artists' names in your track or release titles," और प्रोवाइडर दस्तावेज़ में, "Spotify strongly recommends against including additional information, such as references to 'Featured Artists' in track and product titles." Music Biz सलाह देता है कि फ़ीचर्ड कलाकारों को "at the Artist role level and not add this data to the track or album release title" श्रेय दिया जाए।

जहाँ अनुबंध शीर्षक में बिलिंग की माँग करता है, वहाँ परंपरा एकसमान है। Music Biz, "feat." और "with" पर: "when included in the title are generally lowercase and in English." Apple: "Formatting of 'feat.' and 'with' must be lowercase, in English, not localized, and in parentheses or brackets."

वह "not localized" निर्देश यहाँ बेहद अहम है: शीर्षक फ़ील्ड में "feat." का हिंदी अनुवाद मत कीजिए। "(के साथ)", "(फ़ीट.)", "(सह-गायन)" — ये सब ग़लत हैं। "feat." एक मशीन-पठनीय टोकन है, शब्द नहीं।

सही ढाँचा: शीर्षक फ़ील्ड में केवल गीत का नाम, और हर कलाकार अपनी भूमिका-फ़ील्ड में — फिर स्टोर ख़ुद वह "(feat....)" प्रदर्शन बना देता है जो आप चाहते थे। भूमिकाएँ पहचान हैं, शीर्षक प्रदर्शन; प्रदर्शन-फ़ील्ड में पहचान डालने से पहचान नष्ट होती है और प्रदर्शन भी बिगड़ता है।

7. संस्करण और उपशीर्षक

संस्करण फ़ील्ड का काम केवल इतना है कि एक ही शीर्षक साझा करने वाली दो रिकॉर्डिंगों को अलग किया जा सके। यही उसे भरने की कसौटी भी है। शब्दावली स्थिर है: Radio Edit, Extended Mix, Live, Acoustic, Instrumental, Single Version, Alternate Take, Demo, Remastered, और नामित रीमिक्स Artist Name Remix के रूप में। Apple: "To differentiate multiple versions of the same track title, use terms in parentheses or brackets such as: Alternate Take...Live, Instrumental, Single Version, Radio Edit." विराम-चिह्न पर Music Biz कहता है कि पहले कोष्ठक और आगे के विवरण के लिए वर्ग-कोष्ठक इस्तेमाल कीजिए।

"Radio Edit" का अर्थ "साफ़ वाला संस्करण" नहीं है। Music Biz इसे उसी संस्करण के लिए रखता है जो सचमुच प्रसारण के लिए तैयार किया गया हो, और सामग्री-संपादन के लिए "Edited Version" कहने को कहता है। Radio Edit सामान्यतः लंबाई का संपादन है; Edited Version सामग्री का।

"Original Mix" हर जगह सुरक्षित नहीं है, और यह स्टोरों के बीच एक असली मतभेद है। Apple की प्रकाशित गाइड इसे मना करती है: "The standard, original version of an album, track, or music video must not include any additional information in the title unless it is needed to identify the content," और अस्वीकृत शब्दों में गिनाती है "Exclusive, Limited Edition, Album Version, Original Mix, Tone, Alert Tone...Dolby Atmos, lossless, high-resolution audio." Spotify की सार्वजनिक मेटाडेटा गाइडेंस "Original Mix" का नाम लेकर कोई नियम प्रकाशित नहीं करती; उसकी प्रकाशित स्थिति वही सामान्य है कि शीर्षकों में अतिरिक्त जानकारी नहीं होनी चाहिए। Apple की प्रकाशित गाइड "Original Mix" को स्पष्ट रूप से मना करती है; अन्य सेवाएँ इस पर कोई नियम प्रकाशित नहीं करतीं, और व्यवहार स्टोर-दर-स्टोर तथा आपके डिस्ट्रिब्यूटर की अपनी पूर्व-जाँच के अनुसार बदलता है।

एक और बात जो देवनागरी में विशेष रूप से लागू होती है: संस्करण को शीर्षक में हाथ से मत लिखिए। अगर आप शीर्षक फ़ील्ड में "बिरहा की रात (लाइव)" लिखते हैं और संस्करण फ़ील्ड में "Live" भी भरते हैं, तो जो स्टोर अपनी प्रदर्शन-स्ट्रिंग ख़ुद बनाते हैं वे बिरहा की रात (लाइव) (Live) दिखाएँगे। एक जगह चुनिए — संस्करण फ़ील्ड।

8. फ़िल्मी क्रेडिट: पार्श्व गायक, संगीतकार, गीतकार

यह वह जगह है जहाँ भारतीय रिपर्टवा सबसे नियमित रूप से पैसा खोता है, और कारण संरचनात्मक है।

फ़िल्मी परंपरा में एक गीत के पीछे कम से कम तीन अलग-अलग भूमिकाएँ होती हैं, और तीनों का अलग क़ानूनी दर्जा है:

• पार्श्व गायक (playback singer) — यह रिकॉर्डिंग का कलाकार है। यह प्राथमिक कलाकार फ़ील्ड में जाता है (या फ़ीचर्ड, अगर बिलिंग वैसी है)। यह आर्टिस्ट पेज पाता है।
• संगीतकार (music director / composer) — यह कृति का रचयिता है। यह composer फ़ील्ड में जाता है। इसे आर्टिस्ट पेज नहीं मिलता; इसे पब्लिशिंग रॉयल्टी मिलती है।
• गीतकार (lyricist) — यह भी कृति का रचयिता है, शब्दों का। यह lyricist फ़ील्ड में जाता है, composer फ़ील्ड में नहीं।

जो नुक़सान होता है वह बहुत विशिष्ट है। तीन प्रचलित ग़लतियाँ:

1. संगीतकार को प्राथमिक कलाकार बना देना। यह सुनने में तार्किक लगता है — भारत में एल्बम अक्सर संगीतकार के नाम से बिकते हैं — पर इसका मतलब यह है कि गायक को उसके अपने प्रदर्शन का श्रेय नहीं मिलता, और संगीतकार के पेज पर वे रिकॉर्डिंग जुड़ती हैं जिनमें उसने गाया ही नहीं। एक गायक का पूरा कैटलॉग इस तरह अदृश्य हो सकता है।
2. संगीतकार और गीतकार को एक ही खाने में ठूँस देना — "संगीत और गीत: पंडित रघुवीर मिश्र / इमरान फ़ारूक़ी" एक स्ट्रिंग में। अधिकार-समितियाँ लेखक के पंजीकृत नाम पर मिलान करती हैं; एक संयुक्त स्ट्रिंग किसी से मेल नहीं खाती, और दोनों हिस्से बिना मिलान के रह जाते हैं।
3. दोनों को ख़ाली छोड़ देना। यह सबसे आम है, क्योंकि रिलीज़ इसके बावजूद स्वीकृत हो जाती है और सामान्य रूप से स्ट्रीम होती है। स्टोर के मुखपृष्ठ पर कुछ भी ग़लत नहीं दिखता। पब्लिशिंग रॉयल्टी बस कभी नहीं आती।

इसके साथ बाक़ी क्रेडिट-अनुशासन भी जुड़ता है:

• संगीतकार और गीतकार में मंच-नाम नहीं, क़ानूनी नाम जाते हैं। "डीजे फ़ैज़" कोई लेखक नहीं है; उसके पीछे का व्यक्ति है।
• हर लेखक सूचीबद्ध हो, चाहे उसने एक पंक्ति लिखी हो। छूटा हुआ लेखक छूटा हुआ श्रेय नहीं, बिना-मिलान वाला हिस्सा है।
• स्प्लिट का योग 100% हो और वह रिलीज़ से पहले लिखित में तय हो। मेटाडेटा एक समझौते को व्यक्त करता है; समझौता न हो तो वह एक अनुमान है जिस पर बाद में विवाद होता है।
• पारंपरिक और सार्वजनिक-डोमेन रचनाओं के भी लेखक होते हैं — व्यवस्थापक (arranger)। ठुमरी, भजन और लोक-धुनों को केवल "पारंपरिक / Traditional" लिखकर भेजना उस आय को छोड़ देना है। अगर आपने बंदिश की व्यवस्था की है, तो व्यवस्था आपकी है।
• रीमिक्स रचना नहीं बदलता। मूल लेखक ही लेखक रहते हैं, जब तक रीमिक्स में नई रचना न जुड़े — और वह एक बातचीत का विषय है, अनुमान का नहीं।
• वाद्य-कलाकार (तबला, हारमोनियम, सारंगी, बाँसुरी) योगदानकर्ता भूमिकाओं में जाते हैं। ये पेज नहीं बनाते और रिकॉर्डिंग-पक्ष का भुगतान नहीं लाते, पर ये वही जानकारी है जिससे शास्त्रीय और अर्ध-शास्त्रीय कैटलॉग खोजे जाते हैं।

रिकॉर्डिंग-रॉयल्टी शोर मचाकर विफल होती है, पब्लिशिंग-रॉयल्टी चुपचाप: बँटा हुआ आर्टिस्ट पेज एक दिन में दिख जाता है, बिना-मिलान वाली कृति बरसों तक नहीं।

9. क्या-क्या वाक़ई रिजेक्ट होता है — और डिलीवरी से पहले की जाँच-सूची

1. शीर्षक फ़ील्ड में कलाकार के नाम — "ft.", "feat.", "with", या शीर्षक में टाइप किया हुआ रीमिक्सर का नाम जबकि भूमिका-फ़ील्ड ख़ाली है (खंड 6)।
2. शीर्षक में एक्सप्लिसिट/क्लीन शब्द — "(Explicit)", "(Clean)", "(साफ़ संस्करण)"। फ़्लैग इस्तेमाल कीजिए।
3. शीर्षक में प्रचारात्मक या वर्णनात्मक टेक्स्ट — "Exclusive", "Limited Edition", "Album Version", "Original Mix", या "Dolby Atmos" और "lossless" जैसे फ़ॉर्मैट-दावे, जो सब Apple की गाइड में नामित हैं।
4. केसिंग का उल्लंघन — रोमन शीर्षकों में पूरे बड़े अक्षर, पूरे छोटे अक्षर, या मनमाना केस, जब तक वह वास्तविक और सुसंगत कलात्मक निर्णय न हो। (देवनागरी में केस होता ही नहीं — हमने जाँचा, 'ग़ज़ल'.upper() वही स्ट्रिंग लौटाता है — इसलिए यह नियम केवल आपके रोमनीकरण पर लागू है, पर वहाँ लागू है।)
5. आर्टवर्क से न मिलता मेटाडेटा — कवर पर लिखा शीर्षक, कलाकार और संस्करण फ़ील्ड से अक्षरशः मेल खाना चाहिए। देवनागरी में यहीं अनुस्वार/चंद्रबिंदु का फ़र्क़ पकड़ा जाता है।
6. ग़लत या ख़ाली भाषा-फ़ील्ड, विशेष रूप से ग़ैर-लैटिन रिलीज़ पर शीर्षक-भाषा।
7. संगीतकार या गीतकार का न होना, जिसे कुछ गंतव्य सीधे अस्वीकार कर देते हैं।
8. वर्जित वर्ण — इमोजी, सजावटी प्रतीक, दोहरे स्पेस, भटके हुए अदृश्य वर्ण (ZWJ/ZWNJ यहीं आते हैं)।
9. ग़लत पहचान-संख्याएँ — भौतिक रूप से भिन्न रिकॉर्डिंग पर दोबारा इस्तेमाल किया गया ISRC, या ऐसा UPC जो अपना चेक डिजिट पास न करे।
10. मौजूदा कैटलॉग से असंगत कलाकार-नाम — जो अक्सर रिजेक्ट होता ही नहीं, और इसीलिए इस सूची की सबसे नुक़सानदेह मद है।

डिलीवरी से पहले की दिनचर्या। कलाकार-स्ट्रिंग टाइप करने के बजाय पेस्ट कीजिए; पुष्टि कीजिए कि हर शीर्षक फ़ील्ड में केवल गीत का नाम है; पुष्टि कीजिए कि हर भूमिका के लिए एक फ़ील्ड है और हर फ़ील्ड के लिए एक भूमिका; NFC में सामान्यीकृत कीजिए और अलग से जाँचिए कि नुक़्ता-रूप पूरे कैटलॉग में एकसमान है (क्योंकि सामान्यीकरण यहाँ आपको जो देगा वह विघटित रूप है, पूर्वरचित नहीं); अंक-समुच्चय तय कीजिए; अनुस्वार/चंद्रबिंदु वर्तनी-नीति लागू कीजिए; अदृश्य वर्ण हटाइए; दोनों भाषा-फ़ील्ड भरिए; P-लाइन और C-लाइन अलग-अलग जाँचिए; यह पहली रिलीज़ न हो तो मूल रिलीज़ तिथि दीजिए; और आर्टवर्क को फ़ील्डों से वर्ण-दर-वर्ण मिलाइए।

हर अस्वीकृति सस्ती है; महँगी वे त्रुटियाँ हैं जो जाँच पास कर जाती हैं।

10. सारांश

• मेटाडेटा तीन परतों पर दर्ज होता है — रिलीज़, रिकॉर्डिंग, कृति — और अधिकांश महँगी ग़लतियाँ ग़लत परत पर दर्ज सही तथ्य होती हैं। कलाकार का नाम एक कुंजी है, लेबल नहीं; भूमिकाएँ पहचान हैं, शीर्षक प्रदर्शन।
• देवनागरी में बाइट-स्ट्रिंग और प्रदर्शन अलग-अलग तरीक़ों से विफल होते हैं और आँख किसी का ऑडिट नहीं कर सकती: पूर्वरचित बनाम विघटित नुक़्ता (और यह याद रखते हुए कि U+0958–U+095F चारों सामान्यीकरण रूपों में टूटते हैं, जुड़ते नहीं), अनुस्वार बनाम चंद्रबिंदु बनाम संयुक्त नासिक्य, मात्रा-क्रम, और देवनागरी बनाम ASCII अंक — इनमें से हर एक अकेले ही एक कलाकार को दो में बाँट सकता है।
• हिंदी–उर्दू लिपि-द्वैत तकनीकी नहीं, नीतिगत समस्या है: एक प्राथमिक लिपि, एक स्थिर रोमनीकरण, और बाक़ी सब स्थानीयकरण फ़ील्डों में।
• संगीतकार और गीतकार वे खाने हैं जिनसे पब्लिशिंग का पैसा ट्रेस होता है, और वे बिना किसी लक्षण के विफल होते हैं। फ़िल्मी रिपर्टवा में इन्हें मिलाकर लिखना या छोड़ देना सबसे महँगी चुप्पी है।

Mazufa पर वितरण निःशुल्क है — कोई अपलोड शुल्क नहीं, कोई सब्सक्रिप्शन नहीं, प्रति-रिलीज़ कोई शुल्क नहीं; एकमात्र कटौती प्राप्त रॉयल्टी का 5% है, और हर पूर्ण आवेदन की समीक्षा एक व्यक्ति करता है।

स्रोत

• Unicode Standard Annex #15, Unicode Normalization Forms — विशेष रूप से §5 Composition Exclusion — https://www.unicode.org/reports/tr15/
• Unicode Character Database, CompositionExclusions.txt (U+0958–U+095F की सूची, 2026-09-07 को सत्यापित) — https://www.unicode.org/Public/UCD/latest/ucd/CompositionExclusions.txt
• Unicode Character Database — वर्ण-गुण: कैननिकल विघटन, कंबाइनिंग क्लास, संख्यात्मक मान — https://www.unicode.org/ucd/
• Unicode Standard Annex #9, Unicode Bidirectional Algorithm (देवनागरी पर लागू नहीं, पर नस्तालीक़ समकक्ष के लिए) — https://www.unicode.org/reports/tr9/
• Music Business Association, Music Metadata Style Guide v2.1 — https://www.musicbiz.org/wp-content/uploads/2016/04/MusicMetadataStyleGuide_V2.1.pdf
• Apple Music Style Guide — https://help.apple.com/itc/musicstyleguide/en.lproj/static.html
• Spotify for Artists, Music metadata guidelines — https://support.spotify.com/us/artists/article/metadata-formatting-guidelines/
• Spotify Provider Support, Featured artist in a product or track title — https://providersupport.spotify.com/article/featured-artist-in-a-product-or-track-title
• DDEX, Standards (Electronic Release Notification Message Suite, ERN सहित) — https://ddex.net/standards/
• IFPI, International Standard Recording Code (ISRC) Handbook (§A.10.1, रीमास्टरिंग और creative input) — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf

जो प्रकाशित नहीं है, उसकी सीमा पर। यहाँ बताया गया हर स्टोर-नियम उसी स्टोर के सार्वजनिक दस्तावेज़ से उद्धृत है। तीन चीज़ें जो कलाकारों को नियमित रूप से तथ्य की तरह बताई जाती हैं, किसी सेवा द्वारा प्रकाशित नहीं हैं और यहाँ दावे के रूप में नहीं कही गई हैं: आर्टिस्ट-पेज मर्ज के लिए आवश्यक सीमाएँ और प्रमाण; वह आंतरिक मिलान-तर्क जो तय करता है कि कोई डिलीवरी मौजूदा कलाकार से जुड़ेगी या नया कलाकार बनाएगी; और Apple के नामित निषेध से आगे, "Original Mix" पर हर स्टोर का बर्ताव। देवनागरी मेटाडेटा त्रुटि-दर का कोई प्रकाशित माप भी, हमारी जानकारी में, कहीं मौजूद नहीं है।