म्यूज़िक मेटाडेटा की पूरी समझ: पहली बार में ही सही कीजिए

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

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

यह गाइड उन फ़ील्ड को देखती है जो सचमुच चीज़ें बिगाड़ते हैं, वे क्यों बिगड़ते हैं, और इसके बजाय क्या करना चाहिए।

वह एक नियम जो बाक़ी सब नियमों के नीचे है

स्टोर और सेवाएँ आपका इरादा नहीं पढ़तीं। वे स्ट्रिंग पढ़ती हैं। दो प्रविष्टियाँ या तो मेल खाती हैं या नहीं, और "काफ़ी हद तक सही" का मतलब "अलग" ही निकलता है।

यह अकेला तंत्र मेटाडेटा की लगभग हर नाकामी समझा देता है। "DJ Sameer" और "DJ Sameer" (दो स्पेस) अलग-अलग कलाकार हैं। "Nadia Rahman" और "Nadia Rehman" किसी पब्लिशर की प्रणाली के लिए अलग-अलग लोग हैं। बिना ISRC के डिलीवर हुए ट्रैक को आगे कहीं कोई कोड मिल जाता है, और अब वही रिकॉर्डिंग दो पहचानकर्ता और दो रॉयल्टी रास्ते ढोती है।

तो व्यावहारिक अनुशासन "सावधानी बरतिए" नहीं है। वह यह है: हर बार-बार आने वाले नाम और कोड का सही रूप एक बार तय कीजिए, उसे लिख लीजिए, और हर रिलीज़ के लिए हमेशा उसी लिखित रिकॉर्ड का इस्तेमाल कीजिए।

आर्टिस्ट नाम: एक स्ट्रिंग चुनिए और उसे कभी मत बदलिए

आपका आर्टिस्ट नाम वह मुख्य कुंजी है जो आपके पूरे कैटलॉग को जोड़े रखती है। कैपिटलाइज़ेशन बदलना, "The" जोड़ना या हटाना, हाइफ़न की जगह एन डैश लगाना, या किसी आद्याक्षर के बाद बिंदु जोड़ना — इतना भी दूसरी प्रोफ़ाइल बना देने के लिए काफ़ी हो सकता है।

पहली रिलीज़ से पहले क्या तय कर लें:

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

अगर आपकी रिलीज़ें पहले से दो प्रोफ़ाइलों में बँटी हैं, तो इलाज प्रभावित रिलीज़ों के लिए अपने डिस्ट्रीब्यूटर को भेजा गया सुधार अनुरोध है, न कि "सही" स्पेलिंग के साथ नई रिलीज़।

शीर्षक: मेटाडेटा आर्टवर्क की कॉपी नहीं है

शीर्षक फ़ील्ड कैटलॉग फ़ील्ड है, मार्केटिंग लाइन नहीं। आम अस्वीकृतियाँ और उनकी वजहें:

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

यहाँ सबसे ज़्यादा फ़ायदे वाला सुधार फ़ीचर्ड आर्टिस्ट का है। फ़ीचर को शीर्षक स्ट्रिंग के बजाय आर्टिस्ट फ़ील्ड में डालने से ही ट्रैक फ़ीचर्ड आर्टिस्ट की प्रोफ़ाइल पर दिखता है और उनके दर्शकों तक पहुँचता है। शीर्षक में टाइप कर देने पर वह बस सजावट है।

क्रेडिट: क़ानूनी नाम, हैंडल नहीं

गीतकार और प्रोड्यूसर क्रेडिट पब्लिशिंग का पैसा ढोते हैं। पब्लिशिंग का प्रबंधन उन सोसाइटियों और पब्लिशरों के हाथ है जिनकी प्रणालियाँ क़ानूनी नामों और पंजीकृत लेखक पहचानकर्ताओं पर मिलान करती हैं — किसी बीट टैग पर छपे नाम पर नहीं।

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

पहचानकर्ताओं के बीच का फ़र्क़ ध्यान रखिए: ISRC रिकॉर्डिंग की पहचान है, ISWC रचना की, और UPC रिलीज़ की। ये तीन अलग चीज़ें हैं और एक दूसरे की जगह नहीं ले सकतीं।

कोड: ISRC और UPC

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

नया ISRC तब ज़रूरी है जब रिकॉर्डिंग सचमुच अलग हो: रीमिक्स, एडिट, लाइव वर्ज़न, इंस्ट्रुमेंटल। वही रिकॉर्डिंग दोबारा रिलीज़ करने के लिए नहीं चाहिए, और डिस्ट्रीब्यूटर बदलने पर ISRC रिकॉर्डिंग के साथ ही रहता है।

रीमास्टर का दायरा ज़्यादातर सलाहों के सुझाव से संकरा है। IFPI ISRC हैंडबुक (§A.10.1) कहती है कि नया ISRC तभी और सिर्फ़ तभी दिया जाता है जब रीमास्टरिंग में रिकॉर्डिंग पर ही रचनात्मक योगदान लगा हो। वह साफ़ तौर पर सामान्य स्तर परिवर्तन, अपरिवर्ती EQ, अपरिवर्ती कंप्रेशन, डी-नॉइज़िंग, डी-क्लिकिंग, गति और पिच सुधार, सैंपल-रेट रूपांतरण तथा डिदरिंग को बाहर रखती है — इन्हें "मूलतः अपरिवर्ती या तकनीकी समायोजन प्रक्रियाएँ" कहा गया है। एक शर्त हर हाल में सुरक्षित है: जहाँ रीमास्टर किया गया वर्ज़न मूल के साथ अपने अलग ट्रैक के तौर पर बिक्री पर जाता है, वहाँ आप दो उत्पाद बेच रहे हैं, और दूसरा अपना अलग कोड लेता है।

UPC रिलीज़ की पहचान है, रिकॉर्डिंग की नहीं। UPC-A 12 अंकों का है; EAN-13 13 अंकों का। आगे एक शून्य लगाने से UPC-A, EAN-13 बन जाता है, और चेक डिजिट नहीं बदलता। वह चेक डिजिट निकाला जा सकता है: दाएँ से शुरू करके उससे पहले के अंकों को बारी-बारी 3 और 1 से गुणा कीजिए, उन्हें जोड़िए, और चेक डिजिट वही है जो कुल को दस के अगले गुणज तक पहुँचा दे। ग़लत चेक डिजिट वाला UPC ऐसी टाइपिंग ग़लती है जिसे आप ख़ुद पकड़ सकते हैं — आप इसे ब्राउज़र में ISRC और UPC चेकर से जाँच सकते हैं।

ग़ैर-लैटिन लिपि और मिश्रित दिशा वाला टेक्स्ट

अगर आपका मेटाडेटा अरबी, फ़ारसी, उर्दू, हिब्रू या किसी भी दाएँ-से-बाएँ लिपि में है, तो सबसे आम गड़बड़ी एनकोडिंग नहीं है — वह द्विदिशीय टेक्स्ट है। जब किसी RTL स्ट्रिंग में लैटिन टोकन मिलते हैं तो Unicode द्विदिशीय एल्गोरिदम (UAX #9) प्रदर्शन का क्रम तय करता है, और किसी अरबी शीर्षक में डाला गया लैटिन शब्द, कोई संख्या या कोष्ठक वाला वर्ज़न टैग वहाँ नहीं दिख सकता जहाँ आपने टाइप किया था।

व्यावहारिक बचाव:

• जहाँ तक हो सके एक ही फ़ील्ड के भीतर लिपि एक जैसी रखिए।
• देखिए कि स्ट्रिंग सादे RTL संदर्भ में कैसी रेंडर होती है, सिर्फ़ अपने DAW या स्प्रेडशीट में नहीं।
• जहाँ स्टोर ट्रांसलिटरेशन के लिए अलग फ़ील्ड देता है वहाँ वह दीजिए, एक ही शीर्षक के भीतर लिपियाँ मत मिलाइए।
• फ़ील्ड परंपराओं के उद्योग संदर्भ के तौर पर Music Biz Metadata Style Guide का पालन कीजिए।

जॉनर, भाषा और एक्सप्लिसिट फ़्लैग

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

रिलीज़-पूर्व चेकलिस्ट

हर डिलीवरी से पहले यह चलाइए:

• आर्टिस्ट नाम आपके लिखित रिकॉर्ड से अक्षर-दर-अक्षर मेल खाता है, स्पेसिंग समेत।
• फ़ीचर्ड आर्टिस्ट आर्टिस्ट फ़ील्ड में हैं, शीर्षक में नहीं।
• शीर्षकों में कोई प्रचार टेक्स्ट नहीं, कोई "(Official Audio)" नहीं, कोई इमोजी नहीं, कोई ग़ैर-ज़रूरी कैप्स नहीं।
• वर्ज़न टैग सिर्फ़ वहीं मौजूद हैं जहाँ दूसरा वर्ज़न सचमुच है।
• हर गीतकार अपने क़ानूनी नाम से सूचीबद्ध है, और हिस्सेदारी लिखित में तय है।
• ISRC 12 अक्षरों का है, इसी ख़ास रिकॉर्डिंग के लिए सही है, और दोबारा सिर्फ़ तभी इस्तेमाल हुआ है जब रिकॉर्डिंग अपरिवर्तित हो।
• UPC का चेक डिजिट सही निकलता है, और वह UPC सिर्फ़ इसी रिलीज़ का है।
• भाषा, जॉनर और एक्सप्लिसिट फ़्लैग असली सामग्री को दर्शाते हैं।
• ग़ैर-लैटिन फ़ील्ड RTL संदर्भ में सही रेंडर होते हैं, बिना किसी फ़ालतू लैटिन टोकन के।

आप पूरे समूह को स्टोर के शैली नियमों के मुक़ाबले मेटाडेटा चेकर से जाँच सकते हैं — यह आपके ब्राउज़र में चलता है और कोई ऑडियो अपलोड नहीं होता — और फ़ील्ड-दर-फ़ील्ड परंपराएँ मेटाडेटा संदर्भ में दर्ज हैं।

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