ISRC, ISWC, UPC/EAN — রেকর্ডিং, রচনা এবং রিলিজের পরিচয়

এক গান, হাজার রেকর্ডিং: বাংলা ভাণ্ডারের জন্য শনাক্তকারী কোডের সম্পূর্ণ কারিগরি রেফারেন্স।

সংক্ষিপ্ত উত্তর

তিনটি কোড, তিনটি সম্পূর্ণ আলাদা জিনিস। ISRC (১২ অক্ষর) শনাক্ত করে একটি নির্দিষ্ট রেকর্ডিং — একটি পরিবেশনা, একটি মিক্স, একটি মাস্টার; ISWC শনাক্ত করে রচনা বা ওয়ার্ক — গানটি নিজে, যেমনটি লেখা ও সুর করা হয়েছে; আর UPC/EAN শনাক্ত করে রিলিজ — বাজারে ছাড়া পণ্যটি। বাংলা ভাণ্ডারে এই পার্থক্যটি পৃথিবীর যেকোনো ভাষার চেয়ে বেশি স্পষ্ট: "পুরানো সেই দিনের কথা" একটি ওয়ার্ক, তার রচয়িতা নথিভুক্ত, তার ISWC এক — কিন্তু কণিকা বন্দ্যোপাধ্যায়ের রেকর্ডিং, সাগর সেনের রেকর্ডিং আর আপনার গত মাসের রেকর্ডিং তিনটি আলাদা রেকর্ডিং, তিনটি আলাদা ISRC। ISRC-তে কোনো চেক ডিজিট নেই, তাই একটি অক্ষর উল্টে গেলেও কোডটি দেখতে নিখুঁত থাকে এবং টাকা অন্য কারও কাছে চলে যায়; UPC-তে চেক ডিজিট আছে, তাই সেখানে ভুল অন্তত চিৎকার করে ধরা পড়ে। আর একটি ভুল বাংলা রিলিজে বারবার ঘটে এবং সরাসরি টাকা কাটে: রবীন্দ্রসঙ্গীত, নজরুলগীতি বা শাহ আবদুল করিমের গানকে "Traditional" লিখে পাঠানো — এদের রচয়িতা নথিভুক্ত, এবং রচয়িতা শনাক্ত না হলে ISWC বরাদ্দই হয় না।

১. তিন স্তর: এক গান, হাজার রেকর্ডিং

একটি রিলিজ একক বস্তু নয়, একটি স্তরবিন্যাস — এবং শনাক্তকারী কোডগুলো ঠিক সেই স্তরগুলোর গায়ে বসে।

ISRC — রেকর্ডিং। ISO 3901, IFPI রেজিস্ট্রেশন অথরিটি হিসেবে ব্যবস্থাপনা করে, জাতীয় এজেন্সিগুলো বরাদ্দ দেয়। এক মাস্টার, এক ISRC। আপনার স্টুডিও ভার্সন আর আপনার শান্তিনিকেতনের মঞ্চে গাওয়া লাইভ ভার্সন — দুটি রেকর্ডিং, দুটি ISRC, যদিও গান একটাই এবং রচয়িতাও একজনই।

ISWC — রচনা। ISO 15707, CISAC-র অধীনে পরিচালিত। কাঠামো: "the letter T (the 'prefix element'), followed by nine digits (the 'work identifier'), and a numeric check digit" (ISWC)। ISWC ওয়ার্ককে শনাক্ত করে, তার প্রকাশরূপকে নয় — সাইটটির ভাষায়, "The ISWC identifies musical works, not their manifestations, objects, or expressions (e.g. publications, broadcasts...)"। আপনি নিজে ISWC "কিনতে" যান না; এটি বরাদ্দ হয় আপনার কালেক্টিং সোসাইটি বা পাবলিশারের মাধ্যমে ওয়ার্ক রেজিস্ট্রেশনের সময়।

UPC/EAN — রিলিজ। GS1-এর Global Trade Item Number — সাবানের প্যাকেটে যে শ্রেণির কোড বসে, ঠিক সেটাই। এটি অ্যালবাম, ইপি বা সিঙ্গলকে পণ্য হিসেবে নাম দেয়। তিন গানের একটি ইপি: একটি UPC, তিনটি ISRC।

ISRC হলো রেকর্ডিং, ISWC হলো গান, আর UPC হলো যে বাক্সে ভরে আপনি সেটি বিক্রি করলেন।

রবীন্দ্রসঙ্গীত: পৃথিবীর স্পষ্টতম উদাহরণ

ওয়ার্ক আর রেকর্ডিংয়ের পার্থক্য বোঝাতে বিশ্বসংগীতে রবীন্দ্রসঙ্গীতের চেয়ে ভালো উদাহরণ সম্ভবত নেই। রবীন্দ্রনাথের গানের সংখ্যা প্রায় ২,২৩২, গীতবিতানে সংকলিত, এবং স্বরবিতানের ৬৪ খণ্ডে ১,৭২১টি গানের স্বরলিপিসহ পাঠ প্রকাশিত (Rabindra Sangeet)। অর্থাৎ ওয়ার্কগুলোর পাঠ, রচয়িতা ও স্বরলিপি নথিভুক্ত — অজ্ঞাত কিছু নেই।

অন্যদিকে রেকর্ডিং? একটিমাত্র গান — ধরুন "আমার সোনার বাংলা" বা "আজি ঝরো ঝরো মুখর বাদরদিনে" — এক শতাব্দীর বেশি সময় ধরে গ্রামোফোন রেকর্ড, রেডিও ট্রান্সক্রিপশন, ক্যাসেট, সিডি এবং এখন স্ট্রিমিংয়ে অসংখ্যবার রেকর্ড হয়েছে। এবং রবীন্দ্রসঙ্গীতে পরিবেশনার ঘরানা শক্তিশালী: একই গানের পাঠ এক থাকলেও উচ্চারণ, লয়, বিস্তার ও সংগত ঘরানাভেদে আলাদা।

কাঠামোটা তাই একদম পরিষ্কার:

একই যুক্তি হুবহু প্রযোজ্য নজরুলগীতি, অতুলপ্রসাদী, দ্বিজেন্দ্রগীতি এবং রজনীকান্তের গানের ওপর। এই পাঁচটি ধারা — বাংলায় যাদের একসঙ্গে "পঞ্চকবির গান" বলা হয় — রচয়িতার নাম, গানের পাঠ এবং প্রায়শই স্বরলিপিসহ নথিভুক্ত। এগুলো কোনো অর্থেই অজ্ঞাতপরিচয় লোকসংগীত নয়।

২. "Traditional" কখন সঠিক, কখন ব্যয়বহুল ভুল

এই ডকুমেন্ট যদি একটিমাত্র জিনিস শেখাতে পারে, সেটি এই অনুচ্ছেদ।

বাংলা ক্যাটালগে সবচেয়ে বেশি টাকা হারায় একটি ড্রপডাউন থেকে — কম্পোজার/লিরিসিস্ট ফিল্ডে "Traditional" বেছে নেওয়া থেকে। কারণটা কাঠামোগত, মতামতের ব্যাপার নয়। ISWC ইন্টারন্যাশনাল এজেন্সি স্পষ্ট করে বলে: "An ISWC code is only allocated by the local Registration Agency when all of the creators of the work have been uniquely identified" (ISWC — Getting an ISWC)। যে ওয়ার্কের রচয়িতা শনাক্ত করা হয়নি, তার ISWC বরাদ্দ হয় না; ISWC না থাকলে রেকর্ডিং থেকে ওয়ার্কে যাওয়ার জোড় (link) থাকে না; সেই জোড় না থাকলে প্রকাশনা-পক্ষের টাকা কোথাও যায় না — গানটি বাজে, স্ট্রিম গোনা হয়, টাকা আদায় হয়, এবং সাসপেন্স অ্যাকাউন্টে বসে থাকে।

২.১ যেখানে রচয়িতা নথিভুক্ত

রবীন্দ্রনাথ ঠাকুর, কাজী নজরুল ইসলাম, অতুলপ্রসাদ সেন, দ্বিজেন্দ্রলাল রায়, রজনীকান্ত সেন — এই পাঁচজনের গান নামসহ প্রকাশিত সংকলনে বিদ্যমান। এখানে "Traditional" লেখা কেবল আর্থিকভাবে ক্ষতিকর নয়, তথ্যগতভাবে ভুল। কম্পোজার ও লিরিসিস্ট ফিল্ডে রচয়িতার নাম বসান — এবং সেই নামের একটি ক্যানোনিকাল বানান ঠিক করে প্রতিটি রিলিজে সেটাই ব্যবহার করুন, কারণ "Rabindranath Tagore", "Rabindra Nath Thakur" ও "রবীন্দ্রনাথ ঠাকুর" ম্যাচিং সিস্টেমের কাছে তিনটি আলাদা স্ট্রিং।

২.২ যাঁদের রচয়িতা জানা, অথচ যাঁরা নিয়মিত লোকসংগীত বলে ফাইল হন

এই তালিকাটাই আসল সমস্যা। এই গানগুলো শোনায় লোকসংগীতের মতো, বাউল বা ভাটির আসরে গাওয়া হয়, এবং বহু রিলিজে বিনা দ্বিধায় "Traditional" বসিয়ে দেওয়া হয়। অথচ:

• শাহ আবদুল করিম (১৯১৬–২০০৯) — "Karim wrote and composed over 1600 songs", ছয়টি সংকলনে ১৯৪৮ থেকে ২০০১ সালের মধ্যে প্রকাশিত (Shah Abdul Karim)। তিনি একবিংশ শতাব্দী পর্যন্ত বেঁচে ছিলেন। "বন্দে মায়া লাগাইছে" বা "কেন পিরিতি বাড়াইলা রে বন্ধু" কোনো অর্থেই অজ্ঞাত-রচয়িতার গান নয়।
• রাধারমণ দত্ত (১৮৩৩–১৯১৫) — ধামাইল গানের প্রবর্তক হিসেবে পরিচিত, দুই হাজারেরও বেশি গানের রচয়িতা; "ভ্রমর কইও গিয়া" তাঁরই (Radharaman Dutta)।
• হাসন রাজা (১৮৫৪–১৯২২) — সিলেটের মরমি কবি ও গীতিকার; হাসন রাজা সমগ্র-তে ৫০০টি কবিতা ও গান সংকলিত (Hason Raja)।
• লালন (মৃত্যু ১৮৯০) — নিচে আলাদা করে আলোচ্য, কারণ তাঁর ক্ষেত্রে প্রশ্নটি ভিন্ন।

এই চারজনের কোনো গানকে "Traditional" হিসেবে ফাইল করলে আপনি একজন নথিভুক্ত রচয়িতার ওয়ার্ককে অজ্ঞাত ঘোষণা করছেন — এবং সেই ঘোষণা ডাউনস্ট্রিমের প্রতিটি ডেটাবেসে কপি হয়ে যায়।

২.৩ যেখানে "Traditional" সত্যিই সঠিক

উল্টো দিকটাও সমান গুরুত্বপূর্ণ, নইলে মানুষ ভয়ে সব জায়গায় নাম বসাতে শুরু করে। ভাটিয়ালি, ভাওয়াইয়া, জারি, সারি — এগুলো ধারা, রচনা নয়। মেঘনা-পদ্মার মাঝির ভাটিয়ালি, রংপুর-কোচবিহারের গাড়িয়ালের ভাওয়াইয়া, কারবালার কাহিনি নিয়ে জারি, নৌকাবাইচের সারি — এদের বহু গানের কোনো নির্দিষ্ট নথিভুক্ত রচয়িতা নেই; পাঠ অঞ্চলভেদে বদলায়, এবং সংগ্রাহকের খাতায় ওঠার আগে বাহকই ছিল একমাত্র রক্ষক। এখানে "Traditional" সঠিক উত্তর, এবং সেটিই লিখুন।

তবে দুটি শর্ত মনে রাখুন। প্রথমত, ধারা আর রচনা এক করে ফেলবেন না: একটি গান ভাটিয়ালি ঢঙে গাওয়া হলেই সেটি অজ্ঞাত-রচয়িতার হয়ে যায় না — আবদুল আলীম যে গানগুলো জনপ্রিয় করেছেন তার অনেকগুলোর রচয়িতা জানা। দ্বিতীয়ত, প্রকৃত ঐতিহ্যবাহী গানেও আপনার অ্যারেঞ্জমেন্ট আপনার নিজের কাজ; সেটি অ্যারেঞ্জার রোলে ক্রেডিট করুন, রচয়িতার ঘরে নয়।

২.৪ লালনের বিশেষ ক্ষেত্র: রচয়িতা জানা, পাঠ বিতর্কিত

লালনকে আলাদা করে বলা দরকার, কারণ তাঁর ক্ষেত্রে সমস্যাটি "রচয়িতা অজ্ঞাত" নয় — সমস্যা হলো কোন গানটি সত্যিই তাঁর। লালন নিজে গান লিখে রাখেননি: "Lalon left no written copies of his songs, which were transmitted orally and only later transcribed by his followers", এবং তাঁর নামে প্রচলিত গানের সংখ্যা ২,০০০ থেকে ১০,০০০ পর্যন্ত বলা হলেও "only about 800 songs are generally considered authentic" (Lalon)।

এর ব্যবহারিক অর্থ: লালনগীতিকে "Traditional" বানিয়ে দেবেন না — রচয়িতা হিসেবে লালনের নামই দিন, কারণ তিনি একজন নির্দিষ্ট, নথিভুক্ত ব্যক্তি। কিন্তু যদি আপনি এমন কোনো পাঠ রেকর্ড করেন যার লালন-কর্তৃত্ব নিয়ে প্রশ্ন আছে, সেটি স্বীকার করুন এবং যে সংকলন থেকে পাঠ নিয়েছেন তার হদিস নিজের নথিতে রেখে দিন। বিরোধ হলে আপনার হাতে উৎস থাকা আর না-থাকার তফাত পুরোটাই।

"Traditional" একটি তথ্যগত দাবি — এই ওয়ার্কের কোনো শনাক্তযোগ্য রচয়িতা নেই। ভাটিয়ালি বা সারির ক্ষেত্রে সেটি সাধারণত সত্য; রবীন্দ্রসঙ্গীত বা শাহ আবদুল করিমের গানের ক্ষেত্রে সেটি মিথ্যা, এবং সেই মিথ্যার দাম প্রকাশনা-রয়্যালটিতে শোধ করতে হয়।

২.৫ সিদ্ধান্ত-সারণি: কোন গানে কী লিখবেন

একটি সাধারণ ভুল এই সারণিতে ধরা পড়ে না, তাই আলাদা করে বলা দরকার: শিল্পীর নাম রচয়িতার ঘরে বসাবেন না। যিনি গেয়েছেন তিনি পারফর্মার; রচয়িতার ঘর ওয়ার্কের বর্ণনা। বাংলা ক্যাটালগে "কম্পোজার: [গায়কের নাম]" অত্যন্ত সাধারণ এবং সেটি একটি ভুল দাবি — এটি ঐ গায়ককে ওয়ার্কের লেখক বলে ঘোষণা করে, যা সোসাইটির দিকে সরাসরি বিরোধ তৈরি করতে পারে।

৩. ISRC-র গঠন, অক্ষর ধরে ধরে

বারোটি অ্যালফানিউমেরিক অক্ষর, চারটি ঘরে। IFPI একে বর্ণনা করে পাঁচ-অক্ষরের প্রিফিক্স (দুটি অক্ষর + তিনটি অ্যালফানিউমেরিক), তারপর দুই অঙ্কের year of reference, তারপর পাঁচ অঙ্কের designation code হিসেবে (IFPI ISRC structure)। পাঠযোগ্য রূপ: CC-XXX-YY-NNNNN

উদাহরণ: IN-Q4R-24-00087 — ভারতীয় এজেন্সির দেওয়া প্রিফিক্স, ২০২৪ সালে বরাদ্দ, ঐ বছরের ৮৭তম কোড।

হাইফেন কেবল দেখার জন্য

ISRC Handbook স্পষ্ট: "The letters 'ISRC' (the space) and the hyphens do not form part of the ISRC" (§5)। অর্থাৎ IN-Q4R-24-00087 আর INQ4R2400087 একই কোড। ডেটাবেসে বারো অক্ষরেই রাখুন — ডেলিভারি স্পেক হাইফেনহীন রূপ চায়, আর বারো-অক্ষরের ফিল্ডে পনেরো অক্ষরের স্ট্রিং পাঠানো মানে অকারণ ভ্যালিডেশন ব্যর্থতা।

চেক ডিজিট নেই

এটা আলাদা করে বলা দরকার, কারণ অনেকে ধরে নেন আছে। UPC-তে চেক ডিজিট আছে, ISWC-তে আছে, ISRC-তে নেই। স্পেসিফিকেশনে এমন কিছু রাখাই হয়নি, এবং কোনো ভ্যালিডেটর আপনাকে বলতে পারবে না যে একটি সুগঠিত ISRC আপনার রেকর্ডিংয়ের সঠিক ISRC কি না। যান্ত্রিকভাবে যাচাই করা যায় কেবল আকার: দুই অক্ষর, তিন অ্যালফানিউমেরিক, দুই অঙ্ক, পাঁচ অঙ্ক, একটি নিবন্ধিত কান্ট্রি কোড, একটি যুক্তিসংগত বছর।

ISRC-তে চেক ডিজিট নেই, তাই একটি অক্ষর উল্টে গেলে যা তৈরি হয় সেটিও দেখতে সম্পূর্ণ বৈধ একটি ISRC — কেবল সেটি অন্য কারও রেকর্ডিংয়ের।

এই অসামঞ্জস্যের কারণেই ISRC এন্ট্রিতে যতটা সন্দেহপ্রবণ হওয়া দরকার, UPC এন্ট্রিতে ততটা নয়: UPC-র ভুল সাধারণত নিজের চেক ডিজিটেই আটকায়, ISRC-র ভুল নির্বিঘ্নে পার হয়ে যায়।

Year of reference আসলে কী

এটি রেকর্ডিংয়ের বছর নয়, রিলিজের বছরও নয়। IFPI-র সংজ্ঞা অনুযায়ী এটি ISRC বরাদ্দের বছর — "the last two digits of that year (e.g. 15 for 2015, 20 for 2020)" — এবং IFPI সরাসরি লেখে যে "the year in which the ISRC is assigned may be a different year from the year of recording" (IFPI ISRC structure)।

এর কাজ প্রশাসনিক: এটি প্রতি বছর কোড-স্পেসকে নতুন করে খোলে, "to ensure that codes assigned in prior years cannot be inadvertently re-assigned" (একই সূত্র) — অর্থাৎ এটি একটি নেমস্পেস বিভাজক, তারিখের ঘর নয়।

বাংলা ক্যাটালগে এর গুরুত্ব বিশাল, কারণ এখানে পুরনো রেকর্ডিং নতুন করে কোড পাওয়ার ঘটনা নিয়ম, ব্যতিক্রম নয়। ১৯৬৮ সালের একটি টেপ যদি আপনি ২০২৬ সালে কোড দেন, year of reference হবে 26। সেটাই সঠিক; "ঠিক" করতে যাবেন না। এবং কখনো ISRC দেখে রেকর্ডিংয়ের তারিখ অনুমান করবেন না — রেকর্ডিংয়ের সাল মেটাডেটার ঘরে থাকে, শনাক্তকারী কোড পার্স করে নয়।

৪. নতুন ISRC কখন লাগে, আর কখন নেওয়া নিষেধ

মূল নীতিটি Handbook-এ দুই বাক্যে: "A recording with an ISRC that has not undergone material change since an ISRC was assigned shall not be assigned another ISRC" (§4.3), এবং "An ISRC that has been assigned to a recording shall never be re-assigned to another different recording" (§A.3)। এক রেকর্ডিং, এক কোড, চিরকাল — এবং এক কোড, এক রেকর্ডিং, চিরকাল।

নতুন কোড লাগবে

• রিমিক্স। "A remixed version of a recording will differ from the original and hence it shall be assigned a new ISRC" (§A.9.8)।
• এডিট। "A version that is edited, for example to mute or replace profanities, shall be assigned a new ISRC" (§A.9.4) — রেডিও এডিট, সংক্ষিপ্ত সিঙ্গল এডিট।
• লাইভ ভার্সন। "The live recording is completely different from the studio version and a new ISRC is required" (§A.9.1)। একই শিল্পীর একই গানের স্টুডিও ও মঞ্চ-রেকর্ডিং কখনোই এক কোড ভাগ করবে না।
• ইনস্ট্রুমেন্টাল বা উপাদান-বাদ-দেওয়া ভার্সন। "A version of a track where the vocal (or other element) has been suppressed shall also be assigned a new ISRC if it is intended for release" (§A.9.14)।
• উল্লেখযোগ্য দৈর্ঘ্য পরিবর্তন। Handbook সৃজনশীল বিষয়বস্তুকে প্রভাবিত করা দৈর্ঘ্য-পরিবর্তনকে material ধরে এবং ১০ সেকেন্ডের বেশি অ-সৃজনশীল পরিবর্তনকে চিহ্নিত করে (§A.10.2); IFPI-র FAQ একই সীমা পুনরুক্তি করে: "changes in playing time which exceed 10 seconds" (IFPI FAQ)।

রিমাস্টার: এখানেই প্রচলিত ধারণা ভুল

"রিমাস্টার মানেই নতুন ISRC" — কথাটা বহু জায়গায় লেখা থাকে এবং এটি ভুল। Handbook শর্তটি অনেক সংকীর্ণ করে বেঁধে দিয়েছে (§A.10.1): নতুন ISRC লাগবে যদি এবং কেবল যদি রিমাস্টারিংয়ের প্রক্রিয়াগুলো "involve the application of creative input to the recording itself"।

এবং Handbook স্পষ্টভাবে যা যা বাদ দেয়: সাধারণ লেভেল পরিবর্তন, invariant EQ, invariant কম্প্রেশন, ডি-নয়েজিং, ডি-ক্লিকিং, গতি ও পিচ সংশোধন, স্যাম্পল-রেট পরিবর্তন এবং ডিদারিং — "A new ISRC shall not be assigned in the context of essentially invariant or technological adjustment processes."

এই ব্যতিক্রম-তালিকাটা পড়ে দেখুন: এটি প্রায় হুবহু সেই কাজের তালিকা যা একটি পুরনো টেপ বা শেলাক ডিস্ক ডিজিটাইজ করতে গিয়ে করতে হয়। সেই কারণেই পরের অনুচ্ছেদটি বাংলা ক্যাটালগের জন্য এত গুরুত্বপূর্ণ।

নিরাপদ ও বলার মতো ব্যবহারিক শর্ত একটাই: রিমাস্টারটি যদি মূল ট্র্যাকের পাশাপাশি আলাদা ট্র্যাক হিসেবে বিক্রি হয়, তবে সেটি আলাদা পণ্য এবং তার নিজস্ব কোড দরকার — ইঞ্জিনিয়ারিংকে আপনি যেভাবেই শ্রেণিভুক্ত করুন না কেন।

নতুন কোড লাগবে না

• একই মাস্টারের পুনঃপ্রকাশ। নতুন প্রচ্ছদ, নতুন ডিস্ট্রিবিউটর, নতুন টেরিটরি বা নতুন রিলিজ ডেট রেকর্ডিংয়ের পরিবর্তন নয়। ISRC থেকে যায়।
• অপরিবর্তিত রেকর্ডিংয়ের মালিকানা বদল। "If the original Registrant sells or licenses the recording in unchanged form after it has been given an ISRC, no new ISRC shall be assigned and the ISRC for the recording shall remain the same" (§4.6)।
• নতুন UPC। সংকলন অ্যালবামের নিজস্ব UPC হয়; তার ভেতরের রেকর্ডিংগুলো নিজেদের ISRC ধরে রাখে।

একটি অসম ক্ষেত্র আছে, এবং সেটি বাংলা আর্কাইভের জন্য প্রাসঙ্গিক: IFPI-র FAQ বলে "if a recording did not have an ISRC originally, has changed ownership, and is being released unchanged by the current rights holder, a new ISRC should be assigned" (IFPI FAQ)। নিয়মটি বিদ্যমান কোড রক্ষা করে; যে রেকর্ডিংয়ের কোনোদিন কোড ছিল না তার জন্য কাল্পনিক বংশপরিচয় বানায় না।

কভার ভার্সন: নতুন রেকর্ডিং, পুরনো ওয়ার্ক

বাংলা রিলিজে সবচেয়ে বেশি যে প্রশ্নটা আসে: "আমি একটা রবীন্দ্রসঙ্গীত কভার করেছি — নতুন ISRC লাগবে?" উত্তর: হ্যাঁ, অবশ্যই — কিন্তু কারণটা "কভার" বলে নয়। এটি একটি সম্পূর্ণ নতুন রেকর্ডিং, আপনার গলা, আপনার সংগত, আপনার মাস্টার। নতুন রেকর্ডিং মানেই নতুন ISRC, ব্যতিক্রম নেই।

যা নতুন নয়, সেটি হলো ওয়ার্ক। গানটি আগের মতোই আছে, রচয়িতা আগের মতোই আছেন। তাই আপনার কভারের ISWC নতুন হওয়ার কথা নয়; আপনার রেকর্ডিংটির বিদ্যমান ওয়ার্কের সঙ্গে যুক্ত হওয়ার কথা। এখানেই সবচেয়ে বেশি ভুল হয়: কভার রিলিজ করতে গিয়ে অনেকে ওয়ার্ক ফিল্ডে নিজের নাম বসিয়ে দেন কারণ ফর্মে "আপনার গান" লেখা আছে। ফলে সোসাইটির ডেটাবেসে একই গানের একটি নকল ওয়ার্ক এন্ট্রি তৈরি হয়, দুটি ওয়ার্কে টাকা ভাগ হয়, এবং দুটিরই দাবিদার নিয়ে প্রশ্ন ওঠে।

আপনি যদি সত্যিই নতুন কিছু যোগ করে থাকেন — নতুন অন্তরা লিখেছেন, নতুন সুরে বেঁধেছেন, বা একটি প্রচলিত গানের নিজস্ব অ্যারেঞ্জমেন্ট তৈরি করেছেন — সেটি অ্যারেঞ্জার বা অ্যাডাপ্টর রোলে ঘোষণা করুন, মূল রচয়িতাকে সরিয়ে নয়। রোলগুলো একসঙ্গে থাকার জন্যই আছে।

সিদ্ধান্তের নিয়ম

একটাই প্রশ্ন করুন: শ্রোতা কি অন্য একটি অডিও ফাইল শুনবেন?

হ্যাঁ হলে — ভিন্ন পরিবেশনা, ভিন্ন মিক্স, ভিন্ন দৈর্ঘ্য, ভিন্ন বিষয়বস্তু — এটি ভিন্ন রেকর্ডিং, নতুন ISRC চাই। না হলে — বিটগুলো অভিন্ন, কেবল মোড়ক, দাম, টেরিটরি বা ডিস্ট্রিবিউটর বদলেছে — পুরনো ISRC-ই থাকবে।

তারপর নিরাপত্তা-যাচাই: কখনো একটি ISRC-কে দুটি ভিন্ন অডিও ফাইলের দিকে তাক করাবেন না। পরিবর্তনটি material কি না তা নিয়ে সংশয় থাকলে নতুন কোড দেওয়া মেরামতযোগ্য ভুল; দুটি রেকর্ডিংয়ে এক কোড বসানো মেরামতযোগ্য নয় — যত ডেটাবেস সেটি গিলবে, সবগুলোতেই দূষণ ছড়াবে, এবং ফেরত নেওয়ার উপায় নেই।

৫. আর্কাইভাল রিইস্যু: রেকর্ডিং পুরনো, কোড নতুন

বাংলা ভাণ্ডারের একটা বড় অংশ এখন ডিজিটাইজেশনের টেবিলে: HMV/Gramophone Company-র ৭৮ RPM শেলাক ডিস্ক, রেডিওর টেপ, আর ঢাকার ক্যাসেট-যুগের বিপুল ক্যাটালগ। এই কাজে চারটি প্রশ্ন বারবার ওঠে, এবং চারটিরই উত্তর নিয়মে আছে।

১. রেকর্ডিং ১৯৩২ সালের হলে ISRC-র বছর কী হবে? যে বছর আপনি কোডটি বরাদ্দ করছেন — সম্ভবত 26। ISRC-র বছরের ঘর কোড তৈরির সময় বলে, সংগীত তৈরির সময় নয় (অনুচ্ছেদ ৩)। রেকর্ডিংয়ের প্রকৃত সাল যাবে মেটাডেটায়, বিশেষত original release date ফিল্ডে, যেটি খালি রাখলে প্রতিটি ডাউনস্ট্রিম সিস্টেম ধরে নেবে এটি এই বছরের নতুন গান।

২. পুরনো ডিস্ক পরিষ্কার করা কি রিমাস্টারিং, নাকি নতুন রেকর্ডিং? কোনোটাই নয় — ওটা একটি বিদ্যমান রেকর্ডিংয়ের কারিগরি পুনরুদ্ধার। ডি-ক্লিকিং, ডি-নয়েজিং, গতি সংশোধন (৭৮ RPM ডিস্ক প্রায়ই ঠিক ৭৮-এ বাজেনি), স্যাম্পল-রেট রূপান্তর, ডিদারিং — Handbook §A.10.1 এই সবগুলোকেই নাম ধরে "essentially invariant or technological adjustment processes" বলে চিহ্নিত করে, যেগুলোর জন্য নতুন ISRC বরাদ্দ করা হবে না। রেকর্ডিংটি অবশ্য এর আগে কখনো ISRC পায়নি, তাই এটি তার প্রথম কোড পাবে — কিন্তু কারণটা "রিমাস্টার" নয়, কারণটা হলো কোড কখনো ছিলই না।

৩. কোথায় গিয়ে এটা সৃজনশীল হয়ে যায়? যেখানে আপনি সিদ্ধান্তমূলকভাবে শব্দটাকে বদলাচ্ছেন, পুনরুদ্ধার করছেন না: মূলে না-থাকা রিভার্ব যোগ, স্টেরিও পুনর্নির্মাণ, ট্র্যাক ছেঁটে বা জুড়ে দেওয়া, চরিত্র বদলে দেওয়ার মতো টোনাল রিশেপিং। সেটা সৃজনশীল ইনপুট, এবং তখন নতুন কোড। ব্যবহারিক পরামর্শ: আপনি ঠিক কী কী প্রসেস চালিয়েছেন তার একটি তালিকা রাখুন — প্রশ্ন উঠলে ঐ তালিকাই আপনার যুক্তি।

৪. এক টেপ থেকে দুই ভার্সন বেরোলে? যদি আপনি "restored" আর "original transfer" দুটোই আলাদা ট্র্যাক হিসেবে ছাড়েন, ওগুলো দুটি পণ্য, দুটি ISRC — নির্বিশেষে ইঞ্জিনিয়ারিং সৃজনশীল ছিল কি না। শ্রোতা দুটি ভিন্ন অডিও ফাইল পাচ্ছেন; নিয়মটি সেখানেই শেষ।

একটি ৭৮ RPM ডিস্ক থেকে ট্র্যাক ভাগ করা

পুরনো শেলাক ডিস্কে সাধারণত প্রতি পিঠে একটি গান, এবং ট্রান্সফার প্রায়ই হয় গোটা পিঠ একসঙ্গে — শুরুতে সুচ নামার শব্দ, শেষে রান-আউট। প্রশ্ন ওঠে: একটি ট্রান্সফার ফাইল, কিন্তু রিলিজ হবে দুটি ট্র্যাক হিসেবে — কয়টি ISRC?

উত্তরটা শ্রোতার দিক থেকে ভাবুন: শ্রোতা দুটি আলাদা অডিও ফাইল পাচ্ছেন, দুটি আলাদা গান, দুটি আলাদা ওয়ার্ক। তাই দুটি ISRC, এবং প্রতিটির সঙ্গে নিজস্ব ওয়ার্ক-ক্রেডিট। মূল ট্রান্সফার ফাইলটি আপনার আর্কাইভাল মাস্টার — সেটি যদি কখনো প্রকাশ না করেন, তার কোনো ISRC লাগে না। কোড লাগে প্রকাশিত রেকর্ডিংয়ের, আপনার হার্ডডিস্কে থাকা কাজের ফাইলের নয়।

একই যুক্তি ক্যাসেট-যুগের ক্যাটালগে: একটি সাইড একটানা ট্রান্সফার করে পরে ট্র্যাকে ভাগ করলে ভাগ করা ট্র্যাকগুলোই প্রকাশিত রেকর্ডিং, এবং কোড তারা পায়।

পুরনো টেপ পরিষ্কার করা প্রযুক্তিগত কাজ, সৃজনশীল রিমাস্টারিং নয় — কিন্তু যে রেকর্ডিংয়ের কোনোদিন ISRC ছিল না, সে তার প্রথম ISRC পাবেই।

আর্কাইভাল রিইস্যুতে P-line নিয়েও সতর্ক থাকুন: P-line-এর সাল হলো সাউন্ড রেকর্ডিংটির প্রথম প্রকাশের সাল, আপনার আপলোডের সাল নয়। মালিকানা-শৃঙ্খল অস্পষ্ট হলে সেটি রিলিজের আগেই মীমাংসা করুন — শনাক্তকারী কোড ঠিক থাকলেও অধিকারের দাবি ভুল থাকলে ফল একই: টাকা আটকে থাকে।

৬. ISWC এবং যে ক্রেডিটটা হারিয়ে যায়

বাংলা রিলিজে সবচেয়ে বেশি খালি থাকা দুটি ফিল্ড হলো কম্পোজার ও লিরিসিস্ট, এবং সবচেয়ে বেশি টাকা সেখানেই হারায়। কারণটা কাঠামোগত: রেকর্ডিং-পক্ষের টাকা ISRC ধরে চলে, প্রকাশনা-পক্ষের টাকা চলে ISWC এবং সোসাইটির ডেটাবেসে থাকা ISRC↔ISWC জোড় ধরে। প্রথমটা ঠিক করে দ্বিতীয়টা ফাঁকা রাখলে গানটা বাজে, স্ট্রিম বাড়ে, ড্যাশবোর্ডে সংখ্যা ওঠে — আর লেখকের টাকা কোথাও পৌঁছায় না।

ISWC নিজে তুলতে যাবেন না; এটি বরাদ্দ হয় রেজিস্ট্রেশনের সময়। ISWC এজেন্সির ভাষায়: "For new works, no steps are necessary. Works will be automatically assigned a number as part of the registration process", এবং "Registration Agencies are responsible for the assignment of ISWCs" (ISWC — Getting an ISWC)। আপনার কাজ হলো ওয়ার্কটিকে যথাযথভাবে রেজিস্টার করা — সঠিক রচয়িতার নাম ও সঠিক শেয়ার সহ।

মেডলি, ধামাইল-পটপুরি ও আসরের রেকর্ডিং: এক রেকর্ডিং, একাধিক ওয়ার্ক

ISRC আর ISWC-র সম্পর্ক সবসময় এক-থেকে-এক নয়, এবং বাংলা ভাণ্ডারে এই ব্যতিক্রম নিয়মিত ঘটে।

মেডলি বা পটপুরি। বিয়েবাড়ির ধামাইলের একটানা মালা, কিংবা এক ট্র্যাকে গাঁথা তিনটি নজরুলগীতি — এটি একটি রেকর্ডিং, তাই একটি ISRC। কিন্তু এর ভেতরে তিনটি আলাদা ওয়ার্ক আছে, এবং প্রতিটির রচয়িতা ও শেয়ার আলাদাভাবে ঘোষণা করতে হবে। এক ISRC, একাধিক ISWC-লিঙ্ক — এটি বৈধ কাঠামো, এবং প্রকাশনার টাকা ঠিকভাবে ভাগ হওয়ার একমাত্র উপায়।

আসরের লাইভ রেকর্ডিং। একটি বাউল আসর বা রবীন্দ্রজয়ন্তীর অনুষ্ঠান একটানা রেকর্ড হলে দুটি পথ আছে, এবং সিদ্ধান্তটা প্রকাশের সময়েই নিতে হয়। যদি আপনি গোটা অনুষ্ঠানকে একটি দীর্ঘ ট্র্যাক হিসেবে ছাড়েন, সেটি একটি রেকর্ডিং, একটি ISRC, ভেতরে যত গান তত ওয়ার্ক-ক্রেডিট। যদি গান ধরে ধরে ভাগ করে ছাড়েন, প্রতিটি ভাগ একটি করে রেকর্ডিং, প্রতিটির নিজস্ব ISRC। মাঝপথে সিদ্ধান্ত বদলাবেন না — একই অডিও একবার আস্ত এবং একবার ভাগ করে ছাড়লে সেগুলো আলাদা রেকর্ডিং হিসেবেই গণ্য হবে, এবং শ্রোতার সংখ্যা দুই ভাগ হয়ে যাবে।

কথন বা ভূমিকা। আসরের রেকর্ডিংয়ে গানের আগে দীর্ঘ কথন থাকলে সেটি ট্র্যাকের অংশ, আলাদা কিছু নয় — যদি না আপনি সেটিকে আলাদা ট্র্যাক হিসেবে প্রকাশ করেন, তখন সেটিরও নিজস্ব ISRC লাগবে।

রবীন্দ্রসঙ্গীতের ক্ষেত্রে একটা বাড়তি সূক্ষ্মতা আছে যেটা লিখে রাখা দরকার: একই গানের ISWC থাকতেও পারে, নাও থাকতে পারে — নির্ভর করে কেউ কোথাও সেটি রেজিস্টার করেছে কি না। তাই "এক ওয়ার্ক, এক ISWC" কথাটি যথাযথ রূপে লিখুন: যেখানে রেজিস্টার্ড, সেখানে এক ISWC। কোনো সোসাইটির ডেটাবেসে আগে থেকে ওয়ার্কটি থাকলে আপনার রেজিস্ট্রেশন সেটির সঙ্গে যুক্ত হওয়া উচিত, নতুন ডুপ্লিকেট ওয়ার্ক তৈরি করা নয় — ডুপ্লিকেট ওয়ার্ক এন্ট্রি সোসাইটির দিক থেকে ঠিক ততটাই ক্ষতিকর, যতটা ডুপ্লিকেট ISRC ডিস্ট্রিবিউশনের দিকে।

৭. প্রিফিক্স কোথা থেকে আসে: ভারত ও বাংলাদেশ

ISRC প্রিফিক্স জাতীয় ISRC এজেন্সি বরাদ্দ করে, এবং এখানে দুই বাংলার অবস্থা আলাদা (২০২৬-০৯-০৭ তারিখে IFPI-র তালিকা যাচাই করা):

• ভারত — জাতীয় এজেন্সি তালিকাভুক্ত: The Indian Music Industry, মুম্বাই (ISRC Agency Contacts)।
• বাংলাদেশ — ঐ তালিকায় বাংলাদেশের কোনো জাতীয় এজেন্সি নেই। পৃষ্ঠাটি এই অবস্থার জন্য নির্দেশ দেয়: "If you are based in a country which is not mentioned in the lists above, please apply for your ISRC Prefix code through the International ISRC Agency" — যেটি c/o IFPI, লন্ডন।

ঢাকার কোনো লেবেল যদি নিজের প্রিফিক্স চায়, পথটা তাই ইন্টারন্যাশনাল এজেন্সি হয়ে। আর যদি নিজের প্রিফিক্স না নিয়ে ডিস্ট্রিবিউটরের দেওয়া কোড ব্যবহার করেন, সেটাও বৈধ — শর্ত একটাই, ডিস্ট্রিবিউটরকে অনুমোদিত ISRC Manager হতে হবে; IFPI এই তালিকা রক্ষণাবেক্ষণ করে (ISRC Managers)। যে সার্ভিসের কোনো বরাদ্দ নেই, তার বানানো বারো-অক্ষরের স্ট্রিং ISRC নয়; সেটি একটি সংঘর্ষের অপেক্ষায় থাকা স্ট্রিং।

যেটা মানুষকে বিভ্রান্ত করে: কোডটি রেকর্ডিংয়ের, কিন্তু প্রিফিক্সটি যে নিবন্ধন করেছে তার। ডিস্ট্রিবিউটর আপনাকে IN-Q4R-24-00087 দিলে INQ4R তার রেজিস্ট্র্যান্ট কোড। ঐ বারো-অক্ষরের ISRC আপনি ঐ রেকর্ডিংয়ে চিরকাল ব্যবহার করবেন — সেটাই বাধ্যতামূলক — কিন্তু ডিস্ট্রিবিউটর ছাড়ার পর INQ4R-এর নিচে নতুন কোড আপনি বানাতে পারবেন না, তাই পরের রিলিজে অন্য প্রিফিক্স আসবে। মিশ্র প্রিফিক্সের ক্যাটালগ কোনো ত্রুটি নয়; ডুপ্লিকেট ডেজিগনেশন কোডের ক্যাটালগ ত্রুটি।

নিজের প্রিফিক্স নেওয়া যুক্তিসংগত যখন: আপনি একাধিক শিল্পীর লেবেল চালান; একাধিক ডিস্ট্রিবিউটরের মধ্য দিয়ে ছাড়েন কিন্তু একটাই স্থিতিশীল প্রিফিক্স চান; ডেলিভারির আগে কোড দরকার হয় (সিংক, ফিজিক্যাল উৎপাদন, সম্প্রচার, সোসাইটি রেজিস্ট্রেশন); অথবা আপনি চান আপনার কোড কোনো কোম্পানির টিকে থাকার ওপর নির্ভর না করুক — আর্কাইভ ডিজিটাইজ করা প্রতিষ্ঠানের জন্য এই শেষ কারণটাই সাধারণত নির্ণায়ক।

৮. UPC ও EAN: পণ্যের শনাক্তকারী

UPC-A ১২ অঙ্ক, EAN-13 ১৩ অঙ্ক। দুটিই GS1-এর Global Trade Item Number — GTIN-12 ও GTIN-13 — একই কাঠামোয়: GS1 কোম্পানি প্রিফিক্স, ব্র্যান্ড-মালিকের দেওয়া আইটেম রেফারেন্স, আর শেষ ঘরে একটি চেক ডিজিট।

UPC পণ্য শনাক্ত করে: এই অ্যালবাম, এই কনফিগারেশন। একই রেকর্ডের ডিজিটাল অ্যালবাম, সিডি এবং ভিনাইল তিনটি পণ্য, স্বাভাবিকভাবে তিনটি UPC। সিঙ্গলের নিজস্ব UPC হয়; সেই রেকর্ডিং পরে অ্যালবামে এলে তার ISRC এক থাকে, অ্যালবামের UPC আলাদা।

GS1 সংরক্ষণের একটি নির্দিষ্ট পরামর্শ দেয়: "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 নিজে লেখে: "Since GS1 user companies can manufacture products anywhere in the world, GS1 Prefixes do not identify the country of origin for a given product" (GS1 company prefix)। প্রিফিক্স বলে কোন GS1 সদস্য সংস্থা নম্বরটি ইস্যু করেছে, পণ্যটি কোথায় তৈরি তা নয়। বাংলা প্রেক্ষাপটে একটি সতর্কতা যোগ করা দরকার: ইন্টারনেটে ছড়ানো বহু "বারকোড কান্ট্রি কোড" তালিকা 894-কে বাংলাদেশ বলে দেখায়, কিন্তু GS1-এর নিজের বর্তমান তালিকায় (২০২৬-০৯-০৭ যাচাই) 890 = GS1 India এবং 894 = "Managed by GS1 Global Office for future MO"। কোনো প্রিফিক্স নিয়ে নিশ্চিত হতে চাইলে GS1-এর প্রাথমিক পৃষ্ঠাটি দেখুন, তৃতীয় পক্ষের তালিকা নয়।

সংকলন ও পূজার সিঙ্গল: নতুন UPC, পুরনো ISRC

বাংলা বাজারে দুটি প্রথা এই নিয়মটিকে প্রতি বছর পরীক্ষা করে।

সংকলন অ্যালবাম। "শ্রেষ্ঠ নজরুলগীতি" ধরনের সংকলন বাংলা ক্যাটালগে অত্যন্ত সাধারণ, এবং এখানে ভুলটা যান্ত্রিক: নতুন পণ্য তৈরি করতে গিয়ে ভেতরের ট্র্যাকগুলোকেও নতুন কোড দিয়ে দেওয়া। সঠিক কাঠামো হলো — সংকলনটি একটি নতুন পণ্য, তাই নতুন UPC; কিন্তু ভেতরের রেকর্ডিংগুলো অপরিবর্তিত, তাই তারা তাদের পুরনো ISRC ধরে রাখবে। ভেতরের কোড বদলে দিলে প্রতিটি ট্র্যাকের জমা হওয়া ইতিহাস — স্ট্রিম, প্লেলিস্ট, সোসাইটি রেজিস্ট্রেশন — সংকলনের সংস্করণে পৌঁছায় না, এবং আপনি কার্যত নিজের ক্যাটালগের সঙ্গে নিজে প্রতিযোগিতা করেন।

পূজার সিঙ্গল ও বার্ষিক পুনঃপ্রকাশ। কলকাতার শারদীয়া প্রকাশনার প্রথায় বছরে বছরে একই রেকর্ডিং নতুন মোড়কে ফিরে আসে। নিয়ম একই এবং আরও কঠোরভাবে প্রযোজ্য: মোড়ক নতুন, রেকর্ডিং পুরনো — নতুন UPC, পুরনো ISRC। প্রতি বছর নতুন ISRC দিলে আপনার সবচেয়ে জনপ্রিয় রেকর্ডিংটি প্রতি বছর শূন্য থেকে শুরু করে।

সংক্ষেপে: প্যাকেজ বদলালে UPC বদলায়; অডিও বদলালে ISRC বদলায়। দুটি ঘটনা সাধারণত একসঙ্গে ঘটে না।

একটি শূন্য বসালে চেক ডিজিট বদলায় না কেন

এই কথাটা সবাই বলে, কেউ ব্যাখ্যা করে না। কারণটা সহজ: GS1 অ্যালগরিদমের ওজনগুলো সংখ্যার ডান প্রান্ত থেকে গোনা হয়, বাঁ প্রান্ত থেকে নয়।

চেক ডিজিট বসে সবচেয়ে ডানে। তার ঠিক আগের অঙ্ক থেকে বাঁ দিকে এগোতে এগোতে ওজন পালা করে ×৩, ×১, ×৩, ×১ — অনির্দিষ্টকাল। যেহেতু এই প্যাটার্নটি চেক ডিজিটের অবস্থানের সাপেক্ষে সংজ্ঞায়িত, GTIN-12-এর প্রতিটি অঙ্ক ১৩ বা ১৪ অঙ্কে প্যাড করার পরেও ঠিক একই ওজন ধরে রাখে। কিছুই সরে না।

তাই বাঁয়ে একটি শূন্য বসালে যোগফলে একটি পদ যুক্ত হয়, আর সেই পদটি ০ × ৩ বা ০ × ১ — দুই ক্ষেত্রেই শূন্য। যোগফল অপরিবর্তিত, সুতরাং পরবর্তী দশের গুণিতকে পৌঁছাতে যা লাগে সেটিও অপরিবর্তিত, সুতরাং চেক ডিজিট অপরিবর্তিত।

ব্যবহারিক অর্থ: 890412738659 আর 0890412738659 একই GTIN। কোনো সিস্টেম একটি রূপ প্রত্যাখ্যান করলে সেটি ফরম্যাটিংয়ের নিয়ম, দুটি আলাদা পণ্য নয় — সেটি মেটাতে দ্বিতীয় UPC কিনবেন না।

৯. চেক ডিজিট হাতে কষা

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: ৮৯০৪১২৭৩৮৬৫৯। প্রথম এগারোটি অঙ্ক ৮৯০৪১২৭৩৮৬৫, আর শেষের ৯ হলো সেই চেক ডিজিট যা আমরা বের করব। এগারোটি অঙ্ক ডান থেকে পড়ে:

যোগফল: ১৫ + ৬ + ২৪ + ৩ + ২১ + ২ + ৩ + ৪ + ০ + ৯ + ২৪ = ১১১।

১১১-এর সমান বা তার চেয়ে বড় নিকটতম দশের গুণিতক = ১২০। ১২০ − ১১১ = ৯।

চেক ডিজিট ৯, অর্থাৎ সম্পূর্ণ UPC-A: ৮৯০৪১২৭৩৮৬৫৯ ✓

একই হিসাব ASCII অঙ্কে

বাংলা অঙ্ক পড়তে স্বাভাবিক, কিন্তু ডেলিভারি ফাইলে কখনোই বাংলা অঙ্ক পাঠাবেন না — শনাক্তকারী ঘরগুলোতে ASCII 0–9 ছাড়া কিছু চলে না, এবং কোনো ইউনিকোড নর্মালাইজেশন ফর্ম ০১২৩-কে 0123-এ ভাঁজ করে না। তাই একই হিসাব ASCII-তে:

UPC-A 890412738659, প্রথম এগারো অঙ্ক 89041273865। ডান থেকে:

5×3=15, 6×1=6, 8×3=24, 3×1=3, 7×3=21, 2×1=2, 1×3=3, 4×1=4, 0×3=0, 9×1=9, 8×3=24

যোগফল = 15+6+24+3+21+2+3+4+0+9+24 = 111 → পরবর্তী দশের গুণিতক 120 → 120 − 111 = 9। ফল অভিন্ন, যেমন হওয়ার কথা: অঙ্কের লিপি বদলালেও মান বদলায় না।

এবার EAN-13। বাঁয়ে শূন্য বসান: 0890412738659। চেক ডিজিটের আগের বারোটি অঙ্ক 089041273865। ডান থেকে পড়লে মূল এগারোটি অঙ্ক হুবহু একই ওজন পায়; নতুন 0 পায় দ্বাদশ ওজন ×১, অবদান ০। যোগফল ১১১, পরবর্তী গুণিতক ১২০, চেক ডিজিট ৯ — অপরিবর্তিত, ঠিক যেমনটা অনুচ্ছেদ ৮ বলেছিল।

যাচাই করতে চাইলে (তৈরি করার বদলে) একই পদ্ধতি চালান, তবে চেক ডিজিটকেও ×১ ওজনে যোগে ঢোকান, এবং দেখুন মোট দশের গুণিতক হচ্ছে কি না। 890412738659-এর জন্য: 111 + 9 = 120। সংগত।

ISRC-র গঠন ও UPC/EAN চেক ডিজিট আপনি mazufa.com-এর বিনামূল্যের ব্রাউজার-ভিত্তিক টুল দিয়ে যাচাই করতে পারেন, যেটি সম্পূর্ণভাবে আপনার নিজের ডিভাইসেই চলে এবং কিছুই আপলোড করে না।

চেক ডিজিটের সীমা

চেক ডিজিট প্রমাণ করে সংখ্যাটি ঠিকভাবে টাইপ হয়েছে; প্রমাণ করে না যে সংখ্যাটি আপনার।

অ্যালগরিদমটি প্রতিটি একক-অঙ্কের ভুল ধরে, এবং পাশাপাশি অঙ্ক উল্টে যাওয়ার বেশিরভাগ ক্ষেত্রও ধরে — কিন্তু সবগুলো নয়। পাশাপাশি দুটি অঙ্কের পার্থক্য ঠিক ৫ হলে (০/৫, ১/৬, ২/৭, ৩/৮, ৪/৯) সেগুলো উল্টে গেলে ভারিত যোগফল ঠিক ±১০ বদলায়, ফলে চেক ডিজিট বৈধই থেকে যায়। এই শ্রেণির ভুল নিঃশব্দে পার হয়ে যায় — তাই UPC কেবল চেকারে ফেলে সন্তুষ্ট না হয়ে যে উৎস থেকে নম্বরটি পেয়েছেন তার সঙ্গে মিলিয়ে নিন।

১০. ঢাকা ও কলকাতা: এক রেকর্ডিং, দুই পণ্য

বাংলা রিলিজে একটি পরিস্থিতি প্রায়ই আসে যা অন্য ভাষায় ততটা আসে না: একই রেকর্ডিং দুই দেশে দুটি আলাদা প্রতিষ্ঠানের মাধ্যমে ছাড়া হয় — ঢাকা থেকে এক লেবেল, কলকাতা থেকে আরেক লেবেল। এতে দুটি রিলিজ তৈরি হয়, এবং প্রায়ই দুটি কোডও তৈরি হয়ে যায়। কোনটা ঠিক, কোনটা ভুল, সেটা আলাদা করা জরুরি।

যা সঠিক ও প্রত্যাশিত: দুটি আলাদা পণ্য মানে দুটি আলাদা UPC। কলকাতার পণ্য 890412738659, ঢাকার পণ্য 620735194487 — আলাদা প্রিফিক্স, আলাদা GS1 সদস্য সংস্থা, আলাদা পণ্য এন্ট্রি। এটি নিয়মের ভেতর: UPC পণ্যকে শনাক্ত করে, রেকর্ডিংকে নয়। প্রচ্ছদ আলাদা হতে পারে, ট্র্যাক-ক্রম আলাদা হতে পারে, টেরিটরি আলাদা — সবই বৈধ।

যা ভুল: একই অপরিবর্তিত রেকর্ডিংকে দুটি আলাদা ISRC দেওয়া। এটাই আসল বিপদ, এবং এটাই সবচেয়ে বেশি ঘটে — কারণ দুই প্রান্তে দুটি ডিস্ট্রিবিউটর অনবোর্ডিং ফর্ম পূরণ করছে, দুটোতেই "আমার ইতিমধ্যেই ISRC আছে" ঘরটি ফাঁকা, আর দুটি সিস্টেমই নিজের প্রিফিক্স থেকে নতুন কোড বানিয়ে দিচ্ছে। ফল: একটি রেকর্ডিং ডাউনস্ট্রিমে দুটি রেকর্ডিং হিসেবে বাঁচে। স্ট্রিম দুই ভাগ হয়, নেইবারিং-রাইটস দাবি দুই ভাগ হয়, চার্ট ইতিহাস দুই ভাগ হয়, এবং কোনো সোসাইটি নিজে থেকে এদের জুড়ে দেয় না।

Handbook §4.3-এ নিয়মটি সরাসরি: material পরিবর্তন না হলে দ্বিতীয় ISRC বরাদ্দ করা যাবে না। ভৌগোলিক সীমানা material পরিবর্তন নয়।

তাহলে করণীয়:

1. রেকর্ডিংটির ISRC আগে বরাদ্দ করুন — যেকোনো ডিস্ট্রিবিউশন চুক্তির আগে, একটি জায়গা থেকে।
2. দুই লেবেলের সঙ্গে চুক্তিতে ISRC-টি লিখিতভাবে উল্লেখ করুন, যাতে অনবোর্ডিং ফর্মে সেটি বসানো হয়, নতুন কোড তৈরি না হয়।
3. প্রতিটি ডিস্ট্রিবিউটরের ফর্মে "existing ISRC" ঘরটি পূরণ করুন — এই একটি অভ্যাস বাংলা রিলিজে সবচেয়ে বেশি ডুপ্লিকেট কোড ঠেকায়।
4. UPC আলাদা হতে দিন। সেটা সমস্যা নয়, সেটাই কাঠামো।
5. দুটি পণ্যেই ISWC ও রচয়িতার ক্রেডিট অভিন্ন রাখুন। ওয়ার্ক এক, তার বর্ণনাও এক হওয়া উচিত — একই গান দুই দেশে দুই রচয়িতার নামে ফাইল হলে সোসাইটির দিকে বিরোধ তৈরি হয়।

যদি দেরি হয়ে গিয়ে থাকে এবং দুটি ISRC ইতিমধ্যেই বাজারে থাকে, ক্ষতিটা মেনে নিয়ে সিদ্ধান্ত নিন কোনটি আপনার canonical কোড, বাকিটির ব্যবহার বন্ধ করুন, এবং দুটি ডিস্ট্রিবিউটর ও সংশ্লিষ্ট সোসাইটিকে লিখিতভাবে জানান। পূর্ববর্তী ইতিহাস সব ক্ষেত্রে ফেরত আসে না — এই কারণেই ক্রম ১ নম্বর ধাপটাই আসল সমাধান।

১১. সাধারণ ভুল ও তাদের কারণ

একই ISRC দুটি ভিন্ন রেকর্ডিংয়ে। সবচেয়ে খারাপ, কারণ এটি নিজে থেকে শোধরায় না: ডাউনস্ট্রিমের প্রতিটি ম্যাচিং সিস্টেম দুটি রেকর্ডিংকে চিরস্থায়ীভাবে একটি বলে ধরে। কারণ সাধারণত স্প্রেডশিটের কপি-পেস্ট বা টেমপ্লেটের যে সারিটি কেউ আপডেট করেনি।

অপরিবর্তিত পুনঃপ্রকাশে নতুন ISRC। রেকর্ডিংয়ের জমানো পরিচয় ফেলে দেয়: প্লেলিস্ট ইতিহাস, সোসাইটি রেজিস্ট্রেশন, নেইবারিং-রাইটস দাবি — সব পুরনো কোডে বাঁধা। কারণ: অনবোর্ডিং ফর্মে "existing ISRC" ঘরটি ফাঁকা রেখে দেওয়া।

ISRC-তে অক্ষর উল্টে যাওয়া। চেক ডিজিট নেই, ধরা পড়ে না। রেকর্ডিং এমন একটি কোডে ডেলিভার হয় যা হয় কারও নয় (প্লে unmatched থাকে) নয়তো অন্য কারও (তাঁর নামে জমা হয়)। প্রতিকার: হাতে টাইপ না করে কপি-পেস্ট, এবং একটি উৎস-তালিকার বিরুদ্ধে রিলিজের প্রতিটি ISRC মিলিয়ে নেওয়া।

"Traditional" ফিল্ড রিফ্লেক্স। রচয়িতা জানা থাকা সত্ত্বেও লোকঘরানার গান দেখলেই "Traditional" বেছে নেওয়া (অনুচ্ছেদ ২)। প্রকাশনা-পক্ষের টাকা রুট করার আর কোনো পথ থাকে না।

UPC যা নিজের চেক ডিজিটেই ব্যর্থ। প্রায় সবসময় টাইপো, ছাঁটা স্ট্রিং, বা স্প্রেডশিটের অটো-ফরম্যাটে মুছে যাওয়া প্রথম শূন্য। কলামটি পেস্ট করার আগে টেক্সট ফরম্যাটে দিন। এই ভুলটি অন্তত শব্দ করে — বেশিরভাগ ইনজেশন সিস্টেম এটি প্রত্যাখ্যান করে।

অডিও ডেলিভারি ও মেটাডেটার কোড না মেলা। সবচেয়ে নীরব এবং সবচেয়ে ব্যয়বহুল। অডিও ফাইলে এমবেড করা ISRC, DDEX বা স্প্রেডশিটে ঘোষিত ISRC, এবং সোসাইটি রেজিস্ট্রেশনের ISRC — তিনটিই একই বারো অক্ষর হতে হবে। আলাদা হলে সবকিছু কাজ করছে বলে মনে হয়: রিলিজ লাইভ হয়, স্ট্রিম জমে, ড্যাশবোর্ডে সংখ্যা ওঠে — আর ম্যাচিং ভাঙে এমন জায়গায় যা আপনি দেখতে পান না, কয়েক মাস পরে।

সবচেয়ে দামি শনাক্তকারী-ভুলগুলো সেগুলোই যেগুলো রিলিজটাকে লাইভ হতে দেয় এবং তারপর ম্যাচিং ভেঙে দেয়।

১২. স্ট্রিম থেকে পেমেন্ট: শিকলটা কোথায় ছেঁড়ে

পুরো শৃঙ্খলটি বোঝা থাকলে ঠিক কোন জায়গায় একটি ভাঙা কোড কী কাটে তা পরিষ্কার হয়।

1. প্লে ঘটে। সার্ভিস তার ক্যাটালগের রেকর্ডিংয়ের বিপরীতে প্লে ইভেন্ট লগ করে, যা আপনার ডেলিভার করা ISRC-র সঙ্গে মেলানো।
2. সার্ভিস রিপোর্ট করে। ব্যবহারের রিপোর্ট ISRC ধরে আইটেমাইজড হয়ে অধিকারধারী বা ডিস্ট্রিবিউটরের কাছে আসে, রিলিজ শনাক্ত হয় UPC দিয়ে। এখানে রেকর্ডিং-পক্ষের টাকা হিসাব হয় পুলড রেভিনিউয়ের ভাগ হিসেবে, প্রতি প্লে-র নির্দিষ্ট হার হিসেবে নয় — Spotify নিজেই বলে যে তারা প্রতি-স্ট্রিম হার দেয় না; রাজস্ব পুল হয়ে streamshare অনুযায়ী ভাগ হয়, তাই একটি প্লে-র মূল্য পুলের সঙ্গে ওঠানামা করে।
3. ডিস্ট্রিবিউটর হিসাব মেলায়। রিপোর্টের লাইনগুলো ISRC ও UPC ধরে আপনার ক্যাটালগের সঙ্গে মিলিয়ে আপনার স্টেটমেন্ট তৈরি হয়। রিপোর্টে থাকা যে ISRC আপনার ক্যাটালগে নেই, সেটি কখনো আপনার স্টেটমেন্টে পৌঁছায় না।
4. রচনার দিকটা সমান্তরালে চলে। গানের মেকানিক্যাল ও পারফরম্যান্স রয়্যালটি আদায় করে সোসাইটি ও মেকানিক্যাল লাইসেন্সিং সংস্থা, যারা রিপোর্ট করা ISRC-কে রেজিস্টার্ড ওয়ার্কের (ISWC) সঙ্গে জোড়ে, তারপর গীতিকার ও পাবলিশারের কাছে পাঠায়। আলাদা পাইপলাইন, আলাদা সময়সূচি, আলাদা টাকা।
5. নেইবারিং রাইটস। সম্প্রচার ও পাবলিক পারফরম্যান্স থেকে রেকর্ডিংয়ের আয় আদায় করে নেইবারিং-রাইটস সোসাইটি, ISRC ধরে — এমন একটি রেজিস্ট্রেশনের বিপরীতে যেখানে অধিকারধারী ও ফিচারড পারফর্মারদের নাম আছে।
6. পেমেন্ট। টাকা হস্তান্তর হয়, উৎসে কর-প্রক্রিয়া সাপেক্ষে।

প্রতিটি ধাপ একটি শনাক্তকারীর ওপর join, এবং join নীরবে ব্যর্থ হয়। ধাপ ১ বা ২-এ ISRC ভাঙলে রেকর্ডিং-পক্ষের টাকা unmatched। ধাপ ৪-এ ISRC↔ISWC জোড় ভাঙলে গীতিকারের টাকা unmatched — বাংলা ভাণ্ডারে এটাই সবচেয়ে ঘন ঘন ভাঙা জোড়। UPC ভাঙলে পণ্য-পর্যায়ের হিসাব মেলে না। আর অডিও ও মেটাডেটার মিল ভাঙলে সবগুলো একসঙ্গে ভাঙে।

কাজটা জৌলুসহীন এবং রিলিজপ্রতি ঘণ্টাখানেকের: একটি নির্ভরযোগ্য শিট রাখুন — ট্র্যাক শিরোনাম, ভার্সন, ISRC, ISWC, রচয়িতা ও শেয়ার, রিলিজ UPC, আর আর্কাইভ হলে original release date ও উৎস-নথি। শনাক্তকারী কলামগুলো টেক্সট ফরম্যাটে রাখুন। ISRC ডেলিভারির সময় নয়, তার আগেই বরাদ্দ করুন। প্রতিটি UPC-র চেক ডিজিট যাচাই করুন। অডিওতে এমবেড করা কোড শিটের সঙ্গে মিলিয়ে দেখুন। একই কোড দিয়ে রেকর্ডিং ও ওয়ার্ক সোসাইটিতে রেজিস্টার করুন। তারপর স্টেটমেন্টে যখন একটা লাইন নেই, আপনার হাতে তর্ক করার মতো একটি সত্য-উৎস থাকবে — সেটি না থাকলে কত টাকা পাওয়ার কথা ছিল তা প্রতিষ্ঠা করাই সম্ভব নয়।

রিলিজের আগে যাচাই-তালিকা

ডেলিভারির বোতাম টেপার আগে এই তালিকাটা এক পাশ থেকে অন্য পাশে পড়ে যান:

1. প্রতিটি ট্র্যাকের ISRC আছে, এবং সেটি এই রিলিজের আর কোনো ট্র্যাকের সঙ্গে অভিন্ন নয়।
2. যেসব রেকর্ডিং আগে প্রকাশিত হয়েছে, তাদের পুরনো ISRC বসানো হয়েছে — অনবোর্ডিং ফর্মের "existing ISRC" ঘর ফাঁকা নেই।
3. প্রতিটি ISRC ঠিক বারো অক্ষর, হাইফেনহীন, ASCII অক্ষর ও অঙ্কে।
4. UPC-র চেক ডিজিট হাতে বা টুলে যাচাই করা হয়েছে, এবং কলামটি টেক্সট ফরম্যাটে — প্রথম শূন্য অক্ষত।
5. প্রতিটি ট্র্যাকে কম্পোজার ও লিরিসিস্ট পূরণ করা; "Traditional" কেবল সেখানেই যেখানে সেটি সত্য (অনুচ্ছেদ ২.৫)।
6. মেডলি বা আসরের ট্র্যাকে ভেতরের প্রতিটি ওয়ার্কের ক্রেডিট আলাদাভাবে ঘোষিত।
7. পুরনো রেকর্ডিং হলে original release date ও P-line-এর সাল রেকর্ডিংয়ের, আপলোডের নয়।
8. অডিও ফাইলে এমবেড করা ISRC আর স্প্রেডশিটের ISRC অক্ষরে অক্ষরে মেলে।
9. একই রেকর্ডিং দুই দেশে ছাড়লে দুই ডিস্ট্রিবিউটরের কাছে একই ISRC গেছে (অনুচ্ছেদ ১০)।

সারসংক্ষেপ

Mazufa-র ডিস্ট্রিবিউশন বিনামূল্যে — কোনো আপলোড ফি নেই, সাবস্ক্রিপশন নেই, রিলিজপ্রতি চার্জ নেই — এবং একমাত্র কর্তন প্রাপ্ত রয়্যালটির ৫%; প্রতিটি সম্পূর্ণ আবেদন একজন মানুষ পর্যালোচনা করেন।

সূত্র

• IFPI, ISRC Structure (কান্ট্রি কোড, রেজিস্ট্র্যান্ট কোড, year of reference, ডেজিগনেশন কোড; year of reference-এর সংজ্ঞা ও উদ্দেশ্য) — https://isrc.ifpi.org/isrc-standard/isrc-structure
• IFPI, International Standard Recording Code (ISRC) Handbook (§4.3 material পরিবর্তন ছাড়া দ্বিতীয় ISRC নয়; §4.6 অপরিবর্তিত রেকর্ডিং বিক্রি বা লাইসেন্স হলে কোড এক থাকে; §5 হাইফেন কোডের অংশ নয়; §A.3 ISRC পুনর্বরাদ্দ নিষিদ্ধ; §A.9.1 লাইভ ভার্সন; §A.9.4 এডিট; §A.9.8 রিমিক্স; §A.9.14 উপাদান-বাদ-দেওয়া ভার্সন; §A.10.1 রিমাস্টারিং ও creative input; §A.10.2 দৈর্ঘ্য পরিবর্তন) — https://www.ifpi.org/wp-content/uploads/2021/02/ISRC_Handbook.pdf
• IFPI, ISRC FAQs (রিমিক্স ও এডিট; ১০ সেকেন্ডের সীমা; যে রেকর্ডিংয়ের কোনোদিন ISRC ছিল না তার পুনঃপ্রকাশ) — https://isrc.ifpi.org/faqs
• IFPI, ISRC Agency Contacts (ভারতের জাতীয় এজেন্সি The Indian Music Industry, মুম্বাই; তালিকায় না থাকা দেশের জন্য International ISRC Agency, c/o IFPI, লন্ডন — ২০২৬-০৯-০৭ যাচাই) — https://isrc.ifpi.org/contacts/isrc-agency-contacts
• IFPI, ISRC Managers (যেসব প্রতিষ্ঠান অধিকারধারীর পক্ষে ISRC বরাদ্দে অনুমোদিত) — https://isrc.ifpi.org/get-isrc/isrc-managers
• ISWC International Agency, The ISWC (গঠন: T + ৯ অঙ্ক + চেক ডিজিট; ISWC ওয়ার্ক শনাক্ত করে, তার manifestation নয়) — https://www.iswc.org/iswc
• ISWC International Agency, Getting an ISWC ("An ISWC code is only allocated by the local Registration Agency when all of the creators of the work have been uniquely identified"; নতুন ওয়ার্কে রেজিস্ট্রেশনের সময়ই স্বয়ংক্রিয় বরাদ্দ) — https://www.iswc.org/get-iswc
• GS1, Check Digit Calculator ও হাতে-কষার নির্দেশনা (ওজন, যোগফল, নিকটতম সমান বা বৃহত্তর দশের গুণিতক থেকে বিয়োগ) — https://www.gs1.org/services/check-digit-calculator
• GS1, Communicating GS1 trade item numbers (GTIN ১৪ অঙ্কে সংরক্ষণ, ছোট রূপে বাঁয়ে শূন্য) — https://www.gs1.org/edi-xml/technical-user-guide/Item_Numbers
• GS1, GS1 Company Prefix (প্রিফিক্স পণ্যের উৎপত্তির দেশ বোঝায় না; 890 = GS1 India, 894 = "Managed by GS1 Global Office for future MO" — ২০২৬-০৯-০৭ যাচাই) — https://www.gs1.org/standards/id-keys/company-prefix
• ISO 15707:2001, International Standard Musical Work Code (ISWC) — https://www.iso.org/standard/28780.html
• CISAC, International Identifiers (ISWC ব্যবস্থাপনা) — https://www.cisac.org/services/information-services/international-identifiers
• Rabindra Sangeet, Wikipedia (আনুমানিক ২,২৩২ গান; গীতবিতান; স্বরবিতানের ৬৪ খণ্ডে ১,৭২১টি গানের স্বরলিপিসহ পাঠ) — https://en.wikipedia.org/wiki/Rabindra_Sangeet
• Lalon, Wikipedia (মৃত্যু ১৮৯০; গান লিখে রাখেননি, শিষ্যেরা পরে লিপিবদ্ধ করেন; ২,০০০–১০,০০০ গান আরোপিত, প্রায় ৮০০টি সাধারণভাবে খাঁটি বলে বিবেচিত) — https://en.wikipedia.org/wiki/Lalon
• Shah Abdul Karim, Wikipedia (১৯১৬–২০০৯; "wrote and composed over 1600 songs"; ১৯৪৮–২০০১ সালের ছয়টি সংকলন) — https://en.wikipedia.org/wiki/Shah_Abdul_Karim
• Radharaman Dutta, Wikipedia (১৮৩৩–১৯১৫; ধামাইল গানের প্রবর্তক; দুই হাজারের বেশি গান; "ভ্রমর কইও গিয়া") — https://en.wikipedia.org/wiki/Radharaman_Dutta
• Hason Raja, Wikipedia (১৮৫৪–১৯২২; সিলেটের মরমি কবি ও গীতিকার; হাসন রাজা সমগ্র-তে ৫০০টি কবিতা ও গান) — https://en.wikipedia.org/wiki/Hason_Raja

উদাহরণ সম্পর্কে টীকা: 890412738659 ও 620735194487 কেবল চেক-ডিজিট হিসাব দেখানোর জন্য ব্যবহৃত কাঠামোগতভাবে বৈধ UPC-A; এগুলো কোনো নির্দিষ্ট রিলিজের শনাক্তকারী হিসেবে উপস্থাপিত নয়। একইভাবে IN-Q4R-24-00087 একটি কাল্পনিক ISRC।