पहचान-कोड की ज़्यादातर समस्याएँ मुश्किल नहीं होतीं। बस उन्हें इतनी बार ग़लत दोहराया जाता है कि सब उन पर यक़ीन करने लगते हैं। सबसे महँगी पड़ने वाली बात यह दावा है कि रीमास्टर को हमेशा नया ISRC चाहिए। IFPI ISRC Handbook साफ़ शब्दों में इसका उल्टा कहती है, और आम सलाह पर चलने से ही किसी कैटलॉग के दो कोड में बँट जाने और उसकी स्ट्रीम गिनती तथा रॉयल्टी के दोनों में बँट जाने की नौबत आती है।
बात उन तीन पहचान-कोड की है जो एक रिलीज़ पर बैठते हैं — हर एक असल में किसका नाम है, और आपको दिए गए बारकोड को किसी की बात पर भरोसा किए बिना कैसे जाँचा जाए।
ISRC 12 वर्णों का होता है, और हाइफ़न उसका हिस्सा नहीं हैं
ISRC 12 वर्णों का होता है, चार खंडों में:
| खंड | लंबाई | उदाहरण |
|---|---|---|
| देश | 2 | QZ |
| रजिस्ट्रेंट | 3 | NWX |
| संदर्भ वर्ष | 2 | 26 |
| पदनाम | 5 | 00147 |
विभाजकों के साथ लिखने पर यह QZ-NWX-26-00147 बनता है। जैसे यह असल में संग्रहीत होता है, वैसे लिखने पर यह QZNWX2600147 है।
हाइफ़न सिर्फ़ दिखाने की परिपाटी हैं। वे कोड का हिस्सा नहीं हैं। जो डिलीवरी स्पेक बारह वर्ण माँगता है, उसे बारह ही वर्ण चाहिए, और वर्ण गिनने वाले फ़ील्ड में हाइफ़न वाला रूप चिपका देना वैलिडेशन में फ़ेल होने के सबसे उबाऊ तरीक़ों में से एक है। हर जगह बिना-हाइफ़न वाला रूप रखिए और हाइफ़न सिर्फ़ तब जोड़िए जब उसे कोई इंसान पढ़ने वाला हो।
दूसरी जानने लायक बात यह है कि ISRC में क्या नहीं होता: ISRC में कोई चेक डिजिट नहीं होता। कोड के भीतर कुछ भी कोड को जाँचता नहीं। अगर आप एक वर्ण ग़लत टाइप कर दें, तो नतीजा फिर भी ढाँचे के हिसाब से वैध ISRC ही रहेगा — बस अब वह किसी दूसरी रिकॉर्डिंग की ओर इशारा करेगा, या किसी की भी नहीं। बारकोड ख़ुद की जाँच रखते हैं। ISRC नहीं रखते। यह असमानता समझ लेने लायक है, क्योंकि यही तय करती है कि हाथ से नक़ल करते समय किसमें कितनी सावधानी चाहिए।
तीन पहचान-कोड, तीन अलग चीज़ें
बातचीत में इन्हें आपस में बदलकर इस्तेमाल कर लिया जाता है, जबकि ये बिलकुल भी अदल-बदल नहीं किए जा सकते।
- ISRC रिकॉर्डिंग की पहचान करता है। एक ख़ास स्थिर प्रस्तुति, जैसी रिकॉर्ड हुई।
- ISWC गीत की पहचान करता है — अंतर्निहित रचना, वह चीज़ जो कोई रचनाकार लिखता है।
- UPC रिलीज़ की पहचान करता है — वह उत्पाद जो आप बिक्री पर रखते हैं।
तो एक गीत का एक ISWC होता है और उसके बीस ISRC हो सकते हैं, हर रिकॉर्डिंग के लिए एक। एक ही रिकॉर्डिंग एक ISRC रखती है और सिंगल, एल्बम तथा कंपाइलेशन — तीनों पर आ सकती है: तीन UPC, एक ISRC, तीनों जगह अपरिवर्तित।
व्यावहारिक नतीजा: अगर आपकी स्ट्रीम या रॉयल्टी ग़लत जगह पहुँच रही हैं, तो पहला सवाल यह है कि तीनों में से कौन-सा पहचान-कोड ग़लत है, क्योंकि हर एक को शृंखला का अलग हिस्सा पढ़ता है।
असल में नया ISRC किन बातों पर चाहिए
नया ISRC तब चाहिए जब रिकॉर्डिंग सारभूत रूप से अलग हो। यानी:
- कोई रीमिक्स
- कोई एडिट
- कोई लाइव वर्ज़न
- कोई इंस्ट्रुमेंटल
इनमें से कोई भी एक अलग रिकॉर्डिंग है, और उसे अपना कोड चाहिए।
उसी रिकॉर्डिंग के दोबारा रिलीज़ होने पर नया ISRC नहीं चाहिए। वही ऑडियो, नई रिलीज़ तारीख़, नया आर्टवर्क, नया लेबल, नया डिस्ट्रिब्यूटर — रिकॉर्डिंग नहीं बदली, इसलिए पहचान-कोड भी नहीं बदलता।
इस आख़िरी बात का सीधा व्यावसायिक नतीजा है। डिस्ट्रिब्यूटर बदलने पर ISRC रिकॉर्डिंग के साथ ही रहता है। वह डिस्ट्रिब्यूटर की संपत्ति नहीं है और आपके उनसे रिश्ते के ख़त्म होने पर वह ख़त्म नहीं होता। अगर आप जगह बदलते हैं, तो कोड रिकॉर्डिंग के साथ चलता है, और उसे नए कोड के तहत फिर से रजिस्टर करना पुराने कोड से जुड़ा इतिहास खोने का तरीक़ा है, कोई साफ़-सफ़ाई का क़दम नहीं।
रीमास्टर का नियम, जैसा वह असल में लिखा है
यही वह हिस्सा है जिसे ज़्यादातर गाइड ग़लत बताती हैं।
IFPI ISRC Handbook, §A.10.1 में कहती है कि "A new ISRC shall be assigned if (and only if) the processes applied to a recording during re-mastering involve the application of creative input to the recording itself."
"if and only if" को ध्यान से पढ़िए। कसौटी है रिकॉर्डिंग में ही रचनात्मक इनपुट। मेहनत नहीं, लागत नहीं, यह तथ्य नहीं कि कोई इंजीनियर शामिल था, और यह भी नहीं कि बाद में फ़ाइल अलग है।
Handbook इसके आगे जाकर यह भी बताती है कि क्या-क्या नहीं गिना जाएगा। वह स्पष्ट रूप से इन्हें बाहर रखती है:
- सामान्य लेवल बदलाव
- अपरिवर्ती (invariant) EQ
- अपरिवर्ती कंप्रेशन
- डी-नॉइज़िंग
- डी-क्लिकिंग
- स्पीड और पिच सुधार
- सैंपल-रेट बदलाव
- डिदरिंग
और वह सीधे-सीधे कहती है: "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes."
यह सूची उस ज़्यादातर काम को समेट लेती है जो किसी बैक कैटलॉग को स्ट्रीमिंग के लिए तैयार करते समय किया जाता है। लाउडनेस नॉर्मलाइज़ेशन के लिए 2011 के किसी मास्टर को नीचे लाना, टेप ट्रांसफ़र से आई क्लिक साफ़ करना, किसी दूसरी रेट पर रीसैंपल करना, डिलीवरी फ़ॉर्मैट के रास्ते में डिदरिंग करना — §A.10.1 के तहत इनमें से कुछ भी रचनात्मक इनपुट नहीं है। इसलिए न यह लिखिए और न यह मानिए कि रीमास्टर को हमेशा नया ISRC चाहिए। ज़्यादातर बार नहीं चाहिए।
उस सूची में असली काम जो शब्द कर रहा है वह है अपरिवर्ती। पूरी रिकॉर्डिंग पर एकसमान लगाया गया EQ कर्व एक तकनीकी समायोजन है। रिकॉर्डिंग के भीतर फ़ैसले लेता कोई व्यक्ति — हिस्सों के साथ अलग-अलग बर्ताव करता, अपने विवेक से तत्वों को फिर संतुलित करता — रेखा के दूसरी तरफ़ है। अगर जो किया गया उसे आप एक सेटिंग के रूप में बता सकते हैं, न कि फ़ैसलों की एक शृंखला के रूप में, तो वह लगभग निश्चित रूप से अपरिवर्ती है।
एक सुरक्षित व्यावहारिक अपवाद
एक स्थिति ऐसी है जहाँ आपको नया ISRC देना चाहिए, भले ही प्रोसेसिंग ख़ुद अपरिवर्ती लगे, और वह तकनीकी नहीं बल्कि व्यावसायिक स्थिति है।
अगर रीमास्टर मूल के साथ-साथ एक अलग ट्रैक के रूप में बेचा जाता है, तो वह अलग उत्पाद है और उसे अपना कोड चाहिए।
यही वह अपवाद है, और इसे कहना सुरक्षित है। अगर कोई श्रोता एक ही स्टोर में दोनों वर्ज़न देख सकता है और उनमें से चुन सकता है, तो दो चीज़ें बेची जा रही हैं, और जो दो चीज़ें बेची जा रही हों उन्हें गिनने वाले सिस्टम के लिए अलग-अलग पहचानना ज़रूरी है। अगर रीमास्टर मूल की जगह ही ले लेता है — वही कैटलॉग स्लॉट, पुराना वर्ज़न हटा दिया गया — तो §A.10.1 लागू होता है और, रचनात्मक इनपुट न होने पर, कोड वही रहता है।
उस अपवाद से आगे सब कुछ विवेक का मामला है, और ईमानदार जवाब यह है कि Handbook की कसौटी ही कसौटी है। संदेह हो तो एक वाक्य में लिख डालिए कि ऑडियो के साथ असल में क्या किया गया। अगर उस वाक्य में सिर्फ़ बहिष्कार-सूची की चीज़ें हैं, तो आपका जवाब आपके पास है।
UPC और EAN: 12 अंक, 13 अंक, एक चेक डिजिट
रिलीज़ पर लगा बारकोड रिलीज़ की — यानी उत्पाद की — पहचान करता है, रिकॉर्डिंग की नहीं।
UPC-A 12 अंकों का है। EAN-13 13 अंकों का। ये दो अलग नंबरिंग प्रणालियाँ नहीं हैं जिनके बीच रूपांतरण करना पड़े। UPC-A के आगे एक शून्य लगाने से वह EAN-13 बन जाता है, और चेक डिजिट नहीं बदलता।
यह दो बार कहने लायक है क्योंकि इसी से बहुत सारी अनावश्यक घबराहट पैदा होती है। अगर किसी डिस्ट्रिब्यूटर का फ़ॉर्म 13 अंकों का EAN माँगता है और आपके पास 12 अंकों का UPC है, तो आप उसके आगे एक शून्य लगा देते हैं। आप कुछ भी दोबारा नहीं गिनते। आपके पास पहले से जो आख़िरी अंक है, वह अब भी सही है।
चेक डिजिट क्यों बचा रहता है, यह एल्गोरिदम जानते ही दिख जाता है, जो आगे है।
अपना बारकोड ख़ुद हाथ से जाँचना
नियम: दाईं ओर से शुरू करके, चेक डिजिट से पहले के अंकों पर बारी-बारी ×3 और ×1 लगाइए, उन्हें जोड़िए, और चेक डिजिट वह है जो कुल को 10 के अगले गुणक तक पहुँचा दे।
11 अंकों का एक बॉडी लीजिए और निकालिए कि उसका बारहवाँ अंक क्या होना चाहिए। बॉडी:
8 5 9 7 5 1 2 3 4 0 1उस बॉडी के दाएँ सिरे से शुरू कीजिए — यानी 1 से — और बारी-बारी लगाइए, पहले ×3:
| अंक (दाईं ओर से) | 1 | 0 | 4 | 3 | 2 | 1 | 5 | 7 | 9 | 5 | 8 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| भार | ×3 | ×1 | ×3 | ×1 | ×3 | ×1 | ×3 | ×1 | ×3 | ×1 | ×3 |
×3 वाले अंक हैं 1, 4, 2, 5, 9 और 8। इनका जोड़ 29 है, और 29 × 3 = 87।
×1 वाले अंक हैं 0, 3, 1, 7 और 5। इनका जोड़ 16 है।
कुल: 87 + 16 = 103।
103 से ऊपर 10 का अगला गुणक 110 है। तो चेक डिजिट है 110 − 103 = 7, और पूरा UPC-A है:
859751234017अब EAN-13 बनाने के लिए आगे शून्य लगाइए:
0859751234017फिर से गिनिए। बारी-बारी वाली गिनती अब भी उसी जगह से शुरू होती है — चेक डिजिट के ठीक बाएँ वाला अंक अब भी ×3 है — इसलिए हर मूल अंक का भार वही रहता है, और नया अग्रणी शून्य ×1 वाली जगह पर पड़ता है जहाँ उसका योगदान 0 है। कुल अब भी 103 है। चेक डिजिट अब भी 7 है। यही पूरी वजह है कि यह रूपांतरण मुफ़्त पड़ता है।
इससे व्यवहार में दो काम की बातें निकलती हैं।
अगर आपका निकाला हुआ कुल पहले से ही 10 का पूरा गुणक है, तो चेक डिजिट 0 है — 10 नहीं, और अगला गुणक भी नहीं। और अगर आप कोई दिया हुआ बारकोड जाँचें और गणित छपे हुए अंक पर न बैठे, तो नंबर कहीं न कहीं ग़लत है। एक भी अंक ग़लत टाइप होने पर जोड़ लगभग हमेशा बिगड़ जाता है। पास-पास के दो अंक आपस में बदल जाएँ तो कभी-कभी नहीं बिगड़ता, क्योंकि वे ऐसे भारों पर बैठ सकते हैं जो एक-दूसरे को काट दें — इसलिए जाँच का पास होना अच्छा प्रमाण है, सबूत नहीं।
क़लम लेकर पाँच मिनट बिताइए और पता चल जाएगा कि आपकी रिलीज़ पर लगा कोड असली है या नहीं। यह समय किसी को ईमेल करके पूछने से बेहतर ख़र्च होता है।
इसका क्या करें
तीन काम, इसी क्रम में।
- अपने ISRC बिना हाइफ़न के रखिए, अपने नियंत्रण वाली एक ही जगह पर, और साथ में यह भी कि हर कोड किस रिकॉर्डिंग का नाम है। किसी डिस्ट्रिब्यूटर के डैशबोर्ड में नहीं — अपनी ख़ुद की फ़ाइल में। कोड आपके हैं और वे रिकॉर्डिंग्स के पीछे चलते हैं।
- किसी रीमास्टर को नया ISRC देने से पहले, एक वाक्य लिखिए कि ऑडियो के साथ क्या किया गया। अगर वह लेवल, अपरिवर्ती EQ, अपरिवर्ती कंप्रेशन, डी-नॉइज़िंग, डी-क्लिकिंग, स्पीड या पिच सुधार, सैंपल-रेट बदलाव या डिदरिंग है, तो §A.10.1 कहता है कि कोड वही रखिए। अगर रीमास्टर मूल के बग़ल में बिक्री पर जा रहा है, तो चाहे जो हो, उसे नया कोड दीजिए।
- अपने बारकोड पर चेक डिजिट एक बार चला लीजिए। इसमें पाँच मिनट लगते हैं और तीनों पहचान-कोड में यही अकेला है जो ख़ुद बता देगा कि वह ग़लत है या नहीं।
मज़ुफ़ा पर रिलीज़ करना मुफ़्त है और कमीशन 0% है — रॉयल्टी का कोई प्रतिशत नहीं, पूरी की पूरी आगे भेजी जाती है — और यह सिर्फ़ आमंत्रण से चलता है, जिसमें हर पूर्ण आवेदन को एक व्यक्ति पढ़ता है। हमारे टूल पूरी तरह आपके ब्राउज़र में चलते हैं; कोई ऑडियो अपलोड नहीं होता। लेकिन इनमें से कोई बात आपकी रिकॉर्डिंग्स के पहचान-कोड नहीं बदलती। वे रिकॉर्डिंग्स के हैं, और आप आगे जहाँ भी जाएँ, वे उन्हीं के साथ रहते हैं।
स्रोत
- IFPI ISRC Handbook, §A.10.1 — सत्यापित 2026-09-07. (हमारे संदर्भ संग्रह में इस दस्तावेज़ के लिए कोई URL दर्ज नहीं है; अनुभाग संख्या इसलिए दी गई है ताकि आप इसे सीधे Handbook में जाँच सकें।)