तकनीकी संदर्भ

ISRC, ISWC और UPC/EAN: रिकॉर्डिंग, रचना और रिलीज़ की पहचान

समीक्षा 2026-09-07

फ़िल्मी संगीत, रीक्रिएशन, राग-आधारित शास्त्रीय रिपर्टवा और भजन — भारतीय कैटलॉग के लिए पूरा तकनीकी संदर्भ।


सीधा उत्तर

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


1. तीन पहचानें, तीन परतें, तीन पैसे की धाराएँ

पैसा उसी तीन-परत ढाँचे पर बहता है जिस पर पहचान बनी है, इसलिए परत की ग़लती सीधे भुगतान की ग़लती बन जाती है।

ISRC — रिकॉर्डिंग। ISO 3901, जिसका अंतर्राष्ट्रीय रजिस्ट्रेशन अथॉरिटी IFPI है और देश-स्तर पर राष्ट्रीय एजेंसियाँ आवंटन करती हैं। स्ट्रीमिंग का मास्टर-पक्ष (recording revenue) और प्रसारण/सार्वजनिक प्रदर्शन का पड़ोसी-अधिकार (neighbouring rights) इसी कोड पर मिलान होते हैं।

ISWC — कृति। ISO 15707, CISAC की व्यवस्था के अंतर्गत। रूप T-902.145.883-3 जैसा होता है — T, नौ अंक, एक चेक डिजिट — और इन अंकों में देश, लेखक या पब्लिशर की कोई जानकारी छिपी नहीं होती। पब्लिशिंग-पक्ष — यानी संगीतकार और गीतकार को मिलने वाली मैकेनिकल तथा परफ़ॉर्मेंस रॉयल्टी — इसी परत पर चलती है। ISWC आप ख़ुद नहीं बनाते; यह आपकी सोसाइटी या पब्लिशर के ज़रिए कृति के पंजीकरण पर जारी होता है।

UPC/EAN — उत्पाद। GS1 का Global Trade Item Number — वही श्रेणी का कोड जो साबुन की टिकिया पर होता है। यह एल्बम/ईपी/सिंगल को बाज़ार की वस्तु के रूप में पहचानता है। रिटेल रिपोर्टिंग और उत्पाद-स्तरीय मिलान यहीं होता है।

एक वाक्य में: ISRC वह ऑडियो फ़ाइल है, ISWC वह गीत है, UPC वह डिब्बा है जिसमें आपने उसे बेचा।

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


2. एक फ़िल्मी गाना: दुनिया की सबसे परतदार पहचान-श्रृंखला

किसी और परंपरा में एक ही गीत के इतने वैध, एक साथ मौजूद उत्पाद नहीं होते जितने हिंदी फ़िल्म संगीत में। पूरी श्रृंखला एक ठोस (काल्पनिक, पर पूरी तरह सामान्य) उदाहरण से देखिए।

फ़िल्म रेत की नदी (2026) का गाना "साँझ ढले"। संगीतकार: एक व्यक्ति। गीतकार: दूसरा व्यक्ति। पार्श्व गायक: दो — एक पुरुष, एक महिला। रिकॉर्डिंग लेबल के पास है; फ़िल्म के निर्माता के पास फ़िल्म है; कृति संगीतकार, गीतकार और उनके पब्लिशर के बीच बँटी है।

2.1 कृति की परत: एक ISWC

"साँझ ढले" एक कृति है। उसका संगीत बनाने वाला और उसके बोल लिखने वाला उस कृति के लेखक हैं। जब यह कृति सोसाइटी में पंजीकृत होती है, उसे एक ISWC मिलता है — मान लीजिए T-902.145.883-3

अब इस पूरे दस्तावेज़ की सबसे उपयोगी बात: नीचे जो कुछ भी होगा, वह इस ISWC को नहीं बदलेगा। न रीमिक्स, न लाइव संस्करण, न दस साल बाद का रीक्रिएशन, न पाँच अलग-अलग UPC। कृति एक है।

2.2 रिकॉर्डिंग की परत: कितने ISRC?

फ़िल्म के लिए बना मास्टर — पूरा, ४:२६ मिनट का, दोनों गायकों के साथ — एक रिकॉर्डिंग है। उसे एक ISRC मिलता है: IN-M9K-26-01187 (उदाहरण)।

अब देखिए कि उसी सत्र से व्यवहार में क्या-क्या निकलता है, और हर बार सवाल एक ही है — क्या श्रोता को अलग ऑडियो फ़ाइल सुनाई देगी?

संस्करणअलग ऑडियो?ISRC
फ़िल्म/एल्बम संस्करण (४:२६)IN-M9K-26-01187
प्री-रिलीज़ सिंगल (वही मास्टर)नहींवही …01187
संकलन पर वही ट्रैकनहींवही …01187
"सिंगल एडिट" (३:०५, अंतरा छोटा)हाँनया — IN-M9K-26-01188
लो-फ़ाई / स्लोड-रीवर्ब रीमिक्सहाँनया — IN-M9K-26-01193
केवल-वाद्य (करोके/इंस्ट्रुमेंटल)हाँनया — IN-M9K-26-01194
लाइव कॉन्सर्ट संस्करणहाँनया

तीन बातें ध्यान देने लायक़ हैं। पहली, प्री-रिलीज़ सिंगल पर नया ISRC नहीं बनता — वह वही फ़ाइल है, बस अलग डिब्बे में। दूसरी, ३:०५ का एडिट नया ISRC माँगता है क्योंकि प्लेइंग टाइम में दस सेकंड से ज़्यादा का फ़र्क़ है; IFPI का FAQ मॉडिफ़िकेशनों की सूची में साफ़ लिखता है: "Changes in playing time which exceed 10 seconds" (IFPI ISRC FAQ)। तीसरी, केवल-वाद्य संस्करण भी अलग रिकॉर्डिंग है — भारतीय बाज़ार में करोके और "इंस्ट्रुमेंटल" रिलीज़ रोज़ की चीज़ है और इन्हें अक्सर मूल ट्रैक का ISRC दे दिया जाता है, जो सीधा-सीधा टकराव है।

2.3 उत्पाद की परत: चार UPC, एक ही रिकॉर्डिंग

यहीं फ़िल्मी संगीत बाक़ी दुनिया से अलग हो जाता है। एक ही मास्टर, एक ही साल में, चार वैध उत्पादों में जाता है:

उत्पादकबUPC/EAN (उदाहरण)उसमें ISRC
प्री-रिलीज़ सिंगल "साँझ ढले"फ़िल्म से ६ हफ़्ते पहले8904551021373…01187
साउंडट्रैक एल्बम रेत की नदीरिलीज़ से १ हफ़्ता पहले8904551021441…01187 + बाक़ी ट्रैक
रीमिक्स सिंगल "साँझ ढले (लो-फ़ाई)"फ़िल्म के २ महीने बाद8904551021519…01193
लेबल संकलन मॉनसून हिट्स २०२६साल के अंत में8904551021687…01187

चारों उत्पाद वैध हैं, चारों को अपना-अपना UPC चाहिए, और इनमें से तीन में एक ही ISRC है। यही वह ढाँचा है जिसे लोग उलटा कर देते हैं: नया UPC देखकर मान लेते हैं कि नया ISRC भी चाहिए, और संकलन पर वही ट्रैक नए कोड के साथ डाल देते हैं। इसका नतीजा यह होता है कि उस रिकॉर्डिंग के स्ट्रीम, प्लेलिस्ट-इतिहास और पड़ोसी-अधिकार पंजीकरण दो पहचानों में बँट जाते हैं, और सोसाइटी के डेटाबेस में एक "नई" रिकॉर्डिंग प्रकट हो जाती है जिसका कोई इतिहास नहीं।

नया डिब्बा नया UPC माँगता है; नया डिब्बा नया ISRC नहीं माँगता।

2.4 डब और अन्य-भाषा संस्करण: यहाँ ईमानदारी से अनिश्चितता है

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


3. रीक्रिएशन: नई रिकॉर्डिंग, पुरानी कृति — और भारत की सबसे महँगी मेटाडेटा ग़लती

पिछले एक दशक में हिंदी फ़िल्म संगीत का एक बड़ा हिस्सा पुराने गानों के "रीक्रिएशन" से बना है: नब्बे के दशक का, या उससे भी पुराना कोई गाना, नए अरेंजमेंट, नए गायक और नई प्रोडक्शन के साथ दोबारा रिकॉर्ड किया जाता है और नई फ़िल्म में लगता है। पहचान की दृष्टि से यह पूरी तरह साफ़ मामला है — बशर्ते एक ग़लती न की जाए।

जो सच है:

  • यह एक नई रिकॉर्डिंग है। पुराना मास्टर छुआ तक नहीं गया। इसलिए नया ISRC — यहाँ कोई विवाद नहीं। मान लीजिए IN-T4R-26-00042
  • यह एक नई कृति नहीं है। धुन और बोल वही हैं जो मूल संगीतकार ने बनाए और मूल गीतकार ने लिखे। इसलिए ISWC वही रहता है जो मूल कृति का है।
  • इसलिए मूल संगीतकार और मूल गीतकार ही कृति के लेखक बने रहते हैं और पब्लिशिंग-पक्ष उन्हीं (या उनके उत्तराधिकारियों/पब्लिशर) को जाता है।
  • रीक्रिएशन का नया UPC बनता है क्योंकि वह नया उत्पाद है — मान लीजिए 8904551021755

जो सबसे ज़्यादा ग़लत भरा जाता है: रीक्रिएशन करने वाले प्रोड्यूसर को Composer की फ़ील्ड में डाल देना — और मूल संगीतकार को या तो हटा देना, या उन्हें कहीं टिप्पणी में डाल देना।

यह एक फ़ील्ड की ग़लती है और भारतीय संगीत में यही सबसे महँगी है, तीन कारणों से। पहला, यह ग़लत परत की ग़लती है: प्रोड्यूसर ने रिकॉर्डिंग बनाई, कृति नहीं; उसकी सही भूमिकाएँ Producer, Arranger या (जहाँ वास्तव में नई सामग्री जोड़ी गई हो) Additional Composer हैं। दूसरा, यह अपने आप ठीक नहीं होती: एक बार ग़लत लेखक-दावा डिलीवरी में चला गया तो वह दर्जनों डाउनस्ट्रीम डेटाबेस में नक़ल हो जाता है, और वहाँ से हटवाना पंजीकरण-स्तर का विवाद बन जाता है, फ़ॉर्म भरने का काम नहीं। तीसरा, यह मैकेनिकल और परफ़ॉर्मेंस रॉयल्टी की उस धारा को ग़लत दिशा दे देती है जो अक्सर रिकॉर्डिंग-पक्ष की कमाई से बड़ी होती है और दशकों चलती है।

रीक्रिएशन में आप नया मास्टर बनाते हैं, नया लेखक नहीं बनते।

एक व्यावहारिक जाँच: रीक्रिएशन डिलीवर करने से पहले लिखकर तय कीजिए कि (क) मूल संगीतकार का नाम क्या है, (ख) मूल गीतकार का नाम क्या है, (ग) कृति का ISWC क्या है, और (घ) आपके पास इस कृति को दोबारा रिकॉर्ड करके रिलीज़ करने का अधिकार किस दस्तावेज़ से आता है। अगर इनमें से कोई ख़ाना ख़ाली है, समस्या मेटाडेटा की नहीं, लाइसेंस की है — और मेटाडेटा फ़ॉर्म उसे छिपा नहीं सकता।

यही तर्क "अनप्लग्ड", "कवर" और "श्रद्धांजलि" संस्करणों पर भी लागू होता है: हर बार नई रिकॉर्डिंग, हर बार नया ISRC, हर बार वही पुराना ISWC, हर बार वही मूल लेखक।


4. ISRC की संरचना, वर्ण दर वर्ण

बारह अल्फ़ान्यूमेरिक वर्ण, चार खंडों में। IFPI इसे पाँच-वर्ण के प्रीफ़िक्स (दो अक्षर + तीन अल्फ़ान्यूमेरिक), फिर दो अंकों का वर्ष-संदर्भ, फिर पाँच अंकों का पदनाम कोड बताता है (IFPI, ISRC Structure)। पढ़ने के लिए: CC-XXX-YY-NNNNN

खंडलंबाईसामग्री
देश कोडअक्षर। उस एजेंसी का कोड जिसने प्रीफ़िक्स आवंटित किया।
रजिस्ट्रेंट कोडअल्फ़ान्यूमेरिक। कोड देने वाली इकाई।
वर्ष-संदर्भअंक। उस वर्ष के अंतिम दो अंक जिसमें कोड सौंपा गया।
पदनाम कोडअंक। उस वर्ष के भीतर रजिस्ट्रेंट का क्रमांक।

पदनाम कोड की सीमा प्रीफ़िक्स के साथ ही तय होती है: "Allocation of a new Prefix Code will be accompanied by the range of Designation Codes for which it is authorised for that Registrant. This may be the full range of 00000 to 99999, or a subset" (वही स्रोत)। यानी हर रजिस्ट्रेंट के पास पूरे एक लाख कोड हों, यह ज़रूरी नहीं।

4.1 हाइफ़न सिर्फ़ दिखावे के लिए हैं

IN-M9K-26-01187 और INM9K2601187 एक ही कोड हैं। ISRC हैंडबुक स्पष्ट है कि "ISRC" शब्द, स्पेस और हाइफ़न कोड का हिस्सा नहीं हैं। डेटाबेस और डिलीवरी फ़ाइलों में इसे बारह वर्ण के रूप में रखिए — बारह-वर्ण की फ़ील्ड में हाइफ़न सहित पंद्रह वर्ण भेजना एक टाला जा सकने वाला रिजेक्शन है।

4.2 कोई चेक डिजिट नहीं है — और यह छोटी बात नहीं

UPC में चेक डिजिट है। ISWC में चेक डिजिट है। ISRC में नहीं है। इसका सीधा परिणाम यह है कि एक वर्ण की टाइपिंग-ग़लती से बना कोड बिल्कुल वैध दिखता है, बस वह किसी और की रिकॉर्डिंग का होता है (या किसी का भी नहीं)। IFPI केवल रूप की जाँच सुझाता है: कोड "should be a 12-character alphanumeric string that fits the structure of ISRC detailed above" (IFPI, ISRC Structure)।

ISRC में चेक डिजिट न होने का मतलब है कि एक अंक की ग़लती किसी सिस्टम में नहीं पकड़ी जाएगी — इसलिए ISRC कभी टाइप मत कीजिए, हमेशा पेस्ट कीजिए।

4.3 वर्ष-संदर्भ रिकॉर्डिंग का वर्ष नहीं है

यह भारतीय कैटलॉग में बार-बार ग़लत समझा जाता है, ख़ासकर पुराने आर्काइव को डिजिटाइज़ करते समय। IFPI का शब्द: वर्ष-संदर्भ वह वर्ष है "in which the ISRC is assigned to the recording", और "The year in which the ISRC is assigned may be a different year from the year of recording. The year of recording is important information, but it should be entered into and obtained from the metadata associated with the recording, and not from the Year of Reference element of the ISRC" (वही स्रोत)।

इसका उद्देश्य तारीख़ बताना नहीं, नाम-स्थान बाँटना है: यह "refresh[es] the space of codes which may be assigned each calendar year, to ensure that codes assigned in prior years cannot be inadvertently re-assigned"।

यानी १९७८ में रिकॉर्ड हुए किसी मुजरा गीत का टेप अगर आप २०२६ में डिजिटाइज़ करके पहली बार ISRC दे रहे हैं, तो वर्ष-संदर्भ 26 है, 78 नहीं। यह ग़लती नहीं है — इसे "सुधारने" की कोशिश मत कीजिए। रिकॉर्डिंग का असली वर्ष मेटाडेटा के अपने खाने में जाता है।


5. नया ISRC कब चाहिए, और कब बनाना मना है

पूरे नियम की धुरी दो वाक्य हैं। हैंडबुक §4.3: "A recording with an ISRC that has not undergone material change since an ISRC was assigned shall not be assigned another ISRC." और §A.3: "An ISRC that has been assigned to a recording shall never be re-assigned to another different recording." एक रिकॉर्डिंग — एक कोड, हमेशा के लिए; एक कोड — एक रिकॉर्डिंग, हमेशा के लिए।

नया ISRC चाहिए

  • रीमिक्स (§A.9.8) — लो-फ़ाई, स्लोड-रीवर्ब, क्लब मिक्स, डीजे एडिट, सब।
  • एडिट (§A.9.4) — रेडियो एडिट, गाली हटाया गया संस्करण, छोटा किया गया सिंगल कट।
  • लाइव संस्करण (§A.9.1) — "The live recording is completely different from the studio version and a new ISRC is required."
  • इंस्ट्रुमेंटल / केवल-कोरस / कोई तत्व दबाया गया संस्करण (§A.9.14) — करोके ट्रैक इसमें आते हैं।
  • प्लेइंग टाइम में दस सेकंड से अधिक का बदलाव — IFPI FAQ: "Changes in playing time which exceed 10 seconds"।
  • ऐतिहासिक रिकॉर्डिंग की रीस्टोरेशन जहाँ रचनात्मक परिवर्तन शामिल हों — FAQ की सूची में: "Restoration of historical recordings, where creative changes are involved"।

रीमास्टर: नियम उससे कहीं तंग है जितना आम तौर पर बताया जाता है

यह वह जगह है जहाँ इंटरनेट पर मिलने वाली अधिकांश सलाह ग़लत है। हैंडबुक §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." और वह स्पष्ट रूप से बाहर रखता है — साधारण स्तर-परिवर्तन, अपरिवर्ती EQ, अपरिवर्ती कम्प्रेशन, डी-नॉइज़िंग, डी-क्लिकिंग, गति/पिच सुधार, सैंपल-रेट परिवर्तन और डिदरिंग: "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes."

IFPI का FAQ भी यही कहता है, और भी सीधे शब्दों में: "I am remastering some of our company's catalogue recordings. Can we use the same ISRC for the new remastered version? — Yes, generally this is appropriate as the remaster is fundamentally the same recording as the original. Only in the event that the remastering process involves significant new creative input to the resulting remastered recording can it be appropriate to assign a new ISRC" (IFPI ISRC FAQ, प्रश्न ८)।

इसलिए यह लिखना ग़लत है कि "रीमास्टर को हमेशा नया ISRC चाहिए।" पुराने फ़िल्मी टेप की सफ़ाई, हिस हटाना, टेप की गति ठीक करना और नए सैंपल-रेट पर ट्रांसफ़र — ये सब हैंडबुक की भाषा में तकनीकी समायोजन हैं, रचनात्मक इनपुट नहीं।

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

नया ISRC नहीं चाहिए

  • उसी मास्टर का पुनःप्रकाशन। नया आर्टवर्क, नई तारीख़, नया क्षेत्र, नया डिस्ट्रिब्यूटर — रिकॉर्डिंग नहीं बदली।
  • मालिकाना बदलना। हैंडबुक §4.6 और FAQ प्रश्न ६: "Once an ISRC has been assigned to a track the ISRC should remain the same for the lifespan of the track. This is the case even if the ownership of the track changes."
  • संकलन में डालना। संकलन को अपना UPC मिलता है; उसमें मौजूद रिकॉर्डिंगें अपने पुराने ISRC ही रखती हैं।

एक असममित मामला जिसे भारतीय आर्काइव में जानना ज़रूरी है: अगर रिकॉर्डिंग को कभी ISRC मिला ही नहीं था, मालिकाना बदल चुका है, और वर्तमान अधिकार-धारक उसे अपरिवर्तित रूप में रिलीज़ कर रहा है, तो FAQ के अनुसार "a new ISRC should be assigned"। नियम मौजूदा कोड की रक्षा करता है; वह उस सामग्री के लिए इतिहास गढ़ता नहीं जिसका कभी कोड था ही नहीं।

निर्णय-नियम

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


6. राग एक कृति नहीं है: शास्त्रीय रिपर्टवा में ISRC बहुत, ISWC कम

हिंदुस्तानी शास्त्रीय संगीत पहचान-प्रणाली पर वह दबाव डालता है जो फ़िल्मी संगीत नहीं डालता — और यह दबाव असली है, कोई तकनीकी बहाना नहीं।

राग कोई कृति नहीं है। राग यमन, राग भैरवी, राग मारवा — ये स्वर-समुच्चय और उनके बरतने के व्याकरण हैं, किसी एक व्यक्ति की रचना नहीं। इसलिए "राग यमन" को ISWC में लेखक-सहित कृति के रूप में दर्ज करना श्रेणी की ग़लती है — वैसे ही जैसे "सॉनेट" को किसी कविता का शीर्षक मान लेना।

आलाप रचना नहीं, उस क्षण की उपज है। एक सितार वादन में बीस मिनट का आलाप-जोड़-झाला बजता है — वह उसी शाम, उसी मंच पर बना। वह रिकॉर्डिंग के रूप में पूरी तरह ठोस है: उसे ISRC चाहिए, और चाहिए ही। पर वह किसी पूर्व-मौजूद कृति को मूर्त नहीं करता, इसलिए उसके पीछे कोई ISWC नहीं होता।

इसका सीधा नतीजा यह है कि एक शास्त्रीय एल्बम में ISRC की संख्या ज़्यादा और ISWC की संख्या बहुत कम — कभी-कभी शून्य — होना पूरी तरह सही है। यह डेटा की कमी नहीं, रिपर्टवा का स्वभाव है। मान लीजिए एक सितार रिकॉर्डिंग तीन ट्रैक में बँटी है:

ट्रैकISRCISWC
राग मारवा — आलाप एवं जोड़ (१८:२०)चाहिएनहीं
राग मारवा — विलंबित तीनताल में गतचाहिएगत के रचयिता ज्ञात हों तो हाँ
राग मारवा — द्रुत तीनताल में गत, झालाचाहिएवही शर्त

बंदिश का मामला उलटा है। ख़याल की बंदिश, ध्रुपद की रचना, ठुमरी का बोल — इनके वाग्गेयकार अक्सर नाम से जाने जाते हैं (परंपरा में "सदारंग", "अदारंग" जैसे मुद्रा-नाम इसी पहचान के लिए बंदिश के अंतरे में गूँथे जाते हैं)। जहाँ रचयिता का नाम दस्तावेज़ों में मौजूद है, वहाँ बंदिश एक कृति है, और उसका ISWC-स्तरीय पंजीकरण उतना ही वैध है जितना किसी फ़िल्मी गाने का। एक ही ठुमरी को पाँच गायक गाएँ तो पाँच ISRC और एक ISWC — बिल्कुल वैसे ही जैसे फ़िल्मी गाने में।

इसलिए शास्त्रीय एल्बम की सही नीति एक ही वाक्य में: हर ट्रैक को ISRC, और ISWC केवल वहाँ जहाँ कोई नामित रचना वास्तव में बजी है। ट्रैक का शीर्षक (राग, ताल, लय) मेटाडेटा है; वह अपने आप कृति नहीं बना देता।


7. भजन और भक्ति रिपर्टवा: "पारंपरिक" कब सच है

भजन, आरती, कीर्तन और सूफ़ी-भक्ति सामग्री भारतीय स्वतंत्र रिलीज़ का बहुत बड़ा हिस्सा हैं, और इनमें एक बुरी आदत लगभग सार्वभौमिक है: लेखक-खाने में Traditional या "पारंपरिक" लिख देना, क्योंकि वह खाना ख़ाली नहीं छोड़ा जा सकता और सच पता करना झंझट है।

फ़र्क़ ठीक-ठीक यह है:

  • पद और रचनाएँ जिनके रचयिता ज्ञात हैं — कबीर, मीरा, सूरदास, तुलसीदास, नानक की वाणी — पाठ के रचयिता ज्ञात हैं, भले ही वे बहुत पहले हुए हों। इन्हें बेनाम "पारंपरिक" कहना तथ्यतः ग़लत है, चाहे उनके पाठ की कॉपीराइट-स्थिति जो भी हो।
  • धुन अक्सर आधुनिक होती है। यही सबसे ज़्यादा छूटने वाला तथ्य है। सोलहवीं सदी का पद बीसवीं सदी के किसी संगीतकार की बनाई धुन पर गाया जा रहा हो — तो संगीत की रचना उस संगीतकार की है और वह एक जीवित, दस्तावेज़ित लेखक-दावा है। इसे "पारंपरिक" में डाल देना उस संगीतकार की पब्लिशिंग आय को सीधे मिटा देता है।
  • आपकी अपनी नई धुन भी रचना है। अगर आपने किसी पुराने पद को अपनी धुन दी है, तो कृति के संगीत-पक्ष के लेखक आप हैं। इसे भी "पारंपरिक" लिख देना अपने ही अधिकार को छोड़ देना है — और यह बहुत आम है।

व्यावहारिक कसौटी: Traditional तभी लिखिए जब आप यह कह सकें कि आपने ढूँढ़ा और रचयिता का नाम दस्तावेज़ों में मिलता ही नहीं। "मुझे पता नहीं" और "किसी को पता नहीं" एक बात नहीं हैं, और पहचान-प्रणाली में इन दोनों का दाम अलग-अलग है।

"पारंपरिक" एक तथ्य का दावा है, अनुसंधान न करने का बहाना नहीं।


8. भारत में ISRC कहाँ से आता है

भारत की राष्ट्रीय ISRC एजेंसी The Indian Music Industry (IMI), मुंबई है; IFPI की आधिकारिक एजेंसी-सूची में भारत के आगे यही नाम, यही पता (वर्ली, मुंबई – 400030) और संपर्क isrc@indianmi.org दर्ज है (IFPI, ISRC Agency Contacts)। प्रीफ़िक्स के लिए यही रास्ता है।

तीन बातें जो कोड लेते समय जान लेनी चाहिए:

सदस्यता की शर्त नहीं है। IFPI का FAQ दो-टूक है: "The ISRC System is constructed so that any entity creating sound or music video recordings can assign ISRCs to their recordings regardless of their membership of, or standing with, industry associations and other bodies" (IFPI ISRC FAQ, प्रश्न २)।

प्रीफ़िक्स आप चुन नहीं सकते। "Prefix Codes are allocated to applicants by ISRC Agencies on a strictly sequential basis. There is no facility for selecting particular characters within Prefix Codes" (वही, प्रश्न ५)। यानी अपने लेबल के नाम से मिलता-जुलता प्रीफ़िक्स माँगने का कोई प्रावधान नहीं है।

डिस्ट्रिब्यूटर के दिए कोड वैध हैं — अगर देने वाला अधिकृत है। IFPI उन कंपनियों की सूची रखता है जिन्हें दूसरों की ओर से ISRC सौंपने की अनुमति है (ISRC Managers)। बिना आवंटन वाली किसी सेवा का "जनरेट" किया हुआ कोड ISRC नहीं है — वह बारह वर्ण की एक स्ट्रिंग है जो किसी और के आवंटित क्षेत्र से टकराएगी।

डिस्ट्रिब्यूटर बदलने पर क्या होता है

ISRC रिकॉर्डिंग की पहचान है, किसी व्यापारिक रिश्ते की नहीं। डिस्ट्रिब्यूटर बदलने पर आपके ISRC आपकी रिकॉर्डिंगों के साथ ही जाते हैं — यह §4.6 और "अपरिवर्तित रिकॉर्डिंग को दूसरा कोड नहीं" वाले नियम से सीधे निकलता है। जो चीज़ नहीं जाती वह है प्रीफ़िक्स: अगर आपके पुराने डिस्ट्रिब्यूटर ने IN-M9K-26-01187 दिया था, तो INM9K उसका रजिस्ट्रेंट कोड है। उस रिकॉर्डिंग पर वही बारह वर्ण हमेशा रहेंगे (यह अनिवार्य है), पर आप उस प्रीफ़िक्स के नीचे नए कोड नहीं बना सकते, इसलिए अगली रिलीज़ पर दूसरा प्रीफ़िक्स होगा। मिले-जुले प्रीफ़िक्स वाला कैटलॉग दोष नहीं है; दोहराए गए पदनाम कोड वाला कैटलॉग दोष है।

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


9. IPRS और PPL India: कौन-सी परत, किसके पास

भारत में दोनों बड़ी सामूहिक संस्थाएँ ठीक उसी विभाजन पर बैठती हैं जो इस दस्तावेज़ की रीढ़ है, और यही उन्हें याद रखने का सबसे आसान तरीक़ा है:

  • IPRS (The Indian Performing Right Society) — कृति की परत। यानी संगीतकार, गीतकार और पब्लिशर का पक्ष; वही पक्ष जिसे ISWC पहचानता है। (iprs.org)
  • PPL India (Phonographic Performance Limited) — रिकॉर्डिंग की परत। यानी साउंड रिकॉर्डिंग में अधिकार रखने वालों का पक्ष; वही पक्ष जिसे ISRC पहचानता है। (pplindia.org)

इस दस्तावेज़ में जानबूझकर यह नहीं बताया गया कि इनकी सदस्यता, वितरण-चक्र, दावा-प्रक्रिया या पंजीकरण-फ़ॉर्म कैसे काम करते हैं — वे प्रक्रियाएँ इन्हीं संस्थाओं की अपनी हैं, बदलती रहती हैं, और उनका कोई ऐसा स्थिर सार्वजनिक विवरण नहीं है जिसे यहाँ उद्धृत किया जा सके। जो कहा जा सकता है वह यह है कि आपके कोड ही उन दोनों तरफ़ के मिलान की कुंजी हैं: कृति-पंजीकरण में जो लेखक और ISWC दर्ज हैं, और रिकॉर्डिंग-पंजीकरण में जो ISRC दर्ज है, वही आपके डिलीवरी मेटाडेटा में होने चाहिए। जब ये दोनों तरफ़ अलग-अलग होते हैं, दावा तकनीकी रूप से विफल नहीं होता — वह बस मिलता नहीं, और पैसा अपंजीकृत खाते में पड़ा रहता है।


10. UPC और EAN: उत्पाद की पहचान

UPC-A बारह अंक का है, EAN-13 तेरह का। दोनों GS1 के GTIN हैं — GTIN-12 और GTIN-13 — और दोनों की बनावट एक जैसी है: GS1 कंपनी प्रीफ़िक्स, ब्रांड-मालिक का दिया आइटम रेफ़रेंस, और अंत में एक चेक डिजिट। भारतीय लेबलों को GS1 India से मिलने वाले प्रीफ़िक्स आम तौर पर 890 से शुरू होते हैं, इसलिए ऊपर के उदाहरण तेरह अंकों के EAN-13 हैं (GS1 India)।

UPC उत्पाद की पहचान है: यह एल्बम, इस रूप में। डिजिटल एल्बम, सीडी और विनाइल तीन उत्पाद हैं और सामान्यतः तीन UPC लेते हैं। GS1 की सलाह है कि GTIN को हमेशा एक ही चौड़ाई में रखा जाए: "GS1 recommends that GTIN is always stored as a 14-digit number in the data bases. Shorter formats should be filled in with leading zeroes up to 14 characters" (GS1 EDI technical user guide)। अपनी एक्सेल शीट में भी यही कीजिए, और कॉलम को पहले टेक्स्ट फ़ॉर्मैट कीजिए — वरना अगला शून्य चुपचाप ग़ायब हो जाएगा और आपको पता भी नहीं चलेगा।

आगे शून्य लगाने से चेक डिजिट क्यों नहीं बदलता

यह बात सब दोहराते हैं, समझाता कोई नहीं। कारण यह है कि GS1 का भार (weighting) दाईं ओर से गिना जाता है, बाईं ओर से नहीं।

चेक डिजिट सबसे दाईं जगह पर होता है। उससे ठीक पहले वाले अंक से बाईं ओर चलते हुए भार ×३, ×१, ×३, ×१ … दोहराते हैं। चूँकि यह क्रम चेक डिजिट की स्थिति के सापेक्ष तय है, बाईं ओर शून्य जोड़ने से किसी भी मौजूदा अंक का भार नहीं बदलता — कुछ भी खिसकता नहीं। नया शून्य जो पद लेता है वहाँ उसका योगदान ० × ३ या ० × १ है, यानी शून्य। योग वही, अगला दस-गुणज वही, चेक डिजिट वही।

दाईं ओर से गिनने के कारण बाईं ओर का शून्य योग में ठीक शून्य जोड़ता है — इसीलिए UPC-A से EAN-13 बनाने पर चेक डिजिट नहीं बदलता।

व्यावहारिक अर्थ: 605438291763 और 0605438291763 एक ही GTIN हैं। अगर कोई सिस्टम एक रूप को अस्वीकार करता है तो वह फ़ॉर्मैटिंग का नियम है, दो अलग उत्पाद नहीं — उसे संतुष्ट करने के लिए दूसरा UPC मत ख़रीदिए।


11. चेक डिजिट, हाथ से — देवनागरी अंकों सहित

GS1 गणना तीन चरणों में बताता है: हर स्थान को उसके बारी-बारी वाले गुणक से गुणा कीजिए, "add results together to create sum", फिर "subtract the sum from nearest equal or higher multiple of ten" (GS1, Check Digit Calculator)।

प्रक्रिया

  1. चेक डिजिट से पहले वाले अंक लीजिए।
  2. उनमें सबसे दाएँ वाले से शुरू करके बाईं ओर चलते हुए बारी-बारी ×३, ×१, ×३, ×१ … से गुणा कीजिए।
  3. गुणनफल जोड़िए।
  4. योग को अगले दस-गुणज तक बढ़ाइए; अंतर ही चेक डिजिट है। योग पहले से दस का गुणज हो तो चेक डिजिट ० है।

पूरा उदाहरण। UPC-A 605438291763 लीजिए — देवनागरी में ६०५४३८२९१७६३। पहले ग्यारह अंक ६०५४३८२९१७६ / 60543829176 हैं और अंतिम / 3 वही चेक डिजिट है जिसे हम निकालेंगे। दाईं ओर से पढ़िए:

स्थान (दाएँ से)अंक (देवनागरी)अंक (ASCII)भारगुणनफल
6×३१८ / 18
7×१७ / 7
1×३३ / 3
9×१९ / 9
2×३६ / 6
8×१८ / 8
3×३९ / 9
4×१४ / 4
5×३१५ / 15
१०0×१० / 0
११6×३१८ / 18

योग: १८ + ७ + ३ + ९ + ६ + ८ + ९ + ४ + १५ + ० + १८ = ९७ (ASCII: 18 + 7 + 3 + 9 + 6 + 8 + 9 + 4 + 15 + 0 + 18 = 97)।

९७ से बड़ा या बराबर अगला दस-गुणज १०० है। १०० − ९७ =

चेक डिजिट ३ है, इसलिए पूरा UPC-A ६०५४३८२९१७६३ / 605438291763 है। ✓

अब EAN-13। आगे शून्य लगाइए: ०६०५४३८२९१७६३ / 0605438291763। चेक डिजिट से पहले अब बारह अंक हैं। दाईं ओर से गिनते हुए पुराने ग्यारह अंकों के भार बिल्कुल वही रहते हैं; नया शून्य बारहवें स्थान पर ×१ का भार लेता है और ० जोड़ता है। योग: ९७। अगला दस-गुणज: १००। चेक डिजिट: — नहीं बदला, ठीक जैसा ऊपर तर्क से निकला था।

जाँचने के लिए (बनाने के बजाय) यही प्रक्रिया चेक डिजिट को ×१ भार पर शामिल करके चलाइए और देखिए कि कुल दस का गुणज है या नहीं: ९७ + ३ = १००। ✓

आप ISRC की बनावट और UPC/EAN के चेक डिजिट को mazufa.com के मुफ़्त, ब्राउज़र-आधारित चेकर से जाँच सकते हैं — यह पूरी तरह आपके अपने डिवाइस पर चलता है और कुछ भी अपलोड नहीं करता।

**चेक डिजिट यह साबित करता है कि नंबर सही टाइप हुआ; यह नहीं साबित करता कि वह आपका नंबर है।**

और एक सीमा जो जान लेनी चाहिए: यह एल्गोरिदम हर एकल-अंक ग़लती पकड़ लेता है, पर आस-पास के दो ऐसे अंकों की अदला-बदली नहीं पकड़ता जिनमें ५ का अंतर हो (०/५, १/६, २/७, ३/८, ४/९) — ऐसी अदला-बदली से भारित योग ठीक ±१० बदलता है और चेक डिजिट वैध बना रहता है। इसीलिए UPC को अपने स्रोत दस्तावेज़ से मिलाइए, सिर्फ़ चेकर पर भरोसा मत कीजिए।


12. वे विफलताएँ जो भारतीय कैटलॉग में सचमुच दिखती हैं

संकलन पर नया ISRC। सबसे आम। लेबल संकलन बनाते समय हर ट्रैक को नया कोड दे दिया जाता है, जिससे मूल रिकॉर्डिंग का इतिहास दो हिस्सों में बँट जाता है। संकलन को नया UPC चाहिए, नए ISRC नहीं।

रीक्रिएशन में मूल संगीतकार का नाम हट जाना। ऊपर खंड ३ — भारतीय संगीत की सबसे महँगी एकल फ़ील्ड-ग़लती।

करोके/इंस्ट्रुमेंटल पर मूल ट्रैक का ISRC। दो अलग ऑडियो फ़ाइलें एक ही कोड पर — यह वह ग़लती है जो अपने आप कभी ठीक नहीं होती।

राग को कृति मान लेना, और आलाप के लिए ISWC ढूँढ़ना। दोनों दिशाओं में ग़लत: पहला झूठा लेखक-दावा बनाता है, दूसरा डिलीवरी को अनावश्यक रूप से रोक देता है।

हर भक्ति ट्रैक पर Traditional जीवित या दस्तावेज़ित संगीतकार की पब्लिशिंग आय सीधे मिट जाती है, आपकी अपनी धुन सहित।

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

स्प्रेडशीट का UPC खा जाना। 8904551021373 को एक्सेल 8.90455E+12 बना देता है, या आगे का शून्य उड़ा देता है। कॉलम पहले टेक्स्ट कीजिए।

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


13. एक स्ट्रीम से एक भुगतान तक: कड़ी कहाँ टूटती है

  1. प्ले होता है। सेवा उस रिकॉर्डिंग के विरुद्ध घटना दर्ज करती है जिसे उसने आपके दिए ISRC से पहचाना है।
  2. सेवा रिपोर्ट करती है। उपयोग-रिपोर्ट ISRC के हिसाब से आती है, रिलीज़ की पहचान UPC से होती है। मास्टर-पक्ष की रक़म यहाँ प्रति-स्ट्रीम दर से नहीं, पूल में हिस्सेदारी से बनती है — Spotify स्वयं कहता है कि वह प्रति-स्ट्रीम कोई दर नहीं देता; आय पूल की जाती है और स्ट्रीमशेयर के अनुपात में बँटती है।
  3. डिस्ट्रिब्यूटर हिसाब लगाता है। रिपोर्ट की पंक्तियाँ आपके कैटलॉग से ISRC और UPC पर मिलाई जाती हैं। जो ISRC आपके कैटलॉग में नहीं है, वह आपके स्टेटमेंट तक कभी नहीं पहुँचता।
  4. कृति-पक्ष समानांतर चलता है। गीत की मैकेनिकल और परफ़ॉर्मेंस रॉयल्टी सोसाइटियों के रास्ते जाती है, जो रिपोर्ट किए गए ISRC को पंजीकृत कृति (ISWC) से जोड़ती हैं और फिर लेखकों तथा पब्लिशरों तक। अलग पाइपलाइन, अलग समय-सारणी, अलग पैसा।
  5. पड़ोसी अधिकार। प्रसारण और सार्वजनिक प्रदर्शन की रिकॉर्डिंग-पक्षीय आय ISRC पर मिलती है, उस पंजीकरण के विरुद्ध जिसमें अधिकार-धारक और मुख्य कलाकार दर्ज हैं।

हर चरण किसी पहचान पर लगा हुआ जोड़ (join) है, और जोड़ चुपचाप विफल होता है। चरण १–२ पर ISRC टूटा तो मास्टर-पक्ष का पैसा अमिलानित; चरण ४ पर ISRC–ISWC की कड़ी टूटी तो लेखक का पैसा अमिलानित; UPC टूटा तो उत्पाद-स्तर का हिसाब मिलाना असंभव।

हर रॉयल्टी अंततः एक डेटाबेस जोड़ का नतीजा है, और उस जोड़ को थामे रखने वाली इकलौती चीज़ पहचान-कोड है।

अनुशासन उबाऊ है और प्रति रिलीज़ लगभग एक घंटा लेता है: एक प्रामाणिक शीट रखिए जिसमें ट्रैक शीर्षक, संस्करण, ISRC, ISWC, संगीतकार और गीतकार के नाम तथा हिस्से, और रिलीज़ का UPC हो; पहचान वाले कॉलम टेक्स्ट रखिए; ISRC डिलीवरी से पहले सौंपिए, बीच में नहीं; हर UPC का चेक डिजिट जाँचिए; और यह पक्का कीजिए कि ऑडियो में जड़ी पहचान शीट से मेल खाती है। जब किसी स्टेटमेंट में कोई पंक्ति ग़ायब मिले, तब यही शीट आपका पक्ष है — इसके बिना आप यह स्थापित ही नहीं कर सकते कि भुगतान क्या होना चाहिए था।


14. त्वरित संदर्भ

ISRCISWCUPC-A / EAN-13
क्या पहचानता हैरिकॉर्डिंगकृति (गीत)रिलीज़ (उत्पाद)
मानकISO 3901 (IFPI)ISO 15707 (CISAC)GS1 GTIN-12 / GTIN-13
लंबाई१२ अल्फ़ान्यूमेरिकT + ९ अंक + चेक१२ / १३ अंक
चेक डिजिटनहींहाँहाँ
रीमिक्स पर नया?हाँनहीं (वही गीत)अलग उत्पाद हो तो हाँ
रीक्रिएशन पर नया?हाँनहींहाँ
पुनःप्रकाशन पर नया?नहींनहींप्रायः हाँ
भारत में कहाँ सेIMI (राष्ट्रीय एजेंसी) या अधिकृत ISRC मैनेजरपब्लिशर/सोसाइटी के ज़रिएGS1

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


स्रोत

IFPI / ISRC

  • IFPI, ISRC Structure — प्रीफ़िक्स, वर्ष-संदर्भ की परिभाषा और उद्देश्य, पदनाम-कोड की सीमा, वैधता-जाँच: https://isrc.ifpi.org/isrc-standard/isrc-structure
  • IFPI, ISRC Handbook — §4.3 (भौतिक परिवर्तन के बिना दूसरा कोड नहीं), §4.6 (मालिकाना बदलने पर कोड वही), §5 (हाइफ़न कोड का हिस्सा नहीं), §A.3 (कोड कभी दोबारा न सौंपा जाए), §A.9.1 लाइव, §A.9.4 एडिट, §A.9.8 रीमिक्स, §A.9.14 दबाए गए तत्व वाले संस्करण, §A.10.1 रीमास्टरिंग और रचनात्मक इनपुट, §A.10.2 प्लेइंग टाइम: https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
  • IFPI, ISRC FAQs — प्रश्न २ (सदस्यता आवश्यक नहीं), प्रश्न ५ (प्रीफ़िक्स क्रमिक रूप से आवंटित, चुने नहीं जा सकते), प्रश्न ६ (मालिकाना बदलने पर वही कोड), प्रश्न ७ (१० सेकंड, रीमिक्स/एडिट, ऐतिहासिक रीस्टोरेशन), प्रश्न ८ (रीमास्टर पर सामान्यतः वही कोड), प्रश्न ९–१० (जिस रिकॉर्डिंग को कभी कोड नहीं मिला): https://isrc.ifpi.org/faqs
  • IFPI, ISRC Agency Contacts — भारत की राष्ट्रीय एजेंसी The Indian Music Industry, मुंबई: https://isrc.ifpi.org/contacts/isrc-agency-contacts
  • IFPI, ISRC Managers — दूसरों की ओर से ISRC सौंपने के लिए अधिकृत इकाइयाँ: https://isrc.ifpi.org/get-isrc/isrc-managers
  • The Indian Music Industry (IMI): https://www.indianmi.org/

GS1 / UPC-EAN

ISWC

भारतीय सामूहिक संस्थाएँ (केवल परत-पहचान के लिए उद्धृत; उनकी आंतरिक प्रक्रियाओं का कोई दावा इस दस्तावेज़ में नहीं है)

स्ट्रीमिंग आय

  • Spotify for Artists / Loud & Clear — आय पूल की जाती है और स्ट्रीमशेयर के अनुपात में बँटती है; कोई प्रति-स्ट्रीम दर नहीं: https://loudandclear.byspotify.com/

उदाहरणों के बारे में: "साँझ ढले", फ़िल्म रेत की नदी, और ऊपर दिए सभी ISRC, ISWC तथा UPC/EAN कोड केवल संरचना समझाने के लिए गढ़े गए उदाहरण हैं। ये किसी वास्तविक रिलीज़, फ़िल्म, कलाकार या उत्पाद की पहचान नहीं हैं।

बाक़ी तकनीकी संदर्भ

पेशेवरों के लिए लिखे गए, सीधे मूल मानकों से लिए गए, और पढ़ने के लिए मुफ़्त।

इस विषय का मुफ़्त टूल खोलें →

आपका रिलीज़ जाँच लिया गया। अब इसे बाहर लाइए।

फ़ाइलें तैयार होने पर आवेदन में कुछ ही मिनट लगते हैं, और इसे एक इंसान पढ़ता है।

समीक्षा के लिए भेजें

आवेदन मुफ़्त है। कोई खाता नहीं बनता; एक इंसान इसे देखता है और ईमेल से जवाब देता है।

बाक़ी मुफ़्त टूल

मुफ़्त, कोई अकाउंट नहीं, कुछ भी अपलोड नहीं। सब कुछ आपके ब्राउज़र में चलता है।

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