একটি ইমার্সিভ মাস্টার কেন ওয়েভফর্ম এডিটরে পাশ করে আর QC-তে ফেল করে

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

তিন ধরনের অডিও, আর কেন এই পার্থক্যই সবকিছু ঠিক করে দেয়

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

চ্যানেল-ভিত্তিক অডিও প্রতিটি ট্র্যাককে একটি নির্দিষ্ট লাউডস্পিকার অবস্থানে বরাদ্দ করে। স্টেরিও চ্যানেল-ভিত্তিক, 5.1-ও তাই, একটি 7.1.4 বেডও তাই। অবস্থানটি চ্যানেলের পরিচয়ের ভিতরেই ঢালাই করা: ট্র্যাক 3 হল সেন্টার স্পিকার, আর যে সিস্টেমই বাজাক, সেটি সেন্টার স্পিকারই থাকে। ITU-R BS.2051 উন্নত সাউন্ড সিস্টেমের জন্য এটিকে আনুষ্ঠানিক রূপ দেয়, লেআউটগুলিকে Upper + Middle + Bottom স্তরসংখ্যা হিসেবে বর্ণনা করে — System A হল 0+2+0 (স্টেরিও), System B হল 0+5+0 (5.1), System D হল 4+5+0, System J হল 4+7+0, System H হল 9+10+3, অর্থাৎ 22.2 বিন্যাস। ADM-এ এটি DirectSpeakers typeDefinition, typeLabel 0001।

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

দৃশ্য-ভিত্তিক অডিও, বাস্তবে Higher-Order Ambisonics, গোটা শব্দক্ষেত্রটিকে গোলীয়-সমমেল উপাদান হিসেবে এনকোড করে। কোনও উপাদান নিজে থেকে কোনও দিকের সঙ্গে মেলে না; দিক তৈরি হয় রৈখিক সমাবেশ থেকে। এটি HOA, typeLabel 0004। ADM আরও সংজ্ঞায়িত করে Matrix (0002), Mid-Side বা Lt/Rt-র মতো ম্যাট্রিক্সড সংকেতের জন্য, এবং Binaural (0005)।

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

BW64-এর অস্তিত্ব একটি 32-bit সংখ্যার কারণে

চিরাচরিত WAV একটি RIFF ফাইল। 1991 সালের RIFF প্রতিটি চাংকের আগে একটি 32-bit আকার-ঘর বসায়। বত্রিশ বিট 4,294,967,296 বাইট — 4 GB — পর্যন্ত ঠিকানা দিতে পারে, আর সেটিই গোটা ফাইল আর তার ভিতরের data চাংক, দুইয়েরই কঠিন সীমা।

48 kHz / 24-bit স্টেরিওতে ডেটার হার সেকেন্ডে 288,000 বাইট, তাই 4 GB মানে প্রায় 4 hours 8 minutes। অপ্রাসঙ্গিক। 96 kHz / 24-bit-এ 128-ট্র্যাকের একটি অবজেক্ট-ভিত্তিক মাস্টারের ক্ষেত্রে হারটি সেকেন্ডে 36,864,000 বাইট, আর 4 GB মানে দুই মিনিটেরও কম — 116.5 seconds।

ইমার্সিভ মাস্টার নিয়মিতই ওই সীমা ছাড়ায়, আর সীমায় ঠেকা কোনও WAV রাইটার হয় একটি কাটা-পড়া ফাইল তৈরি করে, নয়তো এমন একটি যার ঘোষিত আকারগুলি নিঃশব্দে র‍্যাপ করে গেছে। EBU প্রথমে এর সমাধান দেয় RF64 দিয়ে (EBU Tech 3306); ITU সেটিকে এগিয়ে নিয়ে যায় Recommendation ITU-R BS.2088 হিসেবে — BW64।

সেন্টিনেল কৌশল: 0xFFFFFFFF আর একটি ds64 চাংক

BS.2088 কলকব্জাটি নিয়ে স্পষ্ট। "The ID 'BW64' is used instead of 'RIFF' in the first four bytes of the file", আর মূল 32-bit আকার-ঘরগুলি হয়ে ওঠে এস্কেপ ফ্ল্যাগ: "If the 32-bit value in the field is 0xFFFFFFFF the 64-bit value in the 'ds64' chunk is used instead."

গোটা কৌশলটি এটুকুই, আর সোজাসুজি বলা দরকার: BW64 RIFF-এর আকার-ঘরগুলি চওড়া করে না। এটি সেগুলিতে সেন্টিনেল হিসেবে 0xFFFFFFFF ভরে দেয় আর আসল 64-bit আকারগুলি রাখে একটি ds64 চাংকে, যেটিকে ফাইলের সবার প্রথমে বসতে হয়। ফলে 4 GB-র নিচের একটি BW64 ফাইল চার-অক্ষরের স্বাক্ষরটুকু বাদে সব দিক থেকেই একটি WAV রিডারের সঙ্গে বাইট-সঙ্গতিপূর্ণ। অনেক টুল সেটি মেনে নেয়; কিছু গোঁ ধরে নেয় না।

চাংকগুলি, আর যেটির প্রতিটি এন্ট্রি ঠিক 40 বাইট

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

ds64-কে স্বাক্ষরের পরে প্রথম চাংক হতে হয়, কারণ অন্য কিছু হাঁটার আগে রিডারকে আসল আকারগুলি জানতে হয়। এটি গোটা ফাইলের আকার আর data-র আকারের জন্য 32-bit নিম্ন/উচ্চ অর্ধ বহন করে, সঙ্গে অন্য যেকোনও অতিরিক্ত-বড় চাংকের জন্য ChunkSize64 এন্ট্রির একটি টেবিল — স্যাম্পল-নিখুঁত অটোমেশনসহ হাজার হাজার অবজেক্ট বর্ণনাকারী একটি axml চাংক নিজেই 4 GB-র কাছে পৌঁছতে বা ছাড়িয়ে যেতে পারে।

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

chna হল ভৌত ট্র্যাক আর ADM-এর মধ্যে সেতু। ckID, ckSize, একটি 2-বাইটের numTracks ও একটি 2-বাইটের numUIDs-এর পরে এটি ধরে রাখে নির্দিষ্ট-প্রস্থের audioID এন্ট্রির একটি সমতল অ্যারে, প্রতিটি ঠিক 40 বাইট:

2 + 12 + 14 + 11 + 1 = 40। প্রস্থগুলি পরামর্শমাত্র নয়: সেগুলি নির্দিষ্ট-প্রস্থের ASCII, আর যে রাইটার 13 অক্ষরের একটি UID লেখে সে সামান্য অস্বাভাবিক নয়, বরং একটি নষ্ট টেবিল তৈরি করেছে।

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

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 একটি UTF-8 XML নথি, যাতে থাকে <audioFormatExtended> গাছটি। ওটিই ADM, আর কার্যত সব চিত্তাকর্ষক ব্যর্থতা ওখানেই বাস করে। data নিছক ইন্টারলিভড PCM; তার কিছুই অবজেক্ট সম্পর্কে কিছু জানে না।

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

ADM একটি গ্রাফ, আর ব্যর্থতাগুলি ভাঙা প্রান্ত

ITU-R BS.2076-এর ক্রমটি চলে audioProgramme → audioContent → audioObject → audioPackFormat → audioChannelFormat → audioBlockFormat, যেখানে audioTrackUID পাতা এবং একমাত্র উপাদান যা কোনও ভৌত ট্র্যাকের সঙ্গে মেলে।

ওটি রেফারেন্সের একটি গ্রাফ, বাসা-বাঁধা নথি নয়, আর প্রতিটি গুরুতর ডেলিভারি ব্যর্থতা তার একটি ভাঙা প্রান্ত। ঝুলন্ত রেফারেন্স বিপজ্জনক হওয়ার কারণ হল, একটি ভাঙলে কোনও একক আচরণ ঘটে না। XML-এ অনুপস্থিত একটি প্যাকের নাম করা audioPackFormatIDRef মেলাতে গিয়ে একটি রেন্ডারার পার্স থামিয়ে ফাইলটি প্রত্যাখ্যান করতে পারে; ওই অবজেক্টটি বাদ দিয়ে বাকি সব রেন্ডার করতে পারে, ফলে একটি স্টেম নিঃশব্দে হারিয়ে যাওয়া মিক্স তৈরি হয়; অথবা সাধারণ সংজ্ঞায় ফিরে গিয়ে 0x1000-ঊর্ধ্ব কাস্টম পরিসরে কোনও মিল না পেয়ে নীরবতা বসিয়ে দিতে পারে। তিনটি ফলাফলই "ফাইলটি খুলেছে"। একটিমাত্র শুনে ধরা যায়, তা-ও যদি আপনি জানেন কী থাকার কথা ছিল।

যে চারটি ব্যর্থতা বেশিরভাগ প্রত্যাখ্যানের জন্য দায়ী

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

কোনও অবজেক্ট যাকে দেখায় না, এমন একটি audioTrackUID। chna-তে থাকা যে UID-কে কোনও audioObject দেখায় না, তার মানে এমন অডিও আছে যা কিছুই রেন্ডার করবে না; আর উল্টো ক্ষেত্রে, XML-এ থাকা যে audioTrackUIDRef-এর সঙ্গে মেলে এমন কোনও chna এন্ট্রি নেই, তার মানে মেটাডেটা এমন একটি ট্র্যাক আশা করছে যা নেই। chna থেকে UID-এর সেট আর axml থেকে সেটটি বানিয়ে তাদের প্রতিসম পার্থক্য নিন; সেটি ফাঁকা হওয়া উচিত। 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-এ, কোনও ব্লক এক স্যাম্পলের চেয়ে ছোট নয়, আর সময়কালগুলির যোগফল মূল audioObject-এর সমান। নথির ক্রমে ব্লকগুলি হাঁটুন আর নিশ্চিত করুন rtime[n] + duration[n] == rtime[n+1]। ব্যর্থতা তিন চেহারায় আসে: ফাঁক, যেখানে রেন্ডারারের আচরণ অসংজ্ঞায়িত আর কেউ শেষ অবস্থান ধরে রাখে, কেউ নিঃশব্দ করে দেয়; ওভারল্যাপ, যেখানে ব্লকেরা লড়ে; আর কালানুক্রমের বাইরে চলে যাওয়া ব্লক, অর্থাৎ প্রোগ্রামের মাঝপথে অটোমেশনের পিছনে লাফ।

XML-এ বর্ণিত একটি বেড, যা কখনও ডিস্কে ছাপাই হয়নি। XML ঘোষণা করে একটি 7.1.4 DirectSpeakers প্যাক — বারোটি চ্যানেল — অথচ ছাপা হয়েছে কেবল 5.1 উপসেটটি, বা বাউন্সের সময় হাইট চ্যানেলগুলি মিউট ছিল আর ডিজিটাল ব্ল্যাক হিসেবে ছাপা হয়েছে। রেফারেন্স গ্রাফ অটুট; অডিও নয়। গঠনগত যাচাই এটি ধরতে পারে না: এর জন্য চাই এসেন্স বিশ্লেষণ, অর্থাৎ মেপে দেখা যে একটি DirectSpeakers প্যাকের দাবি করা প্রতিটি চ্যানেলে আদৌ কোনও সংকেত আছে কি না। ঘোষিত বেড চ্যানেলে ডিজিটাল ব্ল্যাক আপনাআপনি ত্রুটি নয় — একটি বৈধ মিক্স একটি টপ-রিয়ার চ্যানেল ফাঁকা রাখতেই পারে — কিন্তু এটি সবসময়ই একজন মানুষের সিদ্ধান্তের যোগ্য।

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

একটি সংখ্যা স্টেরিও থেকে সরে আসার ধাক্কা সামলাতে পারে না, আর কেন পারে না তা বলা দরকার।

BS.1770-5 (November 2023) বর্তমান সংস্করণ; BS.1770-4 রদ, যদিও ব্যবহারে থাকা বেশিরভাগ মিটার এখনও সেটিরই উল্লেখ করে। এর মূল অ্যালগরিদম L, R ও C-কে 1.0 ওজন দেয় আর Ls ও Rs-কে 1.41 (প্রায় +1.5 dB), LFE বাদ দেয়, আর এর পরিধি "from one to five channels"। BS.1770-5 তার সংযোজনীতে এর বাইরেও যায়, BS.2051-এর উন্নত সাউন্ড সিস্টেম আর অবজেক্ট-ভিত্তিক অডিওকে ধরে — যেটিকে মাপার আগে রেন্ডার করতেই হয়। তাই ইমার্সিভ লাউডনেস ফাইলের ধর্ম নয়, একটি রেন্ডারের ধর্ম, আর লক্ষ্য লেআউট বদলালে সংখ্যাটিও বদলায়। একটি নামধারী BS.2051 লেআউটে করা BS.2127-সঙ্গত রেন্ডারকে একটি BS.1770-5 মিটার দিয়ে মাপুন আর তিনটিই আপনার ডেলিভারি নোটে লিখে রাখুন; BS.2127 রেফারেন্স ADM রেন্ডারার সংজ্ঞায়িত করে, আর তার ওপেন-সোর্স সহোদর EBU ADM Renderer (EBU Tech 3388) একটি পুনরুৎপাদনযোগ্য সংখ্যা পাওয়ার ব্যবহারিক উপায়।

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

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

পাঠানোর আগে কী যাচাই করবেন

আগে গঠনগত যাচাই; সেগুলি দ্রুত, আর সেগুলি এর পরের সবকিছু বাতিল করে দেয়।

• প্রথম চার বাইট BW64। সেখানে RIFF পড়লে সেটি নিছক WAV আর 4 GB ছাড়াতে পারে না।
• স্বাক্ষরের পরে ds64-ই প্রথম চাংক, তার 64-bit আকারগুলি ডিস্কে থাকা ফাইল ও data-র আকারের সঙ্গে মেলে, আর data ছাড়া যেকোনও অতিরিক্ত-বড় চাংকের টেবিলে একটি ChunkSize64 এন্ট্রি আছে।
• axml স্পষ্টভাবে খুঁজে বার করুন, data-র পরেরটিও — আংশিক স্ক্যান থেকে কখনও "কোনও ADM নেই" সিদ্ধান্তে আসবেন না।
• fmt স্যাম্পল রেট আর বিট ডেপথ ডেলিভারি স্পেকের সঙ্গে হুবহু মেলে। ADM লেখার পরে কোনও স্যাম্পল-রেট রূপান্তর নয় — তাতে স্যাম্পলে প্রকাশ করা প্রতিটি rtime ও duration বাতিল হয়ে যায়।
• fmt .nChannels সমান chna.numTracks; প্রতিটি trackIndex পরিসরের মধ্যে আর 1 থেকে শুরু।
• প্রতিটি chna এন্ট্রি ঠিক 40 বাইট, নির্দিষ্ট-প্রস্থের ঘরগুলি ঠিকমতো প্যাড করা, আর 0x1000 বা তার উপরের প্রতিটি packRef axml-এ উপস্থিত একটি কাস্টম সংজ্ঞায় গিয়ে মেলে।
• প্রতিটি audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef ও audioTrackUIDRef মেলে। কোনও দিকেই শূন্যটিও ঝুলন্ত প্রান্ত নেই, আর কোনও চক্রাকার রেফারেন্সও নেই।
• বহু-ব্লকের চ্যানেল ফরম্যাটে প্রতিটি ব্লকে rtime ও duration দুটোই আছে; ব্লকগুলি ধারাবাহিক ও একমুখী; অবজেক্ট শুরু হয় 00:00:00.00000-এ।
• ঘোষিত বেডের প্রতিটি চ্যানেলে যা থাকার কথা তা আছে। ডিজিটাল ব্ল্যাক খতিয়ে দেখুন।
• bext স্টার্ট টাইমকোড গোটা সেট জুড়ে সঙ্গতিপূর্ণ, আর স্টেরিও ও বাইনরাল কনফর্মগুলি চলতি মাস্টার থেকে নতুন করে রেন্ডার করা। ইমার্সিভ মূলের তুলনায় 40 ms আগে থাকা একটি কনফর্ম ফাইল-উপস্থিতির যাচাইয়ে পাশ করে আর সমলয়ে শুনলে ফেল করে।
• প্রতিটি ডেলিভারেবলের চেকসাম নিন, ম্যানিফেস্ট রাখুন, আর ADM XML-কে BW64 থেকে আলাদা করে সংরক্ষণ করুন — যে XML আপনি ডিফ করতে পারেন, পরে তার দাম কেবল আবার পার্স করা যায় এমন বাইনারির চেয়ে বেশি।

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

Mazufa-র বিনামূল্যের BW64/ADM ইনস্পেক্টর আছে mazufa.com/immersive-master-check ঠিকানায়; এটি কনটেইনার আর মেটাডেটা সম্পূর্ণভাবে আপনার নিজের ডিভাইসেই পার্স করে আর কিছুই আপলোড করে না, ফলে চুক্তি অনুযায়ী যে উপকরণ ভবন ছেড়ে বেরোতে পারে না, তার উপরেও এটি ব্যবহারযোগ্য। Mazufa নিজে প্রকাশ করার জন্য বিনামূল্যের, 0% কমিশন নেয়, আর কেবল আমন্ত্রণে চলে, যেখানে প্রতিটি সম্পূর্ণ আবেদন একজন মানুষ পড়ে দেখেন।

সূত্র

ITU-R সুপারিশ

• ITU-R BS.2088-2 (11/2025), 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 (02/2025), 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.1770-5 (11/2023), 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 (07/2018), 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 (11/2023), 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

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/publications/tech3388
• 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
• libbw64 রেফারেন্স ইমপ্লিমেন্টেশন — https://github.com/ebu/libbw64

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/