BW64 আর ADM: ইমার্সিভ অডিও ডেলিভারির কারিগরি রেফারেন্স

আখড়া, কীর্তনের মিছিল আর ঢাকের বৃত্ত যে জিনিসটা স্টেরিওতে ধরা যায় না, সেটা ফাইলে ধরার ফরম্যাট — এবং যে স্টুডিওতে ইমার্সিভ মনিটরিং নেই সেখানে বসে সেই ফাইল কীভাবে যাচাই করবেন।

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

ADM (Audio Definition Model, সুপারিশ ITU-R BS.2076) একটা খোলা মেটাডেটা মডেল, যা বলে দেয় একটা ফাইলের প্রতিটা অডিও ট্র্যাক আসলে কী — একটা নির্দিষ্ট স্পিকারের চ্যানেল, নাকি জায়গা বদলাতে থাকা একটা অবজেক্ট, নাকি অ্যাম্বিসনিক শব্দক্ষেত্রের একটা উপাংশ — এবং সেগুলো মিলে কীভাবে একটা সম্পূর্ণ প্রোগ্রাম হয়। এই মেটাডেটা XML আকারে বসে থাকে BW64 কন্টেইনারের ভিতরে (সুপারিশ ITU-R BS.2088), যা RIFF/WAVE-এর একটা ৬৪-বিট সম্প্রসারণ এবং যার একমাত্র কারণ পুরনো WAV-এর ৪ GB সিলিং টপকানো। বাংলা রেকর্ডিংয়ের জন্য এর তাৎপর্য বিমূর্ত নয়: বাউলের আখড়া, নাম-কীর্তনের মিছিল আর পূজার ঢাকের দল — এই তিনটেতেই শ্রোতা পরিবেশনার সামনে নয়, পরিবেশনার ভিতরে থাকেন, আর কীর্তনের ক্ষেত্রে উৎসটা রেকর্ডিং চলাকালীনই জায়গা বদলায়; এই দুটোর কোনোটাই স্টেরিও ধরতে পারে না, কারণ স্টেরিওর কাছে "পিছন" বলে কিছু নেই আর "নড়াচড়া" বলে কিছু নেই। ইমার্সিভ ডেলিভারি QC-তে আটকায় কান খারাপ বলে নয়, আটকায় কারণ অডিও আর মেটাডেটা দুটো আলাদা জিনিস যাদের হুবহু মিলতে হবে, অথচ ফাইল ফরম্যাটের ভিতরে এমন কিছু নেই যা তাদের মিলতে বাধ্য করে। ADM-এর QC আসলে শোনার কাজ নয়, রেফারেন্স-অখণ্ডতা যাচাইয়ের কাজ — আর ঠিক এই কারণেই ঢাকা বা কলকাতার যে স্টুডিওতে একটাও ইমার্সিভ মনিটরিং রুম নেই, সেখানে বসেও এই ফাইল বৈধ কি না তার প্রায় পুরোটা প্রমাণ করা যায়।

১. আখড়ার মাঝখানে বসা শ্রোতা

ফরম্যাট দিয়ে শুরু করলে যুক্তিটা কখনো পরিষ্কার হয় না। শুরু করুন ঘর থেকে।

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

স্টেরিও এই পরিস্থিতিটাকে "খারাপভাবে" ধরে না। স্টেরিও এটাকে আদৌ ধরতে পারে না। স্টেরিওর প্যানোরামা দুটো স্পিকারের মধ্যেকার একটা রেখাংশ, প্রায় ৬০ ডিগ্রি চাপ; আখড়ার শব্দ আসে পূর্ণ ৩৬০ ডিগ্রি অ্যাজিমাথ থেকে, এবং তাঁবুর ছাউনি ও গাছের চাঁদোয়া থেকে প্রতিফলিত হয়ে উপর থেকেও। যে তথ্যটা হারায় সেটা "পরিবেশ" বা "ambience" নয় — যে তথ্যটা হারায় সেটা হলো শ্রোতা কোথায় দাঁড়িয়ে আছেন। বাউল আসরে ওই অবস্থানটাই অর্ধেক অভিজ্ঞতা।

এই কারণেই আখড়া ইমার্সিভ অডিওর একটা বিশুদ্ধ অবজেক্ট-প্লাস-বেড কেস, এবং সেটা আক্ষরিক অর্থেই:

• বেড — তাঁবু বা প্রাঙ্গণের সামগ্রিক শব্দক্ষেত্র: ভিড়ের গুঞ্জন, দূরের মাইকের চুঁইয়ে আসা আওয়াজ, রাতের পোকা, ছাউনি থেকে ফিরে আসা প্রতিফলন। এটা কোনো একক উৎস নয়, এটা একটা ক্ষেত্র। BS.2051-এর কোনো একটা লেআউটে ধরা চ্যানেল-ভিত্তিক বেড, বা উচ্চ-ক্রমের অ্যাম্বিসনিক (HOA), দুটোই যুক্তিসঙ্গত পছন্দ।
• অবজেক্ট — মূল কণ্ঠ ও একতারা (যা ঘোরে), দোতারা, খমক, বাঁশি, আর প্রতিটি করতাল-দল আলাদা আলাদা অবস্থানে। এদের প্রত্যেকের একটা নির্দিষ্ট দিক আছে, এবং সেই দিকটা মিশ্রণের সিদ্ধান্ত নয়, ঘটনার তথ্য।

আখড়ায় শ্রোতার অবস্থান পরিবেশনার অংশ। যে ফরম্যাট শ্রোতাকে বৃত্তের বাইরে বসাতে বাধ্য, সেটা শুধু কম জমকালো নয় — সেটা ভুল।

১.১ নাম-কীর্তনের মিছিল: যে উৎস নিজেই হেঁটে যায়

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

বাংলায় এমন একটা রূপ আছে যেখানে নড়াচড়াটা রূপক নয়, ঘটনা: নগর-কীর্তন, অর্থাৎ কীর্তনের মিছিল। খোল আর করতাল নিয়ে দল রাস্তা ধরে এগোয়। একটা স্থির অবস্থান থেকে রেকর্ড করলে — ধরুন বাড়ির ছাদে বা গলির মুখে একটা অ্যাম্বিসনিক মাইক বসিয়ে — যা রেকর্ড হয় তা হলো একটা উৎস, যেটা দূর থেকে আসে, পাশ দিয়ে যায়, তারপর দূরে মিলিয়ে যায়। রেকর্ডিংয়ের ন-মিনিটের মাথায় খোল বাদক শ্রোতার ডানদিকে; বারো মিনিটের মাথায় ঠিক পিছনে; আঠারো মিনিটের মাথায় বাঁ দিকে এবং অনেক দূরে।

স্টেরিওতে এটা প্যান অটোমেশন দিয়ে "নকল" করা যায়, কিন্তু ফল হয় একটা রেখার উপর বাঁ-থেকে-ডানে চলাচল — উৎস কখনো শ্রোতাকে অতিক্রম করে না, কারণ স্টেরিওতে অতিক্রম করার মতো কোনো পিছন নেই। ADM-এ এটাই আক্ষরিক অর্থে যা বর্ণনা করার জন্য মডেলটা তৈরি: একটা audioObject, যার audioChannelFormat-এর ভিতরে পরপর অনেকগুলো audioBlockFormat, প্রতিটির নিজস্ব rtime আর duration, এবং প্রতিটিতে একটা করে অ্যাজিমাথ-এলিভেশন-দূরত্ব (বা কার্তেসীয় X/Y/Z)। মিছিল যত এগোয়, ব্লকের অ্যাজিমাথ ক্রমশ ঘোরে, দূরত্ব কমে তারপর বাড়ে। রেন্ডারার সেটা যে ঘরে বাজছে সেই ঘরের স্পিকার দিয়ে বাস্তবায়িত করে — ৭.১.৪-এ একরকম, ৫.১-এ আরেকরকম, হেডফোনে তৃতীয়রকম, কিন্তু ঘটনাটা একই থাকে।

এটাই সময়-পরিবর্তনশীল অবজেক্ট অবস্থানের সবচেয়ে সৎ বাস্তব উদাহরণ, এবং QC-র দিক থেকেও সবচেয়ে ঝুঁকিপূর্ণ: ব্লকগুলোর টাইমিং একটুও এলোমেলো হলে উৎস হয় মাঝপথে থমকে যায়, নয়তো এক লাফে পিছিয়ে যায়। সেকশন ৭.৩-এ ঠিক এই ভুলটার কথা আছে।

১.২ ঢাকের বৃত্ত

পূজার ঢাক আরেকটা কেস, এবং এটা বেড বনাম অবজেক্টের পার্থক্য বোঝানোর জন্য সবচেয়ে ভালো।

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

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

ধামাইল-এর কেসটাও একই যুক্তির — সিলেট ও গ্রেটার সিলেটি অঞ্চলের এই বৃত্তাকার গান-নাচে গায়িকারা হাততালি দিতে দিতে ঘোরেন; উৎসগুলো একইসঙ্গে বহু-দিক ও চলমান।

২. তিন ধরনের অডিও, এবং কেন এই ভাগটাই ফরম্যাট ঠিক করে দেয়

কন্টেইনারের আগে মডেল। ইমার্সিভ ডেলিভারির প্রায় প্রতিটা গোলমাল শুরু হয় এই বিভ্রান্তি থেকে যে একটা ট্র্যাক আসলে নিচের তিনটের কোনটা।

চ্যানেল-ভিত্তিক (channel-based) অডিওতে প্রতিটা ট্র্যাক একটা নির্দিষ্ট লাউডস্পিকারের জন্য বরাদ্দ। স্টেরিও চ্যানেল-ভিত্তিক; ৫.১-ও তাই; ৭.১.৪ "বেড"-ও তাই। অবস্থানটা চ্যানেলের পরিচয়ের ভিতরেই সেঁটে দেওয়া: ট্র্যাক ৩ মানে সেন্টার স্পিকার, এবং যে সিস্টেমেই বাজুক সেটা সেন্টার স্পিকারই। ITU-R BS.2051 এই ব্যবস্থাটাকে আনুষ্ঠানিক রূপ দেয়, লেআউটগুলোকে উপরের + মাঝের + নিচের স্তরের সংখ্যা দিয়ে লিখে: System A হলো 0+2+0 (স্টেরিও), System B হলো 0+5+0 (৫.১), System D হলো 4+5+0, System J হলো 4+7+0, আর System H হলো 9+10+3 — অর্থাৎ ২২.২। ADM-এ চ্যানেল-ভিত্তিক বস্তু DirectSpeakers typeDefinition, typeLabel 0001।

অবজেক্ট-ভিত্তিক (object-based) অডিওতে একটা মনো (বা মাল্টিচ্যানেল প্যাক) সিগন্যালের সঙ্গে থাকে অবস্থানের মেটাডেটা, যা সময়ের সাথে বদলাতে পারে। কোন স্পিকার দিয়ে সেটা বাজবে সেটা ঠিক করে রেন্ডারার, ঘরে আসলে যে লেআউটটা আছে তার ভিত্তিতে। ট্র্যাকটা কোনো স্পিকার ধরে নিয়ে বসে থাকে না। এটা typeDefinition Objects, typeLabel 0003। কীর্তনের খোল বাদক, বা আখড়ার ঘুরন্ত মূল কণ্ঠ — এরা এই শ্রেণির।

সিন-ভিত্তিক (scene-based) অডিও, বাস্তবে যা প্রায় সবসময় উচ্চ-ক্রমের অ্যাম্বিসনিক (HOA), গোটা শব্দক্ষেত্রটাকে গোলকীয় হারমোনিক উপাংশের একটা সেট হিসেবে সংকেতায়িত করে। কোনো একটা উপাংশ একা কোনো দিক নির্দেশ করে না; দিক তৈরি হয় রৈখিক সমন্বয় থেকে। এটা typeDefinition HOA, typeLabel 0004। আখড়ার ভিড়-ও-প্রাঙ্গণের বেডটা এই শ্রেণিতে ফেলা সবচেয়ে সৎ। ADM আরও দুটো শ্রেণি সংজ্ঞায়িত করে: Matrix (0002) — যেমন মিড-সাইড বা Lt/Rt — আর Binaural (0005), হেডফোনের জন্য তৈরি জোড়।

চ্যানেল-ভিত্তিক অডিও ফাইলকে বলে দেয় স্পিকার কোথায়; অবজেক্ট-ভিত্তিক অডিও অনুমান করতে অস্বীকার করে; আর সিন-ভিত্তিক অডিও উৎসের বদলে ক্ষেত্রটাকে বর্ণনা করে।

এই ভাগটা নিছক শ্রেণিবিন্যাস নয়। একটা চ্যানেল-ভিত্তিক ডেলিভারেবল নিজেই যথেষ্ট আত্মপরিচয়বাহী — চ্যানেলের ক্রম ঠিক থাকলে খালি WAV হিসেবেও সেটা বাজে। কিন্তু একটা অবজেক্ট-ভিত্তিক বা সিন-ভিত্তিক ডেলিভারেবল মেটাডেটা ছাড়া সম্পূর্ণ অর্থহীন: অডিওটা তখন নিছক একগাদা অবিভাজিত মনো স্ট্রিম, আর ADM ছাড়া আর কিছুই বলছে না ওগুলো কী। এই অসমতাই BW64 আর ADM থাকার একমাত্র কারণ, এবং ইমার্সিভ QC কেন স্টেরিও QC-র চেয়ে কঠিন তারও একমাত্র কারণ।

৩. BW64 কেন আছে: ৪ GB সিলিংয়ের পাটিগণিত

পুরনো WAV একটা RIFF ফাইল। ১৯৯১-এর RIFF প্রতিটা চাঙ্কের আগে একটা ৩২-বিট সাইজ ফিল্ড বসায়। ৩২ বিটে সর্বোচ্চ ৪ ২৯৪ ৯৬৭ ২৯৬ বাইট (৪ GiB) ঠিকানা দেওয়া যায়, এবং সেটাই গোটা ফাইল ও ভিতরের data চাঙ্ক — দুটোরই কঠিন সিলিং।

স্টেরিওর ক্ষেত্রে এই সিলিং অবান্তর। ৪৮ kHz / ২৪-বিট স্টেরিওতে ডেটা রেট 48 000 × 3 × 2 = 288 000 বাইট/সেকেন্ড, তাই ৪ GiB ধরে ৪ ২৯৪ ৯৬৭ ২৯৬ ÷ 288 000 = ১৪ ৯১৩ সেকেন্ড, অর্থাৎ প্রায় ৪ ঘণ্টা ৮ মিনিট। কোনো গান ওখানে পৌঁছায় না।

ইমার্সিভে হিসাবটা উল্টে যায়। ধরা যাক পূজার ঢাকের একটা সেশন: ৭.১.৪ বেড (১২ চ্যানেল) প্লাস ২০টা অবজেক্ট (ছ'টা ঢাক, কাঁসর, শঙ্খ, ঢাকির দলের স্পট মাইক, ধুনুচির চারপাশের অ্যাম্বিয়েন্স স্পট) = ৩২ ট্র্যাক, ৪৮ kHz / ২৪-বিটে:

• রেট = 48 000 × 3 × 32 = 4 608 000 বাইট/সেকেন্ড
• সিলিং = 4 294 967 296 ÷ 4 608 000 = ৯৩২ সেকেন্ড = ১৫ মিনিট ৩২ সেকেন্ড

একটা সন্ধিপূজার অখণ্ড রেকর্ডিং অনায়াসে এর দ্বিগুণ। ৯৬ kHz-এ গেলে একই ৩২ ট্র্যাকের সিলিং নেমে আসে ৪৬৬ সেকেন্ড = ৭ মিনিট ৪৬ সেকেন্ডে — একটা লম্বা কীর্তনের একটা পালাও ধরবে না। আর ১২৮ ট্র্যাকের একটা অবজেক্ট-ভিত্তিক মাস্টার ৯৬ kHz / ২৪-বিটে রেট 36 864 000 বাইট/সেকেন্ড, সিলিং ১১৬.৫ সেকেন্ড — দু'মিনিটেরও কম।

RIFF রাইটার এই সীমা ছুঁলে হয় ছেঁটে দেওয়া ফাইল লেখে, নয়তো এমন ফাইল লেখে যার ঘোষিত সাইজ নিঃশব্দে র‍্যাপ করে গেছে — দ্বিতীয়টা বেশি বিপজ্জনক, কারণ ফাইলটা দেখতে ঠিকঠাক।

EBU প্রথমে এর সমাধান দেয় RF64 (EBU Tech 3306) দিয়ে। ITU সেই কাজটাকেই এগিয়ে নিয়ে দাঁড় করায় সুপারিশ ITU-R BS.2088 — Long-form file format for the international exchange of audio programme materials with metadata — অর্থাৎ BW64। BS.2088 কৌশলটা স্পষ্ট করে বলে দেয়: "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", আর পুরনো ৩২-বিট ফিল্ডগুলো পরিণত হয় escape flag-এ: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

BW64 RIFF-এর সাইজ ফিল্ডগুলোকে চওড়া করে না; সেগুলোতে সংকেত হিসেবে 0xFFFFFFFF বসিয়ে দেয়, আর আসল ৬৪-বিট সাইজগুলো রাখে একটা ds64 চাঙ্কে, যেটা ফাইলের সবার আগে থাকতে হয়।

বংশপরিচয়টা মনে রাখলে সুবিধা হয়। RIFF/WAVE দিল চাঙ্ক-ভিত্তিক কন্টেইনার। Broadcast Wave (BWF, EBU Tech 3285) যোগ করল bext চাঙ্ক — অরিজিনেটর, টাইমকোড রেফারেন্স, কোডিং হিস্ট্রি — এবং WAV হয়ে উঠল সম্প্রচার-বিনিময়ের ফরম্যাট। BW64 সেই সবটা রেখে যোগ করল ৬৪-বিট ঠিকানা আর ADM বহনের চাঙ্কগুলো। ৪ GiB-র নিচে থাকা একটা BW64 ফাইল বাইট-হিসেবে WAV রিডারের সঙ্গে সম্পূর্ণ সঙ্গতিপূর্ণ, কেবল প্রথম চার বাইটের স্বাক্ষরটা আলাদা — বহু টুল সেটা মেনে নেয়, কিছু টুল একগুঁয়েভাবে নেয় না।

৪. চাঙ্ক লেআউট, বাইট ধরে ধরে

BS.2088 অনুযায়ী একটা BW64 ফাইলে অন্তত <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (বিকল্প হিসেবে <bxml-ck> বা <sxml-ck>) এবং <wave-data> থাকার কথা।

৪.১ ds64 — ৬৪-বিট সাইজের টেবিল

BW64 স্বাক্ষরের ঠিক পরেই এটা থাকতে হবে, কারণ ফাইলের বাকিটা হাঁটার আগেই রিডারকে আসল মাপগুলো জানতে হয়। ফিল্ডগুলো ৬৪-বিট রাশির ৩২-বিট অর্ধাংশ হিসেবে লেখা:

ckID আর ckSize বাদ দিলে ন্যূনতম পেলোড দাঁড়ায় 8 + 8 + 8 + 4 = ২৮ বাইট, এবং table[]-এর প্রতিটা এন্ট্রি তার উপরে যোগ হয়।

table[] দেখতে যত তুচ্ছ, বাস্তবে তত নয়। স্যাম্পল-নিখুঁত অটোমেশনসহ হাজার হাজার অবজেক্ট বর্ণনা করা একটা axml চাঙ্ক নিজেই ৪ GiB-র কাছে পৌঁছতে বা ছাড়িয়ে যেতে পারে; data ছাড়া অন্য যেকোনো চাঙ্ক ৬৪-বিট আকার ঘোষণা করে এই টেবিলের মাধ্যমেই।

৪.২ fmt — এসেন্সের বর্ণনা

সাধারণ WAVE ফরম্যাট চাঙ্ক: স্যাম্পল ফরম্যাট, স্যাম্পল রেট, চ্যানেল সংখ্যা, বিট ডেপথ, ব্লক অ্যালাইন। data-র ভিতরে আসলে কতগুলো ইন্টারলিভড চ্যানেল আছে, তার একমাত্র প্রামাণিক ঘোষণা এটাই। বাকি সবটাই ওই চ্যানেলগুলো সম্পর্কে মেটাডেটা, আর মেটাডেটা মিথ্যে বলতে পারে।

৪.৩ chna — চ্যানেল অ্যালোকেশন টেবিল, এবং সেই ৪০ বাইট

chna হলো বাস্তব ট্র্যাক আর ADM-এর মধ্যেকার সেতু। চাঙ্কটা শুরু হয়:

• ckID — ৪ বাইট, 'chna'
• ckSize — ৪ বাইট
• numTracks — ২ বাইট, ফাইলে কতগুলো ট্র্যাক
• numUIDs — ২ বাইট, পরে কতগুলো audioTrackUID এন্ট্রি আছে

তারপর নির্দিষ্ট-প্রস্থের audioID এন্ট্রির একটা সমতল অ্যারে। প্রতিটা এন্ট্রি ঠিক ৪০ বাইট:

যোগফলটা নিজে মিলিয়ে নিন: 2 + 12 = 14; 14 + 14 = 28; 28 + 11 = 39; 39 + 1 = 40। স্ট্রিংগুলোও ঠিক ওই মাপেই বসে — ATU_00000001 বারো অক্ষর, AT_00031001_01 চোদ্দ অক্ষর, AP_00031001 এগারো অক্ষর। এই প্রস্থগুলো পরামর্শ নয়, বাধ্যতামূলক নির্দিষ্ট-প্রস্থ ASCII; যে রাইটার তেরো অক্ষরের UID লেখে সে একটা "একটু অন্যরকম" টেবিল লেখেনি, সে একটা নষ্ট টেবিল লিখেছে।

উপরের ৩২-ট্র্যাকের ঢাক সেশনে, প্রতি ট্র্যাকে একটা করে UID ধরলে:

• এন্ট্রি অংশ = 40 × 32 = 1 280 বাইট
• ckSize = 2 (numTracks) + 2 (numUIDs) + 1 280 = 1 284
• ডিস্কে গোটা চাঙ্ক = 4 (ckID) + 4 (ckSize) + 1 284 = 1 292 বাইট

অর্থাৎ ৩২টা ইমার্সিভ ট্র্যাকের গোটা অ্যালোকেশন টেবিল একটা মাঝারি ছবির থাম্বনেইলের চেয়েও ছোট। এই কারণেই chna পার্স করা সস্তা, এবং এই কারণেই সবচেয়ে সস্তা QC পরীক্ষাগুলো এখান থেকেই শুরু করা উচিত।

আরেকটা নিয়ম মনে রাখতে হয়: ID-র মান 0x0FFF বা তার নিচে হলে সেটা ADM-এর common definitions-কে নির্দেশ করে — অর্থাৎ আগে থেকে সংজ্ঞায়িত মানক চ্যানেল ও প্যাক ফরম্যাট — আর 0x1000 বা তার উপরে হলে সেটা কাস্টম সংজ্ঞা, যা axml-এ উপস্থিত থাকতেই হবে। AP_00010003 কমন সংজ্ঞা অনুযায়ী ৫.১, তার জন্য কোনো XML লাগে না; AP_00031001 একটা কাস্টম অবজেক্ট প্যাক, XML না থাকলে সেই রেফারেন্স ঝুলে থাকে।

ট্র্যাক UID হলো একটা বাস্তব ট্র্যাকের পরিচয়ের ক্রমিক নম্বর, আর এটা আছেই এই কারণে যে একটা ট্র্যাক প্রোগ্রামের মাঝপথে বৈধভাবেই অন্য জিনিস বহন করতে শুরু করতে পারে।

এই কারণেই numUIDs numTracks-এর চেয়ে বড় হতে পারে। EBU-র নির্দেশিকা কথাটা স্পষ্ট করে বলে: যেখানে "the audio elements of a track may be [defined] differently in the course of a file … there will be a different UID for each definition" — অর্থাৎ একই trackIndex একাধিক এন্ট্রিতে আসতেই পারে। বাংলা প্রেক্ষিতে এটা কাল্পনিক নয়: একটা পালা-কীর্তনের রেকর্ডিংয়ে যে ট্র্যাকটা প্রথম বিশ মিনিট একজন গায়কের চলমান অবজেক্ট, সেটাই পরের অংশে অন্য একজনের হয়ে যেতে পারে। যে QC টুল ধরে নেয় "এক ট্র্যাক মানে এক UID", সে সঠিক ফাইলকে নষ্ট বলে চিহ্নিত করবে।

৪.৪ axml — স্বয়ং ADM

UTF-8 এনকোড করা একটা XML ডকুমেন্ট, যার ভিতরে <audioFormatExtended> গাছ। এটাই ADM। এটা টেক্সট, এটা পড়া যায়, এবং কার্যত সব আকর্ষণীয় ব্যর্থতা এখানেই বাস করে। বাংলা মেটাডেটার দিক থেকে একটা বাড়তি সুবিধা আছে: audioProgramme-এর audioProgrammeName বা audioContent-এর নাম UTF-8 হওয়ায় বাংলা লিপিতে "নাম-কীর্তন — প্রথম পালা" লেখা সম্পূর্ণ বৈধ। তবে ব্যবহারিক পরামর্শ হলো ID-নির্ভর ফিল্ডে (audioTrackFormatID ইত্যাদি) কখনোই অ-ASCII কিছু ঢোকাবেন না — ওগুলো নির্দিষ্ট-প্রস্থ, আর যুক্তাক্ষরসহ বাংলা টেক্সটে অক্ষর-সংখ্যা আর বাইট-সংখ্যা এক নয়।

৪.৫ data — ইন্টারলিভড PCM

সাধারণ ইন্টারলিভড স্যাম্পল, ঠিক যেমন WAV-এ। data-র ভিতরের কোনো কিছুই অবজেক্ট সম্পর্কে কিছু জানে না।

৪.৬ ক্রম

ds64 সবসময় প্রথম। fmt অবশ্যই data-র আগে। কিন্তু axml বৈধভাবেই data-র পরে বসতে পারে, এবং প্রায়ই বসে — কারণ, BS.2088 যেমন বলে, রেকর্ডিংয়ের সময় "the XML metadata will likely be of an unknown length." লেজে axml থাকা ফাইল ত্রুটিপূর্ণ নয়; কিন্তু যে রিডার ফাইলের প্রথম কয়েক মেগাবাইট স্ক্যান করেই থেমে যায় সে বলবে ফাইলে কোনো ADM নেই। "আমার ফাইলে মেটাডেটা নেই" জাতীয় অভিযোগের একটা বড় অংশ আসলে এইটুকুই।

৫. ADM অবজেক্ট মডেল

ITU-R BS.2076 মডেলটাকে দু'ভাগে ভাগ করে। ফরম্যাট অংশ — "describes the technical nature of the audio so it can be decoded or rendered correctly" — অডিও তৈরি হওয়ার আগেই লিখে ফেলা যায়। কনটেন্ট অংশ বর্ণনা করে "the language of dialogue, the loudness, etc.", যা সিগন্যাল না থাকলে সম্পূর্ণ করা যায় না। কোনো ভুল কোন অংশে, সেটা জানলেই বোঝা যায় প্রোডাকশনের কোন ধাপে ভুলটা ঢুকেছে।

উপর থেকে নিচে ক্রমটা:

• audioProgramme — একটা সম্পূর্ণ পরিবেশনা-উপস্থাপনা। এক বা একাধিক audioContent-কে নির্দেশ করে।
• audioContent — সম্পাদনাগত অর্থবাহী একটা উপাদান: কণ্ঠের স্টেম, যন্ত্রের স্টেম, বা একটা ভাষা-সংস্করণ। এক বা একাধিক audioObject-কে নির্দেশ করে।
• audioObject — সম্পাদনাগত উদ্দেশ্য আর কারিগরি ফরম্যাটের সংযোগস্থল। এর নিজের শুরুর সময় আর দৈর্ঘ্য আছে, এবং এটা শূন্য বা তার বেশি audioPackFormat, শূন্য বা তার বেশি নেস্টেড audioObject, আর শূন্য বা তার বেশি audioTrackUID-কে নির্দেশ করে। এখানেই কনটেন্ট আর এসেন্স মিলিত হয়।
• audioPackFormat — একসঙ্গে থাকা চ্যানেলগুলোর দল: একটা ৭.১.৪ বেড, একটা স্টেরিও জোড়, বা নির্দিষ্ট ক্রমের একটা HOA সেট। audioChannelFormat-দের নির্দেশ করে, এবং নিজের ভিতরে অন্য প্যাক ধারণ করতে পারে।
• audioChannelFormat — সময়ের সাপেক্ষে একটা চ্যানেলের আচরণ। এর ভিতরে এক বা একাধিক audioBlockFormat।
• audioBlockFormat — পরমাণু। Objects-এর ক্ষেত্রে একটা অবস্থান (azimuth/elevation/distance, বা কার্তেসীয় X/Y/Z), গেইন, আকার, ডিফিউজনেস, সঙ্গে rtime আর duration। স্থির অবজেক্ট মানে একটাই ব্লক; চলমান অবজেক্ট মানে ব্লকের ধারাবাহিকতা।
• audioTrackUID — পাতা, এবং একমাত্র উপাদান যা সরাসরি একটা বাস্তব ট্র্যাকের সঙ্গে মেলে। ঐচ্ছিক sampleRate ও bitDepth অ্যাট্রিবিউট বহন করে, আর একটা audioTrackFormat ও একটা audioPackFormat নির্দেশ করে।

audioStreamFormat আর audioTrackFormat চ্যানেল ফরম্যাট ও ট্র্যাক UID-র মাঝখানে বসে স্ট্রিম এনকোডিং বর্ণনা করে। BS.2076-3 লক্ষ করে যে PCM-এর ক্ষেত্রে এরা কার্যত অপ্রয়োজনীয় — "the audioStreamFormat and the audioTrackFormat should be omitted" — কিন্তু রিডারদের "should be aware that existing ADM files (based on Recommendation ITU-R BS.2076-2 and earlier) for PCM audio may contain" সেগুলো। দুটো গড়নই বৈধ; যে ভ্যালিডেটর একটার উপর জোর দেয়, সে অন্যটার ব্যাপারে ভুল করছে।

ADM একটা নেস্টেড ডকুমেন্ট নয়, রেফারেন্সের গ্রাফ — আর প্রতিটা গুরুতর ডেলিভারি ব্যর্থতা সেই গ্রাফের একটা ভাঙা প্রান্ত।

রেফারেন্স ঝুলে থাকলে ঠিক কী হয়? একরকম কিছু হয় না — এবং সেটাই সমস্যা। XML-এ অনুপস্থিত একটা প্যাককে audioPackFormatIDRef নির্দেশ করলে রেন্ডারার হয় পার্সিং থামিয়ে ফাইল প্রত্যাখ্যান করতে পারে; বা ওই অবজেক্টটা বাদ দিয়ে বাকিটা রেন্ডার করতে পারে, ফলে একটা গোটা স্টেম নিঃশব্দে অনুপস্থিত মিক্স তৈরি হয়; বা কমন সংজ্ঞায় খুঁজতে গিয়ে 0x1000+ পরিসরের একটা কাস্টম ID-র কোনো মিল না পেয়ে নীরবতা বসিয়ে দিতে পারে। তিনটে ক্ষেত্রেই "ফাইল খুলেছে"। তিনটের মধ্যে একটাই কান দিয়ে ধরা পড়ে, আর সেটাও কেবল যদি আপনি জানেন ওখানে কী থাকার কথা ছিল। কান কখনো এমন অনুপস্থিতি ধরতে পারে না যার কথা তাকে আগে বলা হয়নি — এই কারণেই ADM QC স্বয়ংক্রিয় হতে বাধ্য।

৫.১ একটা আখড়ার রেকর্ডিং ADM-এ আসলে কীভাবে বসে

তত্ত্বটা কংক্রিট করা যাক। ধরুন ছেঁউড়িয়ায় একটা সাধুসঙ্গের রেকর্ডিং, ৩২ ট্র্যাক, ৪৮ kHz / ২৪-বিট। কাঠামোটা এরকম দাঁড়ায়:

• একটাই audioProgramme — গোটা আসরের একটা পালা। এর নাম বাংলায় লেখা যায়; audioProgrammeLanguage-এ ISO 639 কোড ben বসে।
• দুটো audioContent — একটা "পরিবেশনা" (কণ্ঠ ও যন্ত্র), আরেকটা "আসর" (ভিড়, প্রাঙ্গণ, প্রতিফলন)। এই ভাগটা সম্পাদনাগত, কারিগরি নয়; পরে যদি কেউ ভিড়ের স্তর আলাদা করে নামাতে চান, এই ভাগটাই সেটা সম্ভব করে।
• "আসর" কনটেন্টের নিচে একটা audioObject, যা একটা HOA audioPackFormat নির্দেশ করে — ফার্স্ট-অর্ডার অ্যাম্বিসনিক হলে চারটে চ্যানেল (W, X, Y, Z), থার্ড-অর্ডার হলে ষোলোটা। এই প্যাকের প্রতিটা audioChannelFormat-এ একটাই audioBlockFormat, কারণ শব্দক্ষেত্রের "অবস্থান" বলে কিছু নেই — গোটা ক্ষেত্রটাই এখানে বস্তু।
• "পরিবেশনা" কনটেন্টের নিচে একাধিক audioObject: মূল কণ্ঠ, একতারা, ডুগি, দোতারা, খমক, বাঁশি, আর করতালের দলগুলো। প্রত্যেকটা Objects টাইপের একটা করে audioPackFormat নির্দেশ করে, আর প্রত্যেকটার নিচে একটা করে audioChannelFormat, যার ভিতরে অবস্থানসহ audioBlockFormat।
• মূল কণ্ঠের অবজেক্টটাই একমাত্র যেটার অনেকগুলো ব্লক দরকার, কারণ গায়ক বৃত্তের ভিতরে ঘোরেন। বাকিগুলো স্থির — প্রত্যেকটার একটা করে ব্লক, একটা করে অ্যাজিমাথ।
• সবার নিচে ৩২টা audioTrackUID, ঠিক ৩২টা বাস্তব ট্র্যাকের সঙ্গে এক-এক মিল, আর chna-তে ৩২টা ৪০-বাইট এন্ট্রি।

লক্ষ করার মতো ব্যাপার হলো এই গোটা বর্ণনায় কোথাও কোনো স্পিকারের নাম নেই — শুধু বেড-প্যাকের ক্ষেত্রে, আর সেখানেও চ্যানেল-ভিত্তিক বেড বেছে নিলে তবেই। বাকিটা দিক আর সময়ের বিবৃতি। এই কারণেই একই ফাইল থেকে একটা ৯+১০+৩ ঘরে আর একজোড়া হেডফোনে দুটো সম্পূর্ণ আলাদা কিন্তু সমানভাবে বৈধ রেন্ডার পাওয়া যায়।

৫.২ axml-এ বাংলা লিপি

axml UTF-8, তাই নাম-জাতীয় ফিল্ডে বাংলা লিপি সম্পূর্ণ বৈধ, এবং ব্যবহার করা উচিতও — audioProgrammeName-এ "সাধুসঙ্গ — প্রথম পালা" লেখা "Sadhusanga Part 1"-এর চেয়ে বেশি তথ্যবহ। তবে কয়েকটা সতর্কতা বাস্তবে বারবার কামড়ায়:

• ID ফিল্ডে কখনো নয়। audioTrackFormatID, audioPackFormatID, audioTrackUID — এগুলো নির্দিষ্ট-প্রস্থ ASCII এবং chna-তে বাইট-হিসেবে গোনা হয়। বাংলার একটা অক্ষর UTF-8-এ তিন বাইট, যুক্তাক্ষর ও মাত্রা মিলিয়ে আরও বেশি — একটা বাংলা অক্ষর ঢোকালেই ৪০-বাইট এন্ট্রি ভেঙে পড়ে।
• নরমালাইজেশন ফর্ম স্থির রাখুন। বাংলায় একই দৃশ্যমান অক্ষর একাধিক কোডপয়েন্ট ক্রমে লেখা সম্ভব; ফাইলজুড়ে একটাই ফর্ম (NFC) ব্যবহার করুন, নাহলে দুটো দেখতে-এক স্ট্রিং তুলনায় অসমান হবে।
• ফাইলের নামে বাংলা এড়িয়ে চলুন। axml-এর ভিতরে বাংলা নিরাপদ; কিন্তু ডেলিভারি প্যাকেজের ফাইল-নামে বাংলা লিপি পথের মধ্যে অনেক পুরনো টুলচেইনে ভেঙে যায়। নাম ASCII রাখুন, অর্থ XML-এ রাখুন।

৬. BS.2127: রেন্ডারিং, এবং কেন একটা ফাইলের একাধিক সত্য থাকে

অবজেক্ট-ভিত্তিক ফাইল নিজে কোনো শব্দ নয়; এটা শব্দ তৈরির নির্দেশনা। শব্দ তৈরি হয় রেন্ডারিংয়ে, এবং রেন্ডারার লক্ষ্য হিসেবে যে BS.2051 লেআউট পায়, তার উপর ফলাফল নির্ভর করে।

ITU-R BS.2127 এই কাজের জন্য রেফারেন্স ADM রেন্ডারার সংজ্ঞায়িত করে — অর্থাৎ ADM মেটাডেটা থেকে একটা নির্দিষ্ট স্পিকার লেআউটে যাওয়ার একটা সম্পূর্ণ, প্রকাশিত, পুনরুৎপাদনযোগ্য পথ। এর মুক্ত-উৎস সহোদর, EBU ADM Renderer (EAR, EBU Tech 3388), বাস্তবে সেই একই ফল পাওয়ার সহজতম উপায়।

এর তাৎপর্য বোঝার সবচেয়ে ভালো উপায় কীর্তনের মিছিলের অবজেক্টটা। ধরুন সেটা রেকর্ডিংয়ের অষ্টম মিনিটে অ্যাজিমাথ ১৩৫° (পিছন-বাঁ), এলিভেশন ০°-এ আছে।

• System J (4+7+0)-এ রেন্ডার করলে পিছন-বাঁ দিকে বাস্তব স্পিকার আছে; উৎসটা মোটামুটি একটা স্পিকারের কাছেই বসে।
• System B (0+5+0, অর্থাৎ ৫.১)-এ রেন্ডার করলে অবস্থানটা পিছনের দুটো স্পিকারের মধ্যে ভাগ হয়ে যায়, এবং কৌণিক নির্ভুলতা কমে।
• System A (0+2+0, স্টেরিও)-এ রেন্ডার করলে ১৩৫° বলে কিছু নেই; রেন্ডারারকে সেটা সামনের ৬০ ডিগ্রির ভিতরে ভাঁজ করতে হয়। শব্দটা থাকে, ঘটনাটা থাকে না।

এই তিনটে রেন্ডার একই ফাইল থেকে এসেছে, তিনটেই বৈধ, এবং তিনটে আলাদা শব্দ। বাইনরাল রেন্ডার আরেকটা — HRTF দিয়ে হেডফোনের জন্য। একটা ইমার্সিভ ডেলিভারেবলের "সঠিক শোনা" বলে কোনো একক জিনিস নেই; আছে একটা নির্দিষ্ট লেআউটে একটা নির্দিষ্ট রেন্ডারারের নির্দিষ্ট ফলাফল। ডেলিভারি নোটে তাই লেআউট আর রেন্ডারারের নাম না লিখলে আপনি আসলে কিছুই লেখেননি।

৭. যেসব QC ভুল বারবার হয়

৭.১ fmt আর chna-র চ্যানেল সংখ্যা মেলে না

fmt.nChannels বলছে ৩২, chna.numTracks বলছে ৩০। ফাইলটা প্রথম দুটো চাঙ্ক থেকেই স্ববিরোধী। সাধারণত কারণ: মেটাডেটা লেখার পর বাউন্স করতে গিয়ে ট্র্যাক সংখ্যা বদলে গেছে, বা কোনো টুল ট্র্যাক ফেলে দিয়ে chna আবার লেখেনি।

ধরার উপায়: দুটো চাঙ্ক পার্স করে পূর্ণসংখ্যা দুটো মেলান। গোটা পাইপলাইনের সবচেয়ে সস্তা পরীক্ষা, আর অবাক করার মতো বড় অংশের ব্যর্থতা এটাই ধরে ফেলে। সঙ্গে দেখুন chna-র প্রতিটা trackIndex 1 … fmt.nChannels পরিসরের ভিতরে আছে কি না।

৭.২ অনাথ ট্র্যাক UID

chna-তে আছে অথচ কোনো audioObject নির্দেশ করে না — এমন UID; কিংবা XML-এ audioTrackUIDRef আছে অথচ chna-তে মিল নেই। প্রথমটার মানে ফাইলে অডিও আছে যা কেউ রেন্ডার করবে না; দ্বিতীয়টার মানে মেটাডেটা এমন ট্র্যাক আশা করছে যা নেই।

ধরার উপায়: chna থেকে UID-র সেট আর axml থেকে UID-র সেট বানিয়ে symmetric difference নিন — ফল খালি হওয়া উচিত। EBU Tech 3392 উদ্দেশ্যটা স্পষ্ট করে বলে: "If the audioObject refers to an audioPackFormat it should also refer to the corresponding audioTrackUIDs."

৭.৩ ব্লক ফরম্যাটের টাইমিং অনুপস্থিত বা উল্টো

এই ভুলটাই কীর্তনের মিছিলের মতো চলমান অবজেক্টকে সবচেয়ে বেশি মারে। BS.2076 নিঃসংশয়: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 তার উপর ধারাবাহিকতার শর্ত বসায় — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — সঙ্গে: অবজেক্টের প্রথম ব্লক শুরু হবে 00:00:00.00000-এ, কোনো ব্লক এক স্যাম্পলের চেয়ে ছোট হবে না, আর সব duration-এর যোগফল মূল audioObject-এর দৈর্ঘ্যের সমান হবে।

ধরার উপায়: প্রতিটা audioChannelFormat-এর ব্লকগুলোতে ডকুমেন্ট-ক্রম ধরে হাঁটুন আর যাচাই করুন rtime[n] + duration[n] == rtime[n+1]। ব্যর্থতা তিন ধরনের হয়: ফাঁক (রেন্ডারারের আচরণ অসংজ্ঞায়িত — কেউ শেষ অবস্থান ধরে রাখে, কেউ নীরব করে দেয়), উপরিপাত (দুটো ব্লক একে অন্যের সঙ্গে লড়ছে), আর কালানুক্রম উল্টে যাওয়া (অটোমেশন মাঝপথে পিছনে লাফ দিচ্ছে)। মিছিলের রেকর্ডিংয়ে তৃতীয়টা কানে ধরা পড়ে একটা অস্বস্তিকর ঘটনা হিসেবে: দল হেঁটে যেতে যেতে হঠাৎ আবার আগের জায়গায় ফিরে আসে।

৭.৪ স্যাম্পল রেট বা বিট ডেপথ অসঙ্গত

audioTrackUID-এ sampleRate ও bitDepth অ্যাট্রিবিউট থাকতে পারে। সেগুলো fmt -এর সঙ্গে না মিললে একই এসেন্স নিয়ে দুটো পরস্পরবিরোধী দাবি দাঁড়ায়। EBU Tech 3392-র অবস্থান হলো এগুলো "Should be ignored if available from the audio essence" — কিন্তু সব রেন্ডারার সেই নির্দেশ মানে না, আর যে ফাইল একজায়গায় 48 000 আর অন্য জায়গায় 96 000 বলে, তাকে বিভিন্ন টুল বিভিন্নভাবে ব্যাখ্যা করবে। আলাদাভাবে নিশ্চিত করুন রেটটা ডেলিভারি স্পেসিফিকেশনের চাওয়া রেটই — ADM লেখার পরে স্যাম্পল-রেট কনভার্শন করলে স্যাম্পলে প্রকাশ করা প্রতিটা rtime আর duration অকেজো হয়ে যায়।

৭.৫ স্টেরিও বা বাইনরাল কনফর্ম অনুপস্থিত বা অসমলয়

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

ধরার উপায়: দৈর্ঘ্য স্যাম্পল ধরে মেলান, bext-এর স্টার্ট টাইমকোড মেলান, আর মাস্টারের একটা নাল-রেন্ডারের সঙ্গে কনফর্মটা ক্রস-কোরিলেট করুন। যে কনফর্ম বর্তমান মাস্টার থেকে সরাসরি উৎপন্ন নয়, সেটাকে সন্দেহজনক ধরে আবার রেন্ডার করুন — আবার যাচাই করবেন না।

৭.৬ মেটাডেটা এমন বেড বর্ণনা করছে যা ফাইলে নেই

XML ঘোষণা করছে একটা ৭.১.৪ DirectSpeakers প্যাক — বারোটা চ্যানেল — কিন্তু আসলে ছাপা হয়েছে শুধু ৫.১ উপসেট, বা উচ্চতার চ্যানেলগুলো বাউন্সের সময় মিউট ছিল এবং ডিজিটাল নীরবতা হিসেবে ছাপা হয়েছে। রেফারেন্স গ্রাফ অক্ষত; অডিও নয়।

ধরার উপায়: কাঠামোগত পরীক্ষা এটা ধরতে পারে না। এসেন্স বিশ্লেষণ লাগে: DirectSpeakers প্যাকের দাবি করা প্রতিটা চ্যানেলে আদৌ সিগন্যাল আছে কি না মাপতে হয়। ঘোষিত বেড চ্যানেলে ডিজিটাল নীরবতা স্বয়ংক্রিয়ভাবে ভুল নয় — একটা বৈধ মিক্সে পিছনের উপরের চ্যানেল খালি থাকতেই পারে — কিন্তু সেটা সবসময়ই একজন মানুষের সিদ্ধান্ত দাবি করে।

কন্টেইনার নিখুঁত হতে পারে, XML নিখুঁতভাবে সুগঠিত হতে পারে, আর ডেলিভারেবল তবুও ভুল হতে পারে; খালি বেড চ্যানেলের একমাত্র পরীক্ষা হলো স্যাম্পলগুলো নিজে দেখা।

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

৮. ইমার্সিভ লাউডনেস: কী প্রকাশিত আর কী নয়

এখানে প্রকাশিত জিনিস আর প্রচলিত জিনিসকে আলাদা রাখা জরুরি।

BS.1770 কী নির্দিষ্ট করে। ITU-R BS.1770 K-weighting সংজ্ঞায়িত করে: একটা হাই-শেলফ "হেড" ফিল্টার (যা একটা কঠিন গোলকের প্রভাব মডেল করে), তার পরে একটা RLB হাই-পাস। ১ kHz-এ এই বক্ররেখার গেইন +0.698 dB, রৈখিক হিসাবে 1.0836। পরিমাপ হয় ৭৫% ওভারল্যাপসহ ৪০০ ms ব্লকে, একটা পরম গেট যা −70 LKFS-এর নিচের ব্লক বাদ দেয়, আর একটা আপেক্ষিক গেট যা পরম গেট উতরে যাওয়া ব্লকগুলোর গড় থেকে হিসাব করে তার উপর −10 LU অফসেট বসায়। আপেক্ষিক গেটটা গেট-বিহীন গড় থেকে আসে না — এই পার্থক্যটা বাস্তবায়নে যথেষ্ট ঘন ঘন ভুল হয় বলেই আলাদা করে বলা দরকার।

সংস্করণ। BS.1770-এর ছ'টা সংস্করণ: -0 (২০০৬), -1 (২০০৭), -2 (২০১১), -3 (২০১২), -4 (২০১৫), -5 (নভেম্বর ২০২৩)। বলবৎ সংস্করণ BS.1770-5; BS.1770-4 (অক্টোবর ২০১৫) অতিক্রান্ত, যদিও বাজারে চালু বেশির ভাগ মিটার এখনো ওটারই নাম লেখে। নথিতে সবসময় -5 লিখুন।

চ্যানেল ওজন ও পরিসর। মূল অ্যালগরিদমে চ্যানেল ওজন L, R ও C-র জন্য 1.0 (0 dB), আর Ls ও Rs-এর জন্য 1.41 (≈ +1.5 dB); LFE বাদ। মূল অ্যালগরিদমের পরিধি "from one to five channels"। BS.1770-5 এর বাইরেটা তার অ্যানেক্সে সম্প্রসারিত করে — BS.2051-এর উন্নত সাউন্ড সিস্টেম, অর্থাৎ যথেচ্ছভাবে স্থাপিত স্পিকার ও উচ্চতার চ্যানেল, এবং অবজেক্ট-ভিত্তিক অডিও, যাকে মাপার আগে রেন্ডার করতেই হবে।

ইমার্সিভ লাউডনেস ফাইলের ধর্ম নয়, একটা রেন্ডারের ধর্ম; লক্ষ্য লেআউট বদলালে সংখ্যাটাও বদলায়।

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

সংশ্লিষ্ট EBU নথি। EBU Tech 3341 মিটারের আচরণ সংজ্ঞায়িত করে (momentary ৪০০ ms, short-term ৩ s)। EBU Tech 3342 Loudness Range সংজ্ঞায়িত করে, যা −20 LU আপেক্ষিক গেট ব্যবহার করে — −10 LU নয়; LRA-তে −10 ব্যবহার করা একটা প্রচলিত বাস্তবায়ন-বাগ। আখড়ার মতো রেকর্ডিংয়ে এই পার্থক্যটা তুচ্ছ নয়: একক কণ্ঠের অংশ আর ভরা দলের অংশের ব্যবধান বড় হওয়ায় ভুল গেট ব্যবহার করলে LRA বাস্তবের চেয়ে অনেক ছোট দেখায়। EBU R 128 সম্প্রচারের প্রোগ্রাম টার্গেট −23 LUFS নির্দিষ্ট করে; R 128 সম্প্রচারের নরমালাইজেশন-রীতি, সংগীত স্ট্রিমিংয়ের স্পেসিফিকেশন নয়।

সংগীতের জন্য যা প্রকাশিত। চ্যানেল-ভিত্তিক স্টেরিও সংগীতের ক্ষেত্রে স্পটিফাই ইন্টিগ্রেটেড টার্গেট −14 LUFS এবং ট্রু-পিক সিলিং −1 dBTP প্রকাশ করে, আর −14 LUFS-এর চেয়ে জোরে মাস্টারের জন্য সেটা −2 dBTP-তে নামায়। AES TD1008 সংগীতের জন্য −16 LUFS সুপারিশ করে; ওই নথির −18 LUFS সংখ্যাটা কথা-প্রধান কনটেন্টের জন্য, আর −18-কে সংগীতের টার্গেট বলা একটা ঘন ঘন ঘটা ও গুরুতর ভুল।

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

সম্প্রচার আর চলচ্চিত্রের নথিপত্র সংগীতের চেয়ে ভালো, কারণ সম্প্রচারকেরা প্রকাশ করেন। আজ যদি আপনার একটা রক্ষণযোগ্য ইমার্সিভ লাউডনেস সংখ্যা দরকার হয়, তাহলে একটা BS.2127-সঙ্গতিপূর্ণ রেন্ডারকে একটা নামধারী BS.2051 লেআউটে নিয়ে একটা BS.1770-5 মিটার দিয়ে মাপুন — আর তিনটে নামই ডেলিভারি নোটে লিখুন।

মালিকানাধীন সিস্টেম প্রসঙ্গে। Dolby Atmos হলো Dolby Laboratories-এর মালিকানাধীন, লাইসেন্সকৃত প্রযুক্তি, আর Sony 360 Reality Audio একটা মালিকানাধীন সিস্টেম যা MPEG-H-এর উপর নির্মিত। এদের ডেলিভারি শর্ত ঠিক করেন এদের মালিকেরা, এবং সেগুলো ITU বা EBU-র সময়সূচি মেনে বদলায় না। এই নথির কোনো অংশ ওই কোম্পানিগুলোর কোনো শর্তের বিবৃতি নয়, এবং কোনো সংশ্লিষ্টতা, সার্টিফিকেশন বা অনুমোদন দাবি করা হচ্ছে না। যেখানে লাইসেন্সদাতা নিজে শর্ত প্রকাশ করেছেন, সেখানে তাঁর নিজের বর্তমান নথি পড়ুন এবং সেটাই উদ্ধৃত করুন।

৯. ইমার্সিভ মনিটরিং ছাড়া কাজ করার সৎ অবস্থান

এই অংশটা না লিখলে বাকি নথিটা অসৎ হয়ে যায়।

ঢাকা বা কলকাতার স্টুডিওতে ৭.১.৪ মনিটরিং প্রায় নেই বললেই চলে। যেসব ঘর আছে সেগুলো মূলত স্টেরিও, কিছু ক্ষেত্রে ৫.১ — এবং সেই ৫.১-ও প্রায়শই টেলিভিশন বা বিজ্ঞাপনের কাজের জন্য, ঠিকভাবে ক্যালিব্রেট করা অবস্থায় নয়। বাস্তব পরিস্থিতিটা এই: ইমার্সিভ ডেলিভারেবল তৈরি হচ্ছে এমন ঘরে যেখানে সেটা শোনার উপায় নেই।

এই অবস্থায় সৎ অবস্থানটা তিন লাইনের:

এক — যা যাচাই করা যায় না, তা দাবি করবেন না। হেডফোনে বাইনরাল রেন্ডার শোনা একটা কাজের সূচক, কিন্তু সেটা ৭.১.৪ ঘরে শোনার সমতুল্য নয়। ডেলিভারি নোটে "৭.১.৪-এ পর্যবেক্ষণ করা হয়েছে" লেখা যাবে না যদি সেটা করা না হয়ে থাকে।

দুই — যা যাচাই করা যায়, তার প্রায় সবটাই যাচাই করা যায়। এবং সেটাই ভালো খবর। এই নথির সেকশন ৭-এর ছয়টা ব্যর্থতার মধ্যে পাঁচটাই সম্পূর্ণ কাঠামোগত — চ্যানেল সংখ্যা, অনাথ UID, ব্লক টাইমিং, স্যাম্পল রেট দ্বন্দ্ব, ঝুলন্ত রেফারেন্স — এবং এগুলোর একটাও শোনার উপর নির্ভর করে না। ষষ্ঠটা (খালি বেড চ্যানেল) স্যাম্পল-স্তরের বিশ্লেষণে ধরা পড়ে, কানে নয়। QC-তে যত ফাইল বাতিল হয় তার বিপুল সংখ্যাগরিষ্ঠ অংশ মনিটরিংহীন একটা ল্যাপটপে ধরা সম্ভব।

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

ব্যবহারিক পরামর্শ কয়েকটা:

• রেকর্ডিংয়ের সময় জ্যামিতি লিখে রাখুন। আখড়ায় বা মণ্ডপে কে কোথায় বসেছিলেন, কে কোন দিকে হেঁটেছেন, কোন মিনিটে মিছিল কোন দিকে ছিল — কাগজে বা ফোনে। পরে ADM-এ অবস্থান বসানোর সময় এই নোটটাই আপনার একমাত্র সত্যের উৎস হবে, কারণ কান দিয়ে সেটা পুনর্গঠন করা যাবে না।
• অ্যাম্বিসনিক মাইক থাকলে বেড হিসেবে সেটাই ব্যবহার করুন। একটা ফার্স্ট-অর্ডার অ্যাম্বিসনিক রেকর্ডিংও স্টেরিও জোড়ের চেয়ে অনেক বেশি সৎভাবে বৃত্তাকার আসর ধরে, এবং সেটা HOA প্যাক হিসেবে ADM-এ বসানো সরল।
• XML আলাদা করে সংরক্ষণ করুন। BW64 বাইনারি; axml-এর অনুলিপি আলাদা রাখলে পরে diff করা যায়, আর কী বদলেছে সেটা দেখতে গোটা ফাইল আবার পার্স করতে হয় না।
• একই ফাইল অন্তত দুটো ভিন্ন পার্সার দিয়ে পড়ুন। একটা টুলের বাগ দুটোতে একইভাবে থাকে না।

১০. ডেলিভারি চেকলিস্ট

ক্রম মেনে চলুন। কাঠামোগত পরীক্ষা আগে — সেগুলো দ্রুত, আর ব্যর্থ হলে নিচের সবকিছু অর্থহীন।

কন্টেইনার

1. প্রথম চার বাইট BW64। RIFF হলে এটা সাধারণ WAV, ৪ GiB ছাড়াতে পারবে না।
2. স্বাক্ষরের পরেই ds64, আর তার ৬৪-বিট মানগুলো ডিস্কে ফাইল ও data-র প্রকৃত আকারের সঙ্গে মেলে।
3. data ছাড়া অন্য কোনো অতিরিক্ত-বড় চাঙ্ক থাকলে তার জন্য ds64 টেবিলে ChunkSize64 এন্ট্রি আছে।
4. axml স্পষ্টভাবে খুঁজুন, data-র পরেও। আংশিক স্ক্যান থেকে "ADM নেই" সিদ্ধান্তে যাবেন না।

এসেন্স

1. fmt -এর স্যাম্পল রেট ও বিট ডেপথ স্পেসিফিকেশনের সঙ্গে হুবহু মেলে। ADM লেখার পরে কোনো SRC নয়।
2. fmt.nChannels = chna.numTracks।
3. chna-র প্রতিটা trackIndex পরিসরের ভিতরে এবং ১-ভিত্তিক।

chna অখণ্ডতা

1. প্রতিটা এন্ট্রি ঠিক ৪০ বাইট, প্রতিটা ফিল্ড সঠিকভাবে প্যাড করা নির্দিষ্ট-প্রস্থ ASCII (2 + 12 + 14 + 11 + 1)।
2. 0x1000 বা তার উপরের প্রতিটা packRef axml-এ উপস্থিত একটা কাস্টম সংজ্ঞায় গিয়ে মেলে।
3. একই trackIndex বারবার এলে সেটা ইচ্ছাকৃত (ট্র্যাক বৈধভাবে সংজ্ঞা বদলাচ্ছে), নকল এন্ট্রি নয়।

ADM গ্রাফ

1. প্রতিটা audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef ও audioTrackUIDRef সমাধান পায়। শূন্য ঝুলন্ত প্রান্ত।
2. দু'দিকের কোনোদিকেই অনাথ audioTrackUID নেই।
3. কোনো চক্রাকার বা আত্ম-নির্দেশক উপাদান নেই।
4. প্রতিটা audioChannelFormat-এর typeLabel তার মূল audioPackFormat-এর সঙ্গে মেলে।

টাইমিং

1. একাধিক ব্লকওয়ালা প্রতিটা চ্যানেল ফরম্যাটে প্রতিটা ব্লকে rtime ও duration দুটোই আছে।
2. ব্লকগুলো ধারাবাহিক ও একমুখী; সব duration-এর যোগফল মূল audioObject-এর দৈর্ঘ্যের সমান।
3. অবজেক্ট শুরু হচ্ছে 00:00:00.00000-এ।

কনটেন্ট

1. ঘোষিত বেডের প্রতিটা চ্যানেলে যা থাকার কথা তাই আছে; ডিজিটাল নীরবতা পেলে খতিয়ে দেখুন।
2. অবজেক্টের সংখ্যা ও বেড কনফিগারেশন স্পেসিফিকেশনের সঙ্গে মেলে।
3. bext স্টার্ট টাইমকোড সঠিক এবং সেটের সব ডেলিভারেবলে একই।

রেন্ডার ও কনফর্ম

1. স্টেরিও ও বাইনরাল কনফর্ম বর্তমান মাস্টার থেকে নতুন করে রেন্ডার করা, আগেরটা টেনে আনা নয়।
2. দৈর্ঘ্য ও স্টার্ট টাইমকোড মাস্টারের সঙ্গে স্যাম্পল ধরে মেলে।
3. লাউডনেস একটা নামধারী রেন্ডারে, একটা নামধারী লেআউটে, একটা নামধারী রেন্ডারার দিয়ে মাপা — তিনটেই ডেলিভারি নোটে লেখা।

পুনরুৎপাদনযোগ্যতা

1. প্রতিটা ডেলিভারেবলের চেকসাম নিন, ম্যানিফেস্ট রাখুন।
2. সেশন আর ADM XML BW64-র বাইরে আলাদা করে আর্কাইভ করুন; যে XML diff করা যায় সেটা পরে সেই বাইনারির চেয়ে বেশি কাজে দেয় যেটা কেবল আবার পার্স করা যায়।

একটা ইমার্সিভ ডেলিভারেবল তখন শেষ হয় না যখন সেটা শুনতে ঠিক লাগে; শেষ হয় তখন, যখন এমন একটা যন্ত্র — যে কোনোদিন সেটা শোনেনি — প্রমাণ করতে পারে যে এর সব রেফারেন্স মেলে।

১১. শেষ কথা

BW64 আর ADM খোলা, প্রকাশিত, বিনামূল্যে পাঠযোগ্য মান। শিল্পের এই কোণে সেটা বিরল, এবং সেই সুযোগটা নেওয়া উচিত: BS.2088 আর BS.2076 আপনি নিজে পড়তে পারেন, চল্লিশ লাইন কোড লিখে একটা chna চাঙ্ক পার্স করতে পারেন, আর কোনো এক্সপোর্টারের ডায়ালগ বক্স যা দাবি করছে তার বদলে সে আসলে কী লিখেছে সেটা যাচাই করতে পারেন। এটা এমন একটা ক্ষমতা যা ইমার্সিভ মনিটরিং রুমের উপর নির্ভর করে না — একটা ল্যাপটপ আর ধৈর্যই যথেষ্ট। ইমার্সিভ অডিওতে অপ্রয়োজনীয় প্রত্যাখ্যানের হার এখনো সবচেয়ে বেশি, আর তার প্রায় সবটাই রেফারেন্স-অখণ্ডতার ভুল, যা একটা ভ্যালিডেটর এক সেকেন্ডেরও কমে ধরে ফেলে।

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

সূত্র

ITU-R সুপারিশ

• ITU-R BS.2088-2 (১১/২০২৫), Long-form file format for the international exchange of audio programme materials with metadata (BW64) — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2088-2-202511-I!!PDF-E.pdf
• ITU-R BS.2076-3 (০২/২০২৫), Audio Definition Model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-3-202502-I!!PDF-E.pdf
• ITU-R BS.2076-2 (১০/২০১৯), Audio definition model — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2076-2-201910-S!!TOC-HTM-E.htm
• ITU-R BS.1770-5 (১১/২০২৩), Algorithms to measure audio programme loudness and true-peak audio level — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• ITU-R BS.2051-2 (০৭/২০১৮), Advanced sound system for programme production — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2051-2-201807-S!!PDF-E.pdf
• ITU-R BS.2127-1 (১১/২০২৩), Audio Definition Model renderer for advanced sound systems — https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.2127-1-202311-I!!PDF-E.pdf
• ITU-R BS.2127 ল্যান্ডিং পেজ — https://www.itu.int/rec/R-REC-BS.2127

EBU কারিগরি নথি

• EBU Tech 3306, RF64: An extended file format for audio data — https://tech.ebu.ch/docs/tech/tech3306.pdf
• EBU Tech 3285 (ও সাপ্লিমেন্ট), Specification of the Broadcast Wave Format — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3285s7.pdf
• EBU Tech 3392, ADM Broadcast Production Profile — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3392.pdf
• EBU Tech 3388, ADM Renderer for use in Next Generation Audio broadcasting — https://tech.ebu.ch/docs/tech/tech3388.pdf এবং https://tech.ebu.ch/publications/tech3388
• EBU Tech 3343, Practical guidelines for production and implementation in accordance with EBU R 128 — https://tech.ebu.ch/files/live/sites/tech/files/shared/tech/tech3343v2_0.pdf
• EBU R 128, EBU Tech 3341 (মিটার), EBU Tech 3342 (Loudness Range) — https://tech.ebu.ch
• EBU ADM Guidelines — CHNA chunk — https://adm.ebu.io/reference/excursions/chna_chunk.html
• EBU ADM Guidelines — BW64 and ADM — https://adm.ebu.io/reference/excursions/bw64_and_adm.html
• EBU ADM Guidelines — audioTrackUID — https://adm.ebu.io/reference/adm_elements/audio_track_uid.html
• EBU ADM Renderer (EAR) ডকুমেন্টেশন, BW64 I/O — https://ear.readthedocs.io/en/latest/BW64.html
• libbw64 রেফারেন্স ইমপ্লিমেন্টেশন — https://github.com/ebu/libbw64
• libadm রেফারেন্স ইমপ্লিমেন্টেশন — https://github.com/ebu/libadm

AES

• AES TD1008, Recommendations for loudness of internet audio streaming and on-demand distribution — https://www.aes.org/community/technical-council/technical-document-aestd1008/

সার্ভিস ডকুমেন্টেশন

• Spotify, Loudness normalization — https://support.spotify.com/us/artists/article/loudness-normalization/

সর্বশেষ পর্যালোচনা: সেপ্টেম্বর ২০২৬। মানগুলো সংশোধিত হয়; কোনো ধারা উদ্ধৃত করার আগে উপরের ITU ও EBU পাতাগুলোতে বর্তমান সংস্করণ দেখে নিন।