BW64 और ADM: इमर्सिव ऑडियो डिलीवरी का तकनीकी संदर्भ

हिंदुस्तानी मंच को ऑब्जेक्ट-आधारित दृश्य की तरह लिखने, और उस फ़ाइल को जाँचने के लिए जिसे आप ठीक से सुन ही नहीं सकते।

छोटा जवाब

ADM (Audio Definition Model — ऑडियो परिभाषा मॉडल), यानी सिफ़ारिश ITU-R BS.2076, एक खुला मेटाडेटा मानक है जो बताता है कि फ़ाइल का हर ट्रैक है क्या — एक निश्चित लाउडस्पीकर का चैनल, एक चलता-फिरता ऑब्जेक्ट, या एम्बिसॉनिक क्षेत्र का एक घटक — और वे ट्रैक मिलकर कौन-सा प्रोग्राम बनाते हैं। यह XML के रूप में BW64 कंटेनर (सिफ़ारिश ITU-R BS.2088) के भीतर जाता है, जो RIFF/WAVE का 64-बिट विस्तार है और जिसका पूरा अस्तित्व ही साधारण WAV की 4 GB की छत तोड़ने के लिए है। इमर्सिव डिलीवरी बार-बार QC में इसलिए फेल होती है कि ऑडियो और मेटाडेटा दो अलग चीज़ें हैं जिन्हें हूबहू एक-दूसरे से मेल खाना चाहिए, और फ़ाइल-फ़ॉर्मैट में ऐसा कुछ नहीं है जो उन्हें ज़बरदस्ती मिलाए। fmt में लिखी चैनल-संख्या का chna तालिका से न मिलना, किसी ऑब्जेक्ट द्वारा संदर्भित न किया गया audioTrackUID, पीछे की ओर चलता ब्लॉक-टाइमिंग, XML में वर्णित वह bed जो डिस्क पर कभी छपा ही नहीं — इनमें से कोई भी तरंग-संपादक (waveform editor) को दिखाई नहीं देता और रेंडरर के लिए हर एक घातक है। इमर्सिव QC कान का काम नहीं, संदर्भ-अखंडता (reference integrity) की जाँच है — और यही वजह है कि इमर्सिव मॉनिटरिंग के बिना भी आप एक फ़ाइल को निर्णायक रूप से सही या ग़लत सिद्ध कर सकते हैं।

1. हिंदुस्तानी मंच पहले से ही एक ऑब्जेक्ट-आधारित दृश्य है

ऑब्जेक्ट-आधारित ऑडियो को समझाने के लिए आमतौर पर हेलिकॉप्टर या उड़ती हुई मक्खी का उदाहरण दिया जाता है। हिंदी में काम करने वाले इंजीनियर के लिए इससे कहीं बेहतर, और कहीं ज़्यादा ईमानदार उदाहरण मौजूद है: शास्त्रीय बैठक का मंच।

उस मंच की ज्यामिति मनमानी नहीं है। वह सदियों में तय हुई है और उसका हर हिस्सा अर्थपूर्ण है:

• गायक या मुख्य वादक बीच में, श्रोताओं की ओर मुँह किए।
• तानपूरा वाले ठीक पीछे — एक या दो, कभी-कभी दोनों तरफ़ — ताकि आधार-स्वर सामने से नहीं, चारों ओर से आता महसूस हो।
• तबला एक तरफ़, आम तौर पर गायक के दाहिने।
• सारंगी या हारमोनियम दूसरी तरफ़, बाएँ।

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

यह आदान-प्रदान संगीत के साथ-साथ स्थानिक (spatial) भी है। श्रोता हॉल में इसे दाएँ-से-बीच-से-बाएँ घूमते हुए सुनता है; यही घूमना ही उसे बताता है कि यह संवाद है, एकालाप नहीं। और स्टीरियो में ठीक यही सबसे पहले नष्ट होता है। दो-चैनल मिक्स में तबला और गायक को अलग रखने के लिए इंजीनियर को पैनिंग, EQ और स्तर से लड़ना पड़ता है, और जो बचता है वह "बाएँ तबला, बीच में गायक" जैसा एक चपटा चित्र होता है जिसमें दूरी, ऊँचाई और मुड़ने का अहसास ग़ायब है। स्टीरियो उसी संवाद को ढहा देता है जो इस विधा का पूरा मक़सद है।

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

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

इसी तरह गायक का दूर वाला माइक कोई "रिवर्ब चैनल" नहीं है। वह एक असली स्रोत है, असली जगह पर, जिसकी distance अधिक है। ऑब्जेक्ट के रूप में उसे लिखना ईमानदार भी है और उपयोगी भी: छोटे लेआउट पर रेंडरर उसे नज़दीक वाले माइक के साथ मिला देगा, बड़े लेआउट पर वह हॉल की गहराई देगा।

1.1 जुगलबंदी: वह हालत जिसमें दो मुख्य कलाकार सचमुच आमने-सामने होते हैं

बड़ा ख़याल की एक जुगलबंदी, या सितार–सरोद, या बाँसुरी–वायलिन की जोड़ी, इस दलील को और कड़ा कर देती है। यहाँ दो मुख्य कलाकार वास्तव में एक-दूसरे की ओर मुँह किए बैठते हैं — मंच के केंद्र में नहीं, बल्कि केंद्र से थोड़ा-थोड़ा दोनों ओर हटकर, ताकि वे एक-दूसरे को देख सकें। दो तबला वादक अक्सर पीछे-बाहर की ओर, अपने-अपने कलाकार के पीछे। तानपूरे बीच में।

स्टीरियो में इसे मिक्स करने का एक ही तरीक़ा है: एक कलाकार को बाएँ, दूसरे को दाएँ। यह पहले पाँच मिनट तक प्रभावशाली लगता है और फिर थका देता है, क्योंकि यह उस बात को झुठलाता है जो श्रोता हॉल में महसूस करता है — कि दोनों कलाकार एक ही मंच पर, एक-दूसरे के सामने हैं, न कि दो अलग-अलग स्पीकरों में क़ैद।

ऑब्जेक्ट के रूप में यही दृश्य बिना किसी समझौते के लिखा जा सकता है: दोनों कलाकार केंद्र से समान कोण पर, आगे की ओर, थोड़ी-सी ऊँचाई के अंतर के साथ; उनके तबले उनके पीछे और बाहर; तानपूरे पीछे-केंद्र में। और यह एक ही मेटाडेटा 5.1 कमरे में, 7.1.4 कमरे में और हेडफ़ोन पर तीन अलग-अलग सही जवाब देता है — क्योंकि जवाब हर बार रेंडरर बनाता है, फ़ाइल नहीं।

2. तीन तरह का ऑडियो, और यह फ़र्क़ फ़ॉर्मैट क्यों तय करता है

कंटेनर से पहले मॉडल। इमर्सिव डिलीवरी की लगभग हर समस्या इस भ्रम से शुरू होती है कि कोई ट्रैक असल में इन तीन में से क्या है।

चैनल-आधारित (channel-based) ऑडियो में हर ट्रैक एक निश्चित लाउडस्पीकर की जगह से बँधा होता है। स्टीरियो चैनल-आधारित है; 5.1 भी; और 7.1.4 का "bed" भी। स्थिति चैनल की पहचान में ही गड़ी हुई है: ट्रैक 3 सेंटर स्पीकर है, और हर सिस्टम पर सेंटर स्पीकर ही रहेगा। ITU-R BS.2051 इसी को औपचारिक रूप देता है और लाउडस्पीकर लेआउट को ऊपरी + मध्य + निचली परतों की गिनती से परिभाषित करता है — 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।

ऑब्जेक्ट-आधारित (object-based) ऑडियो में एक मोनो (या बहु-चैनल पैक) सिग्नल के साथ समय के साथ बदलती स्थिति-संबंधी मेटाडेटा चलती है। कौन-से असली स्पीकर इसे बजाएँगे और कैसे, यह रेंडरर तय करता है, उस कमरे के हिसाब से जो वाक़ई मौजूद है। ट्रैक किसी स्पीकर को मानकर चलता ही नहीं। यह Objects है, typeLabel 0003।

दृश्य-आधारित (scene-based) ऑडियो, व्यवहार में हायर-ऑर्डर एम्बिसॉनिक्स, पूरे ध्वनि-क्षेत्र को गोलीय हरात्मक (spherical harmonic) घटकों के समुच्चय के रूप में लिखता है। कोई एक घटक अपने आप किसी दिशा का प्रतिनिधि नहीं होता; दिशा घटकों के रैखिक संयोग से उभरती है। यह HOA है, typeLabel 0004। ADM में Matrix (0002) मैट्रिक्स्ड सिग्नलों के लिए (जैसे Mid-Side या Lt/Rt) और Binaural (0005) सीधे हेडफ़ोन के लिए तैयार जोड़ों के लिए भी परिभाषित हैं।

चैनल-आधारित ऑडियो फ़ाइल को बताता है कि स्पीकर कहाँ हैं; ऑब्जेक्ट-आधारित ऑडियो अनुमान लगाने से इनकार करता है; और दृश्य-आधारित ऑडियो स्रोतों की जगह पूरे क्षेत्र का वर्णन करता है।

यह वर्गीकरण अपने आप में शौक़ की चीज़ नहीं है। चैनल-आधारित डिलीवरेबल इतना आत्म-वर्णनकारी होता है कि नंगे WAV के रूप में भी बच जाए — चैनल क्रम ठीक हो तो बज जाएगा। ऑब्जेक्ट-आधारित या दृश्य-आधारित डिलीवरेबल अपनी मेटाडेटा के बिना निरर्थक है: ऑडियो केवल एक-सी दिखने वाली मोनो धाराओं का ढेर है, और ADM ही एकमात्र चीज़ है जो कहती है कि वे क्या हैं। यही असंतुलन BW64 और ADM के होने की पूरी वजह है, और यही वजह है कि इमर्सिव QC स्टीरियो QC से कठिन है।

3. हॉल, हवेली और मंदिर का आँगन: bed क्या है और ऑब्जेक्ट क्या

ऑब्जेक्ट सब कुछ नहीं होते। सही इमर्सिव प्रस्तुति लगभग हमेशा bed + ऑब्जेक्ट होती है, और भारतीय प्रस्तुति-स्थलों में यह विभाजन असामान्य रूप से साफ़ है।

बंद सभागार में। एक अच्छा शास्त्रीय सभागार अपेक्षाकृत सूखा होता है — गूँज इतनी नहीं कि सूक्ष्म मीड़ धुँधली पड़े। यहाँ मंच के कलाकार ऑब्जेक्ट हैं, और bed वह चीज़ है जो स्थल है: दीवारों से लौटती परावर्तित ध्वनि, हॉल का रव, और श्रोता। ऊपरी परत के चार चैनल छत की जल्दी लौटने वाली परावर्तनों को ढोते हैं और मुख्य रूप से कमरे को "ऊँचा" बनाते हैं।

खुले में — हवेली के आँगन या मंदिर प्रांगण में। यहाँ ऊपरी चैनलों का अर्थ पूरी तरह बदल जाता है, और यह बात अक्सर छूट जाती है। छत है ही नहीं। ऊपर से कोई परावर्तन नहीं आ रही। तो ऊँचाई के चैनल क्या ढो रहे हैं?

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

इससे एक ठोस मिक्सिंग निर्णय निकलता है, न कि केवल एक सुंदर बात: खुले स्थल पर ऊपरी चैनलों में कमरे का कृत्रिम रिवर्ब भरना ग़लत है। आप वहाँ वह चीज़ बना रहे हैं जो भौतिक रूप से मौजूद नहीं थी, और ऐसा करते ही रिकॉर्डिंग "स्टूडियो जैसी" लगने लगती है — ठीक वह गुण जो श्रोता उस माहौल में नहीं चाहता। ऊपरी परत को माहौल और श्रोता के लिए छोड़िए। bed में यही जाना चाहिए, और ADM में यह एक DirectSpeakers पैक है जिसकी अपनी अलग सामग्री है, मुख्य ऑब्जेक्टों की गूँज नहीं।

3.1 इसका असर माइक-योजना पर पड़ता है, मिक्स पर नहीं

यह भेद रिकॉर्डिंग के दिन ही तय होता है, बाद में नहीं। अगर bed को स्थल ढोना है तो स्थल को अलग से रिकॉर्ड करना पड़ेगा — यानी मंच से दूर, श्रोताओं के बीच और उनके पीछे, एक ऐसा माइक-सरणी जिसका काम कलाकारों को पकड़ना नहीं है। बंद सभागार में यह एक परिवेश-सरणी (ambience array) होती है; खुले आँगन में यह अक्सर और भी ऊपर उठाई जाती है, क्योंकि वहाँ जो चीज़ें ऊँचाई के चैनलों में जानी हैं — हवा, पक्षी, छत पर बैठे श्रोता — वे भौतिक रूप से ऊपर ही हैं।

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

4. BW64: यह क्या है और ठीक-ठीक क्यों है

साधारण WAV एक RIFF फ़ाइल है। RIFF, जो 1991 का है, हर chunk के आगे 32-बिट का आकार-फ़ील्ड लगाता है। बत्तीस बिट 4 294 967 296 बाइट — यानी 4 GB — तक पता कर सकते हैं, और यही पूरी फ़ाइल पर भी और उसके भीतर के data chunk पर भी कड़ी छत है।

हिसाब लगाइए। एक sample frame का आकार = चैनलों की संख्या × बाइट प्रति सैंपल (24-बिट = 3 बाइट)।

(यह पूरा अंकगणित आप ख़ुद जाँच सकते हैं; इस तालिका में एक भी संख्या किसी तीसरे पक्ष के दावे से नहीं आई है।)

तीसरी और चौथी पंक्ति को ठहरकर देखिए। एक बड़ा ख़याल विलंबित एकताल में चालीस मिनट से ऊपर जाना बिलकुल सामान्य है, और उसके बाद द्रुत, फिर तराना, फिर एक ठुमरी या भजन — पूरी बैठक डेढ़ से दो घंटे। 22 ट्रैक पर 96 kHz में साधारण WAV ग्यारह मिनट अठारह सेकंड में मर जाता है। यह "थोड़ा तंग" नहीं है; यह असंभव है। और अगर आप पूरी बैठक एक ही निरंतर टेक में रिकॉर्ड कर रहे हैं — जो शास्त्रीय संगीत में सामान्य पद्धति है, क्योंकि प्रस्तुति टुकड़ों में नहीं होती — तो आपके पास विकल्प ही नहीं है।

सीमा से टकराने वाला WAV राइटर दो में से एक चीज़ पैदा करता है: कटी हुई फ़ाइल, या ऐसी फ़ाइल जिसके घोषित आकार चुपचाप लपेटकर (wrap होकर) झूठ बोल रहे हैं। दूसरा वाला ज़्यादा ख़तरनाक है, क्योंकि वह खुलती है।

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", और पुराने 32-बिट फ़ील्ड अब 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 के आकार-फ़ील्डों को चौड़ा नहीं करता; वह उनमें संकेतक (sentinel) के तौर पर 0xFFFFFFFF भर देता है और असली 64-बिट आकार एक ds64 chunk में रखता है जिसका फ़ाइल में सबसे पहले होना अनिवार्य है।

BW64 को एक ही वंश की तीसरी पीढ़ी समझना सबसे आसान है। RIFF/WAVE ने chunk वाला कंटेनर दिया। Broadcast Wave (BWF, EBU Tech 3285) ने bext chunk जोड़ा — originator, टाइमकोड संदर्भ, coding history — और WAV को प्रसारण-विनिमय फ़ॉर्मैट बना दिया। BW64 यह सब बरक़रार रखता है, 64-बिट पता-प्रणाली जोड़ता है, और वे chunk जोड़ता है जो ADM ढोते हैं। 4 GB से छोटी BW64 फ़ाइल एक WAV रीडर के लिए हर मामले में बाइट-दर-बाइट अनुरूप है, सिवाय शुरुआती चार अक्षरों के; बहुत-से टूल इसे स्वीकार कर लेते हैं और कुछ हठपूर्वक नहीं करते।

5. Chunk की बनावट, अंकगणित के साथ

BS.2088 के अनुसार एक BW64 फ़ाइल में कम से कम <ds64-ck>, <fmt-ck>, <chna-ck>, <axml-ck> (जिसके विकल्प <bxml-ck> और <sxml-ck> हैं) और <wave-data> होने चाहिए।

5.1 ds64 — 64-बिट आकारों की तालिका

BW64 हस्ताक्षर के तुरंत बाद पहला chunk यही होना चाहिए, क्योंकि रीडर को कुछ भी चलने से पहले असली आकार पता होने चाहिए। इसके फ़ील्ड 64-बिट राशियों के 32-बिट आधे हिस्से हैं:

न्यूनतम payload = 8 + 8 + 8 + 4 = 28 बाइट, और उसमें 8 बाइट का chunk हेडर जोड़ें तो 36 बाइट।

एक असली मामला गिनिए। एक बैठक की रिकॉर्डिंग: 22 ट्रैक, 96 kHz, 24-बिट, कुल 90 मिनट (5 400 सेकंड)। data का आकार:

6 336 000 बाइट/सेकंड × 5 400 सेकंड = 34 214 400 000 बाइट

यह 4 294 967 296 से बहुत आगे है। इसलिए:

• data chunk का 32-बिट ckSize फ़ील्ड 0xFFFFFFFF से भर दिया जाता है — यह आकार नहीं, संकेतक है।
• असली मान ds64 में दो हिस्सों में जाता है:

dataSizeHigh = 34 214 400 000 ÷ 4 294 967 296 का पूर्णांक भाग = 7 (यानी 0x00000007) dataSizeLow = 34 214 400 000 − (7 × 4 294 967 296) = 34 214 400 000 − 30 064 771 072 = 4 149 628 928 (यानी 0xF7565000)

• रीडर इसे वापस जोड़ता है: (7 × 2³²) + 4 149 628 928 = 30 064 771 072 + 4 149 628 928 = 34 214 400 000। मेल खाता है।

ध्यान दीजिए कि dataSizeLow का मान 4 149 628 928 है, जो 4 294 967 296 से कम है — यह ज़रूरी है, वरना विभाजन ही ग़लत होगा। यह जाँच किसी भी ds64 पार्सर में लिखने लायक़ है।

table[] जितना दिखता है उससे कहीं ज़्यादा मायने रखता है। मान लीजिए एक फ़िल्म-स्कोर मिक्स में 24 ऑब्जेक्ट हैं और हर ऑब्जेक्ट की स्थिति हर 100 मिलीसेकंड पर अद्यतन होती है। 90 मिनट में यह प्रति ऑब्जेक्ट 54 000 audioBlockFormat ब्लॉक हैं, और सब मिलाकर 1 296 000 ब्लॉक। (यह मान लीजिए कि हर ब्लॉक का XML लगभग 300 बाइट लेता है — यह एक स्पष्ट रूप से घोषित अनुमान है, कोई प्रकाशित आँकड़ा नहीं — तो अकेला axml लगभग 389 MB का हो जाता है।) कुछ बड़े प्रोडक्शनों में यह 4 GB को छू भी सकता है, और तब data के अलावा किसी chunk के लिए 64-बिट आकार घोषित करने का इकलौता रास्ता यही तालिका है।

5.2 fmt — सार (essence) का विवरण

मानक WAVE फ़ॉर्मैट chunk: सैंपल फ़ॉर्मैट, सैंपल दर, चैनल संख्या, बिट डेप्थ, block align. यही एकमात्र आधिकारिक बयान है कि data में असल में कितने इंटरलीव्ड चैनल मौजूद हैं। इसके बाद की हर चीज़ उन चैनलों के बारे में मेटाडेटा है, और मेटाडेटा झूठ बोल सकती है।

5.3 chna — चैनल आवंटन तालिका, और उसका 40-बाइट अंकगणित

chna भौतिक ट्रैकों और ADM के बीच का पुल है। इसकी शुरुआत यूँ होती है:

• ckID — 4 बाइट, 'chna'
• ckSize — 4 बाइट
• numTracks — 2 बाइट, फ़ाइल में ट्रैकों की संख्या
• numUIDs — 2 बाइट, आगे आने वाली audioTrackUID प्रविष्टियों की संख्या

उसके बाद निश्चित-चौड़ाई वाली audioID प्रविष्टियों की एक सपाट सरणी। हर प्रविष्टि ठीक 40 बाइट की है:

2 + 12 + 14 + 11 + 1 = 40. ये चौड़ाइयाँ सलाह नहीं हैं; ये निश्चित-चौड़ाई ASCII हैं, और जो राइटर 13 अक्षर का UID लिखता है उसने "थोड़ी असामान्य" तालिका नहीं, भ्रष्ट तालिका बनाई है।

अपनी बैठक वाली फ़ाइल के लिए गिनिए। 22 ट्रैक, हर ट्रैक की एक ही परिभाषा, इसलिए 22 UID:

chna payload = 4 (numTracks + numUIDs) + (22 × 40) = 4 + 880 = 884 बाइट
पूरा chunk   = 8 (ckID + ckSize) + 884 = 892 बाइट

892 बाइट, जो 34 214 400 000 बाइट के ऑडियो का वर्णन करते हैं — यानी फ़ाइल का लगभग 3 करोड़ 84 लाख में से एक हिस्सा। यह अनुपात अपने आप में सोचने लायक़ है: फ़ाइल का सबसे छोटा हिस्सा ही वह हिस्सा है जो उसे सबसे ज़्यादा बार तोड़ता है।

अब एक बारीक मामला। मान लीजिए ट्रैक 17 मंच के बाएँ का स्पॉट माइक है। ख़याल के दौरान उस जगह सारंगी है और वह ट्रैक एक सारंगी-ऑब्जेक्ट है; कार्यक्रम के दूसरे हिस्से में, ठुमरी के लिए, वहीं हारमोनियम आ जाता है और ट्रैक की परिभाषा बदल जाती है। उस ट्रैक को दो UID मिलने चाहिए। तब numTracks 22 ही रहेगा पर numUIDs 23 हो जाएगा:

chna payload = 4 + (23 × 40) = 4 + 920 = 924 बाइट
पूरा chunk   = 8 + 924 = 932 बाइट

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 होगा, वह सही फ़ाइलों को ख़राब बता देता है।

ID की परिपाटी भी नोट कीजिए: 0x0FFF और उससे नीचे के मान ADM की common definitions को संदर्भित करते हैं — पहले से परिभाषित मानक चैनल और पैक फ़ॉर्मैट — जबकि 0x1000 और उससे ऊपर के मान custom परिभाषाएँ हैं जिनका axml में मौजूद होना अनिवार्य है। AP_00010003 common definition के हिसाब से 5.1 है और उसे XML की ज़रूरत नहीं; AP_00031001 एक custom ऑब्जेक्ट पैक है और XML के बिना वह लटका हुआ संदर्भ (dangling reference) है।

audioTrackUID एक भौतिक ट्रैक की पहचान के लिए फ़ाइल का क्रमांक है, और वह इसीलिए मौजूद है ताकि कोई ट्रैक प्रोग्राम के बीच में वैध रूप से यह बदल सके कि वह क्या ढो रहा है।

एक ज़रूरी बात हिंदी में काम करने वालों के लिए। chna के UID, trackRef और packRef फ़ील्ड निश्चित-चौड़ाई ASCII हैं। देवनागरी वहाँ कभी नहीं जा सकती, और जाने की कोशिश करने का मतलब है भ्रष्ट फ़ाइल। "तबला (दायाँ)" जैसा नाम केवल axml में, audioObject या audioChannelFormat के audioObjectName/audioChannelFormatName जैसे गुणों में जाता है — जहाँ वह UTF-8 पाठ है। यह विभाजन याद रखने लायक़ है: पहचान ASCII में, नाम UTF-8 में।

5.4 axml — ख़ुद ADM

एक XML दस्तावेज़, UTF-8 में, जिसमें <audioFormatExtended> वृक्ष होता है। यही ADM है। यह पाठ है, इसे पढ़ा जा सकता है, और दिलचस्प क़िस्म की लगभग सारी विफलताएँ यहीं रहती हैं।

देवनागरी को लेकर तीन ठोस सावधानियाँ:

1. UTF-8, बिना BOM। BOM वाला axml कुछ पार्सरों में पहले ही अक्षर पर टूटता है।
2. नुक़्ता का सामान्यीकरण। "क़व्वाल", "ज़मज़मा", "फ़िरोज़" जैसे शब्दों में नुक़्ता वाले अक्षर यूनिकोड में दो तरह से बन सकते हैं — पूर्व-संयुक्त कोड-पॉइंट (जैसे U+095B ज़) या आधार अक्षर + U+093C नुक़्ता। दोनों देखने में एक जैसे हैं और बाइट-स्तर पर अलग। एक ही फ़ाइल के भीतर, और एक ही डिलीवरी के सब दस्तावेज़ों में, एक ही रूप चुनिए और उस पर टिके रहिए।
3. XML escaping। मोबाइल कीबोर्ड से आया घुमावदार उद्धरण-चिह्न, और नाम में आया & (जैसे "उस्ताद … & साथी"), बिना escape किए XML को अवैध बना देते हैं। भेजने से पहले axml को किसी भी XML पार्सर से एक बार खोलकर देख लीजिए — यह दस सेकंड का काम है और बहुत महँगी अस्वीकृतियाँ बचाता है।

5.5 data — इंटरलीव्ड PCM

साधारण इंटरलीव्ड सैंपल, बिल्कुल WAV की तरह। data के भीतर कोई चीज़ ऑब्जेक्टों के बारे में कुछ नहीं जानती।

5.6 क्रम, और वह जाल जिसमें सब फँसते हैं

ds64 हमेशा पहले। fmt data से पहले। लेकिन **axml को data के बाद रखा जा सकता है**, और अक्सर रखा भी जाता है — क्योंकि, जैसा BS.2088 कहता है, रिकॉर्डिंग के दौरान "the XML metadata will likely be of an unknown length."

पूँछ में axml वाली फ़ाइल दोषपूर्ण नहीं है। पर जो रीडर केवल शुरुआती कुछ मेगाबाइट स्कैन करता है, वह घोषित कर देगा कि फ़ाइल में ADM है ही नहीं। "मेरी फ़ाइल में मेटाडेटा नहीं आ रही" वाली शिकायतों का एक बड़ा हिस्सा अकेले इसी एक तथ्य से समझाया जा सकता है। यह भी याद रखिए कि हमारी 34 GB वाली फ़ाइल में axml तक पहुँचने के लिए रीडर को 34 गीगाबाइट से आगे जाना पड़ेगा — यानी "फ़ाइल का शुरू का हिस्सा देख लिया" कोई जाँच नहीं है।

6. ADM का ऑब्जेक्ट मॉडल

ITU-R BS.2076 मॉडल को दो हिस्सों में बाँटता है। format भाग "describes the technical nature of the audio so it can be decoded or rendered correctly" और इसे ऑडियो के अस्तित्व में आने से पहले भी लिखा जा सकता है। content भाग "the language of dialogue, the loudness, etc." का वर्णन करता है और सिग्नल आने के बाद ही पूरा हो सकता है। कोई तत्व किस भाग का है, यह जानने से पता चलता है कि दी गई ग़लती प्रोडक्शन के किस चरण में घुसी।

ऊपर से नीचे पदानुक्रम:

• audioProgramme — एक पूरी प्रस्तुति। एक या अधिक audioContent को संदर्भित करता है।
• audioContent — संपादकीय अर्थ वाला घटक: संवाद स्टेम, संगीत स्टेम, कोई भाषा-संस्करण। एक या अधिक audioObject को संदर्भित करता है।
• audioObject — संपादकीय आशय और तकनीकी स्वरूप का जोड़। इसमें प्रारंभ-समय और अवधि होती है, और यह शून्य या अधिक audioPackFormat, शून्य या अधिक नेस्टेड audioObject, और शून्य या अधिक audioTrackUID को संदर्भित करता है। content और essence यहीं मिलते हैं।
• audioPackFormat — साथ चलने वाले चैनलों का समूह: एक 7.1.4 bed, एक स्टीरियो जोड़ी, किसी क्रम का HOA समुच्चय। audioChannelFormat तत्वों को संदर्भित करता है और अन्य पैकों को नेस्ट कर सकता है।
• audioChannelFormat — समय के साथ एक चैनल का व्यवहार। इसमें एक या अधिक audioBlockFormat होते हैं।
• audioBlockFormat — परमाणु। Objects के लिए इसमें स्थिति (azimuth/elevation/distance या कार्तीय X/Y/Z), गेन, आकार, विसरण (diffuseness), और साथ में 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" उन्हें। दोनों रूप वैध हैं। जो validator एक पर अड़ता है, वह दूसरे के बारे में ग़लत है।

ADM एक नेस्टेड दस्तावेज़ नहीं, संदर्भों का ग्राफ़ है — और डिलीवरी की हर गंभीर विफलता उस ग्राफ़ का एक टूटा हुआ किनारा है।

जब कोई संदर्भ लटक जाए तो असल में होता क्या है? एक तय व्यवहार नहीं है, और समस्या यही है। ऐसा रेंडरर जो audioPackFormatIDRef को हल करने चला और वह पैक XML में मिला ही नहीं — वह (क) पार्सिंग रोककर फ़ाइल अस्वीकार कर सकता है; (ख) उस ऑब्जेक्ट को छोड़कर बाक़ी सब रेंडर कर सकता है, जिससे एक मिक्स बनता है जिसमें चुपचाप एक स्टेम ग़ायब है; या (ग) common definitions पर लौट सकता है, वहाँ 0x1000+ की custom रेंज का कोई ID न पाकर उसकी जगह ख़ामोशी भर सकता है। तीनों नतीजों में "फ़ाइल खुल गई"। इनमें से केवल एक सुनने से पकड़ में आता है, और वह भी तभी जब आपको पहले से पता हो कि वहाँ क्या होना चाहिए था। यही वजह है कि ADM QC स्वचालित होना ही चाहिए: इंसानी कान वह अनुपस्थिति नहीं सुन सकता जिसकी उसे उम्मीद ही नहीं दी गई थी।

7. बैठक को ADM में लिख देना

अब सिद्धांत को हमारी 22-ट्रैक फ़ाइल पर उतारिए। एक व्यावहारिक विन्यास इस तरह बनता है:

• audioProgramme — "बड़ा ख़याल, राग यमन — पूरी बैठक"।
• audioContent दो: "मंच" और "स्थल"। यह विभाजन बाद में मददगार होता है, क्योंकि स्थल की सामग्री का स्तर अलग से समायोजित करना पड़ सकता है।
• "स्थल" के नीचे एक audioObject जो एक DirectSpeakers पैक को संदर्भित करता है — 7.1.4 bed, यानी 12 चैनल, ट्रैक 1–12। इसी में हॉल, श्रोता और (खुले स्थल पर) आकाश जाता है।
• "मंच" के नीचे दस audioObject, ट्रैक 13–22, हर एक Objects typeDefinition के साथ:

दो बातें ध्यान देने लायक़ हैं।

पहली: यहाँ लगभग कोई गति नहीं है। कलाकार बैठे हैं और बैठे रहते हैं। इसका सीधा तकनीकी परिणाम यह है कि हर audioChannelFormat में केवल एक audioBlockFormat चाहिए — rtime 00:00:00.00000 से शुरू और duration पूरे प्रोग्राम के बराबर। इससे axml कुछ दसियों किलोबाइट का रह जाता है, जबकि फ़िल्म-मिक्स में वही सैकड़ों मेगाबाइट का हो सकता है। स्थिर दृश्य ADM का सबसे आसान और सबसे भरोसेमंद उपयोग है, और शास्त्रीय रिकॉर्डिंग ठीक यही है।

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

8. रेंडरिंग: BS.2127 से BS.2051 लेआउट तक

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

ITU-R BS.2127 संदर्भ ADM रेंडरर परिभाषित करता है: वह एल्गोरिथ्म जो ADM मेटाडेटा और ऑडियो लेकर किसी BS.2051 लेआउट के लिए स्पीकर सिग्नल निकालता है। इसका खुला-स्रोत भाई-बंद, EBU ADM Renderer (EAR, EBU Tech 3388), वही काम व्यवहार में करता है और वही संख्या दोहराने योग्य ढंग से देता है।

यह समझने के लिए कि "लेआउट" का मतलब क्या है, BS.2051 की परतों वाली संकेत-पद्धति याद रखिए: ऊपरी + मध्य + निचली। System B यानी 0+5+0 में कोई ऊपरी चैनल नहीं है — यह 5.1 है। System D यानी 4+5+0 में मध्य परत के पाँच के ऊपर चार ऊपरी चैनल जुड़ते हैं। System J यानी 4+7+0 में मध्य परत सात हो जाती है। और System H यानी 9+10+3 में तीनों परतें भरी हुई हैं — यह 22.2 है, जिसमें निचली परत के तीन चैनल श्रोता-तल से नीचे हैं।

यही कारण है कि "इसे Atmos में मिक्स कर दो" जैसा वाक्य तकनीकी रूप से अधूरा है। ADM में आप किसी लेआउट में मिक्स नहीं करते; आप दृश्य का वर्णन करते हैं, और लेआउट रेंडर के समय चुना जाता है। यह मानसिक बदलाव उतना ही बड़ा है जितना ट्रैक-आधारित सोच से बस-आधारित सोच में जाना था।

इससे तीन नतीजे निकलते हैं जो अभ्यास बदल देते हैं:

1. एक फ़ाइल, कई सही जवाब। वही 22-ट्रैक फ़ाइल System B (0+5+0), System D (4+5+0) और System J (4+7+0) पर तीन अलग स्पीकर-सिग्नल-सेट देगी, और तीनों वैध हैं। "मिक्स" अब कोई अकेली चीज़ नहीं रही।
2. डाउनमिक्स एक अनुमान नहीं, एक निर्दिष्ट प्रक्रिया है। स्टीरियो कॉन्फ़ॉर्म बनाने के लिए यह मत सोचिए कि "किस चैनल को कहाँ भेजें"; रेंडरर को System A (0+2+0) के लिए चलाइए। नतीजा दोहराया जा सकता है और आप उसे दस्तावेज़ में दर्ज कर सकते हैं।
3. आप बिना इमर्सिव कमरे के भी काम कर सकते हैं। यह इस पूरे दस्तावेज़ की सबसे उपयोगी व्यावहारिक बात है, और उस पर हम अनुभाग 10 में लौटेंगे।

8.1 बाइनॉरल रेंडर: वह जाँच जो हेडफ़ोन पर सचमुच काम करती है

इमर्सिव कमरा न होने पर भी एक चीज़ आप ईमानदारी से सुन सकते हैं: बाइनॉरल रेंडर। यह हेडफ़ोन के लिए बनाया गया दो-चैनल आउटपुट है जिसमें दिशा HRTF के ज़रिए बनी होती है, और यह इन सवालों के लिए पर्याप्त है:

• क्या तबला उस तरफ़ है जिस तरफ़ होना चाहिए, या दाएँ-बाएँ पलट गया है?
• क्या तानपूरा पीछे है या ग़लती से सामने आ गया है?
• क्या कोई ऑब्जेक्ट पूरी तरह ग़ायब है?
• क्या ऊँचाई की परत में कुछ है भी, या वह पूरी तरह ख़ामोश है?

इनमें से हर एक भारी-भरकम, शर्मिंदा करने वाली ग़लती है और हर एक हेडफ़ोन पर पकड़ी जा सकती है। जो चीज़ें बाइनॉरल पर भरोसे से नहीं जाँची जा सकतीं वे हैं: सटीक ऊँचाई-स्थिति, समग्र तानवर्ण (timbre), और इमर्सिव लाउडनेस। इसलिए बाइनॉरल जाँच का सही इस्तेमाल "मिक्स ठीक है" कहना नहीं, बल्कि "दृश्य उलटा नहीं है" सिद्ध करना है — और यह वाक़ई क़ीमती है।

9. BS.1770-5 के तहत इमर्सिव लाउडनेस

यहाँ यह अलग करना ज़रूरी है कि प्रकाशित क्या है और प्रचलित क्या।

9.1 सिफ़ारिश असल में क्या कहती है

ITU-R BS.1770-5 (नवंबर 2023) अभी लागू संस्करण है। BS.1770 के छह संस्करण हैं — -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) और -5 (2023-11)। BS.1770-4 (अक्टूबर 2015) अधिक्रमित (superseded) हो चुका है, हालाँकि आज तैनात अधिकांश मीटर अब भी उसी का हवाला देते हैं। जहाँ भी वर्तमान संस्करण नाम से बताना हो, -5 बताइए।

तंत्र:

• K-वेटिंग दो-चरणीय फ़िल्टर है — पहले एक high-shelf ("head" फ़िल्टर, जो एक कठोर गोले का मॉडल है), फिर एक high-pass (RLB)।
• 1 kHz पर K-वेटिंग वक्र का गेन +0.698 dB है (रैखिक 1.0836)।
• मापन 400 ms के ब्लॉकों पर, 75% ओवरलैप के साथ।
• निरपेक्ष गेट: −70 LUFS से नीचे के ब्लॉक हटा दिए जाते हैं।
• सापेक्ष गेट: यह उन्हीं ब्लॉकों के माध्य से निकाला जाता है जो निरपेक्ष गेट से बच गए, और फिर उस पर −10 LU का ऑफ़सेट लगता है। यह बिना-गेट वाला माध्य नहीं है। यह भेद व्यवहार में इतनी बार ग़लत लिखा जाता है कि इसे दोहराना ज़रूरी है।
• Loudness Range (LRA), EBU Tech 3342, −20 LU का सापेक्ष गेट इस्तेमाल करता है — −10 LU नहीं। LRA के लिए −10 लगाना एक आम इम्प्लीमेंटेशन बग है।
• शॉर्ट-टर्म लाउडनेस 3 सेकंड की खिड़की (EBU Tech 3341); मोमेंटरी 400 ms.
• ट्रू पीक ओवरसैंपल किए गए सिग्नल पर नापा जाता है — BS.1770 के अनुसार कम से कम 4×, और 8× बेहतर। सैंपल पीक ट्रू पीक नहीं है; इंटर-सैंपल पीक सबसे ऊँचे सैंपल-मान से ऊपर जा सकते हैं।

मूल एल्गोरिथ्म में चैनल भार L, R और C के लिए 1.0 (0 dB) और Ls तथा Rs के लिए 1.41 (≈ +1.5 dB) है; LFE को छोड़ दिया जाता है। मूल एल्गोरिथ्म का दायरा "from one to five channels" है। BS.1770-5 अपने अनुबंधों (annexes) में इससे आगे जाता है — BS.2051 की उन्नत ध्वनि-प्रणालियों तक, यानी मनमानी स्थिति वाले लाउडस्पीकर और ऊँचाई-चैनल तक, और ऑब्जेक्ट-आधारित ऑडियो तक, जिसे नापने से पहले रेंडर करना पड़ता है।

इमर्सिव लाउडनेस फ़ाइल का गुण नहीं है; वह एक रेंडर का गुण है — और लक्ष्य-लेआउट बदलते ही संख्या बदल जाती है।

स्टीरियो से यही मूल अंतर है। स्टीरियो मास्टर की एक लाउडनेस होती है। ऑब्जेक्ट-आधारित मास्टर की उतनी होती हैं जितने रेंडर-लक्ष्य हैं। इसलिए कोई भी आँकड़ा बताते समय तीन चीज़ें साथ बतानी चाहिए: कौन-सा लेआउट, कौन-सा रेंडरर, और कौन-सा मीटर संस्करण।

9.2 संगीत के लिए जो प्रकाशित है

चैनल-आधारित स्टीरियो संगीत के लिए Spotify इंटीग्रेटेड लक्ष्य −14 LUFS और ट्रू-पीक छत −1 dBTP प्रकाशित करता है, और −14 LUFS से तेज़ मास्टर के लिए छत −2 dBTP कर देता है। AES TD1008 संगीत के लिए −16 LUFS की सिफ़ारिश करता है; उसका −18 LUFS वाला आँकड़ा वाणी-प्रधान (speech-led) सामग्री पर लागू होता है — समाचार, वार्ता, नाटक। −18 को संगीत का लक्ष्य बताना एक आम और गंभीर ग़लती है। EBU R 128 का −23 LUFS प्रसारण का प्रोग्राम-लक्ष्य है, स्ट्रीमिंग-संगीत का विनिर्देश नहीं।

9.3 जो प्रकाशित नहीं है

कोई भी संगीत स्ट्रीमिंग सेवा इमर्सिव डिलीवरी के लिए इंटीग्रेटेड लाउडनेस लक्ष्य प्रकाशित नहीं करती। फ़ोरम और विक्रेता-प्रशिक्षण सामग्री में आँकड़े ख़ूब घूमते हैं; कुछ प्रशंसनीय हैं और कुछ शायद सही भी। पर उनमें से एक भी प्रकाशित विनिर्देश नहीं है, और यह दस्तावेज़ किसी को विनिर्देश की तरह नहीं दोहराएगा।

स्टीरियो के लिए भी: Apple Music, YouTube Music, Amazon Music, TIDAL और Deezer कोई नॉर्मलाइज़ेशन लक्ष्य प्रकाशित नहीं करते। इन सेवाओं के लिए आमतौर पर उद्धृत आँकड़े (Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15) व्यापक रूप से रिपोर्ट किए गए हैं, पर सेवा द्वारा प्रकाशित नहीं हैं। इन्हें कभी ऐसा विनिर्देश न मानिए जिससे आप गेन-परिवर्तन निकाल सकें।

प्रसारण और सिनेमा संगीत से बेहतर प्रलेखित हैं, क्योंकि प्रसारक प्रकाशित करते हैं। अगर आपको आज एक बचाव-योग्य इमर्सिव लाउडनेस आँकड़ा चाहिए, तो: BS.2127-अनुरूप रेंडर लीजिए, किसी नामित BS.2051 लेआउट पर, BS.1770-5 मीटर से नापिए, और तीनों बातें डिलीवरी नोट में लिख दीजिए।

9.4 मालिकाना प्रणालियों के बारे में

Dolby Atmos, Dolby Laboratories की मालिकाना, लाइसेंस-आधारित तकनीक है, और Sony 360 Reality Audio, MPEG-H पर बनी एक मालिकाना प्रणाली है। इनकी डिलीवरी-आवश्यकताएँ इनके स्वामी तय करते हैं और वे ITU या EBU की समय-सारणी से बँधी नहीं हैं। इस दस्तावेज़ में कुछ भी इनमें से किसी कंपनी की आवश्यकताओं का बयान नहीं है, और किसी संबद्धता, प्रमाणन या समर्थन का दावा नहीं किया जा रहा। जहाँ लाइसेंसदाता ने आवश्यकता प्रकाशित की है, उसका अपना वर्तमान दस्तावेज़ पढ़िए और उसी का हवाला दीजिए।

10. भारतीय स्टूडियो की ईमानदार स्थिति

एक बात सीधे कह देना बेहतर है, क्योंकि इसे न कहना पाठक के साथ बेईमानी होगी।

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

बाक़ी लगभग सब जगह सिर्फ़ स्टीरियो मॉनिटरिंग है। मुंबई, दिल्ली, चेन्नई, कोलकाता या पुणे का स्वतंत्र स्टूडियो, कॉलेज का स्टूडियो, शास्त्रीय रिकॉर्डिंग करने वाला फ़्रीलांस इंजीनियर, घर पर काम करने वाला प्रोड्यूसर — इनमें से किसी के पास 4+7+0 कमरा नहीं है, और निकट भविष्य में होगा भी नहीं। इस दस्तावेज़ का मक़सद आपको स्पीकर बेचना नहीं है।

तो फिर इसका मूल्य क्या है? तीन चीज़ें, और तीनों बिना इमर्सिव कमरे के हासिल की जा सकती हैं:

पहली — सही डिलीवरी। ट्रैक-गिनती, सैंपल दर, बिट डेप्थ, चैनल क्रम, कॉन्फ़ॉर्म — ये सब विनिर्देश से मिलान की चीज़ें हैं, सुनने की नहीं।

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

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

फ़िल्म-स्कोर और शास्त्रीय रिकॉर्डिंग की ज़रूरतें एक जैसी नहीं हैं, और यह बात दोनों तरफ़ के लोगों के काम आती है। फ़िल्म-मिक्स में ऑब्जेक्ट चलते हैं, बहुत सारे होते हैं, और उनका ऑटोमेशन घना होता है — वहाँ axml बड़ा, ब्लॉक-टाइमिंग जटिल, और ds64 की table[] वाली स्थिति यथार्थ बन सकती है। शास्त्रीय बैठक में दृश्य लगभग स्थिर है, ऑब्जेक्ट कम हैं, और axml छोटा — पर फ़ाइल बहुत लंबी और बहुत भारी है, इसलिए दबाव कंटेनर पर पड़ता है, मेटाडेटा पर नहीं। दोनों मामलों में जाँच की सूची वही है; बस उसमें से कौन-सी पंक्ति आपको काटेगी, यह अलग है।

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

11. आम QC विफलताएँ और हर एक की पहचान

11.1 fmt और chna में चैनल-संख्या का अंतर

fmt.nChannels कहता है 22, chna.numTracks कहता है 20। फ़ाइल पहले दो chunk में ही अपने से असहमत है। आम वजह: मेटाडेटा लिखने के बाद ट्रैक-गिनती बदलकर दोबारा बाउंस करना, या ऐसा टूल जिसने ट्रैक हटाए पर chna दोबारा नहीं लिखा।

पहचान: दोनों chunk पार्स कीजिए और दो पूर्णांक तुलना कीजिए। यह पूरी पाइपलाइन की सबसे सस्ती जाँच है और चौंकाने वाले अनुपात में विफलताएँ पकड़ती है। साथ ही देखिए कि chna का हर trackIndex 1 … fmt.nChannels के भीतर हो।

11.2 अनाथ ट्रैक UID

chna में मौजूद ऐसा UID जिसे कोई audioObject संदर्भित नहीं करता, या 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."

11.3 ब्लॉक-टाइमिंग का ग़ायब या अ-एकदिष्ट होना

BS.2076 स्पष्ट है: "When there is more than one audioBlockFormat within an audioChannelFormat … both rtime and duration shall be present." EBU Tech 3392 इसे सन्निकटता (contiguity) के नियम तक कसता है — "rtime + duration of an audioBlockFormat should match the rtime of the following block" — जिसमें ऑब्जेक्ट का पहला ब्लॉक 00:00:00.00000 से शुरू हो, कोई ब्लॉक एक सैंपल से छोटा न हो, और अवधियों का योग मूल audioObject की अवधि से मेल खाए।

पहचान: हर audioChannelFormat के ब्लॉक दस्तावेज़-क्रम में चलिए और rtime[n] + duration[n] == rtime[n+1] की पुष्टि कीजिए। विफलताएँ तीन आकार लेती हैं: अंतराल (रेंडरर का व्यवहार अपरिभाषित — कोई पिछली स्थिति पकड़े रहता है, कोई म्यूट कर देता है), अतिव्यापन (ब्लॉक आपस में लड़ते हुए), और क्रम-भंग (ऑटोमेशन जो बीच प्रोग्राम में पीछे कूद जाती है)। स्थिर मंच वाली रिकॉर्डिंग में ये तीनों दुर्लभ होने चाहिए — और अगर दिखें, तो यह लगभग हमेशा टूल का बग है, आपका निर्णय नहीं।

11.4 ग़लत सैंपल दर या बिट डेप्थ

audioTrackUID में sampleRate और bitDepth गुण हो सकते हैं। जब वे fmt से टकराते हैं तो एक ही essence के बारे में दो दावे हो जाते हैं। EBU Tech 3392 का रुख़ है कि ये "Should be ignored if available from the audio essence" — पर हर रेंडरर इस मार्गदर्शन का पालन नहीं करता, और जो फ़ाइल एक जगह 48 000 और दूसरी जगह 96 000 कहती है, उसे अलग-अलग टूल अलग-अलग समझेंगे। अलग से यह भी पक्का कीजिए कि दर वही है जो डिलीवरी विनिर्देश माँगता है: ADM लिखने के बाद किया गया सैंपल-रेट रूपांतरण सैंपलों में व्यक्त हर rtime और duration को अमान्य कर देता है।

पहचान: fmt की तुलना XML के हर sampleRate/bitDepth गुण से कीजिए; असहमति को चिह्नित कीजिए भले ही वह सैद्धांतिक रूप से सह्य हो।

11.5 स्टीरियो या बाइनॉरल कॉन्फ़ॉर्म का ग़ायब होना, या खिसक जाना

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

पहचान: अवधियों की सैंपल-दर-सैंपल तुलना, bext से प्रारंभ टाइमकोड की तुलना, और मास्टर के null रेंडर के विरुद्ध कॉन्फ़ॉर्म का सह-संबंध (cross-correlation)। जो कॉन्फ़ॉर्म वर्तमान मास्टर से सीधे व्युत्पन्न नहीं है उसे संदिग्ध मानिए और दोबारा जाँचने के बजाय दोबारा रेंडर कीजिए।

11.6 ऐसा bed जो मेटाडेटा में है, फ़ाइल में नहीं

XML 7.1.4 DirectSpeakers पैक घोषित करता है — बारह चैनल — पर छपा केवल 5.1 उपसमुच्चय, या ऊँचाई के चैनल बाउंस के समय म्यूट थे और डिजिटल ब्लैक के रूप में छप गए। संदर्भ-ग्राफ़ पूरी तरह ठीक है; ऑडियो नहीं है।

पहचान: ढाँचागत जाँचें इसे नहीं पकड़तीं। इसके लिए essence का विश्लेषण चाहिए: DirectSpeakers पैक द्वारा दावा किए गए हर चैनल में सिग्नल है या नहीं, यह नापिए। घोषित bed चैनल पर डिजिटल ब्लैक अपने आप ग़लती नहीं है — एक वैध मिक्स ऊपरी-पिछला चैनल ख़ाली छोड़ सकता है, और खुले आँगन की रिकॉर्डिंग में यह सचमुच होता है — पर यह हमेशा इंसानी फ़ैसले के लायक़ है।

कंटेनर पूरी तरह वैध हो सकता है, XML पूरी तरह सुगठित, और डिलीवरेबल फिर भी ग़लत; ख़ाली bed चैनल की इकलौती जाँच सैंपल देखना है।

12. डिलीवरी चेकलिस्ट

क्रम से चलिए। ढाँचागत जाँचें पहले — वे तेज़ हैं और उनके फेल होते ही आगे की हर चीज़ अर्थहीन हो जाती है।

कंटेनर

1. पहले चार बाइट BW64 हैं। अगर RIFF हैं तो यह साधारण WAV है और 4 GB से आगे नहीं जा सकता।
2. ds64 हस्ताक्षर के बाद पहला chunk है, और उसके 64-बिट आकार डिस्क पर फ़ाइल तथा data के वास्तविक आकारों से मेल खाते हैं।
3. data के अलावा कोई बड़ा chunk हो तो उसकी ChunkSize64 प्रविष्टि ds64 की तालिका में मौजूद है।
4. axml को स्पष्ट रूप से खोजिए, data के बाद भी। अधूरे स्कैन से "ADM नहीं है" का निष्कर्ष मत निकालिए।

Essence

1. fmt की सैंपल दर और बिट डेप्थ डिलीवरी विनिर्देश से ठीक-ठीक मेल खाती हैं। ADM लिखने के बाद कोई SRC नहीं।
2. fmt.nChannels = chna.numTracks।
3. chna का हर trackIndex सीमा के भीतर है और 1 से शुरू होता है।

chna की अखंडता

1. हर प्रविष्टि ठीक 40 बाइट की है, हर फ़ील्ड सही चौड़ाई में padded है।
2. 0x1000 या उससे ऊपर का हर packRef axml में मौजूद किसी custom परिभाषा से हल होता है।
3. दोहराए गए trackIndex जान-बूझकर हैं (ट्रैक ने वैध रूप से परिभाषा बदली), डुप्लिकेशन की ग़लती नहीं।
4. UID, trackRef और packRef शुद्ध ASCII हैं — कोई देवनागरी, कोई नुक़्ता, कोई खाली जगह नहीं।

ADM ग्राफ़

1. हर audioContentIDRef, audioObjectIDRef, audioPackFormatIDRef, audioChannelFormatIDRef और audioTrackUIDRef हल होता है। एक भी लटका किनारा नहीं।
2. दोनों दिशाओं में कोई अनाथ audioTrackUID नहीं।
3. कोई चक्रीय या स्वयं-संदर्भी तत्व नहीं।
4. हर audioChannelFormat का typeLabel उसके मूल audioPackFormat से मेल खाता है।
5. axml UTF-8 है, बिना BOM, और किसी XML पार्सर से बिना त्रुटि खुलता है। नुक़्ता का रूप पूरे दस्तावेज़ में एक-सा है।

टाइमिंग

1. बहु-ब्लॉक चैनल फ़ॉर्मैट के हर ब्लॉक पर rtime और duration दोनों मौजूद हैं।
2. ब्लॉक सन्निकट और एकदिष्ट हैं; अवधियों का योग मूल audioObject की अवधि के बराबर है।
3. ऑब्जेक्ट 00:00:00.00000 से शुरू होते हैं।

सामग्री

1. घोषित bed का हर चैनल वही ढो रहा है जो उसे ढोना चाहिए; डिजिटल ब्लैक की जाँच कीजिए।
2. ऑब्जेक्ट की संख्या और bed का विन्यास डिलीवरी विनिर्देश से मेल खाते हैं।
3. bext का प्रारंभ टाइमकोड सही है और सेट की सब फ़ाइलों में एक-सा है।

रेंडर और कॉन्फ़ॉर्म

1. स्टीरियो और बाइनॉरल कॉन्फ़ॉर्म वर्तमान मास्टर से दोबारा रेंडर किए गए हैं, पुराने आगे नहीं बढ़ाए गए।
2. अवधियाँ और प्रारंभ टाइमकोड मास्टर से सैंपल-दर-सैंपल मेल खाते हैं।
3. लाउडनेस एक नामित लेआउट पर, नामित रेंडरर से बने नामित रेंडर पर नापी गई, और तीनों बातें डिलीवरी नोट में दर्ज हैं।

पुनरुत्पादनीयता

1. हर डिलीवरेबल का चेकसम लीजिए और मैनिफ़ेस्ट रखिए।
2. सेशन और ADM XML को BW64 से अलग संग्रहित कीजिए; जिस XML का आप diff ले सकते हैं वह बाद में उस बाइनरी से ज़्यादा क़ीमती है जिसे आप केवल दोबारा पार्स कर सकते हैं।

इमर्सिव डिलीवरेबल तब पूरा नहीं होता जब वह सही सुनाई देने लगे; वह तब पूरा होता है जब एक ऐसी मशीन जिसने उसे कभी सुना ही नहीं, यह सिद्ध कर सके कि उसके सारे संदर्भ हल होते हैं।

13. समापन

BW64 और ADM खुले, प्रकाशित और मुफ़्त पढ़े जा सकने वाले मानक हैं। इस उद्योग के इस कोने में यह असामान्य है और इसका फ़ायदा उठाना चाहिए: आप BS.2088 और BS.2076 ख़ुद पढ़ सकते हैं, चालीस पंक्तियों के कोड से chna chunk पार्स कर सकते हैं, और यह जाँच सकते हैं कि किसी विक्रेता के एक्सपोर्टर ने असल में क्या लिखा — न कि वह जो उसके डायलॉग बॉक्स ने दावा किया था।

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

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

स्रोत

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.2076-2 (10/2019), 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 (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
• 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/

अंतिम समीक्षा: सितंबर 2026। मानक संशोधित होते रहते हैं; किसी खंड-संख्या का हवाला देने से पहले ऊपर दिए ITU और EBU पृष्ठों पर वर्तमान संस्करण हमेशा जाँच लीजिए।