कोई इमर्सिव मास्टर वेवफ़ॉर्म एडिटर में पास और 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।

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

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

BW64 एक 32-बिट संख्या की वजह से मौजूद है

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

48 kHz / 24-bit स्टीरियो के लिए डेटा दर 288,000 बाइट प्रति सेकंड है, यानी 4 GB लगभग 4 घंटे 8 मिनट। बेमानी। 96 kHz / 24-bit पर 128-ट्रैक ऑब्जेक्ट-आधारित मास्टर के लिए दर 36,864,000 बाइट प्रति सेकंड है, और 4 GB दो मिनट से भी कम — 116.5 सेकंड।

इमर्सिव मास्टर यह सीमा आए दिन पार करते हैं, और जो 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-बिट साइज़ फ़ील्ड एस्केप फ़्लैग बन जाते हैं: "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-बिट साइज़ एक ds64 चंक में रखता है, जिसे फ़ाइल में सबसे पहले बैठना चाहिए। इसलिए 4 GB से छोटी BW64 फ़ाइल चार-वर्णी हस्ताक्षर को छोड़कर हर लिहाज़ से किसी WAV रीडर के लिए बाइट-संगत है। बहुत सारे टूल उसे स्वीकार कर लेते हैं; कुछ ज़िद करके नहीं करते।

चंक, और वह जो हर प्रविष्टि पर ठीक 40 बाइट का है

BS.2088 के अनुसार BW64 फ़ाइल में कम से कम ds64, fmt , chna, axml (वैकल्पिक मेटाडेटा वाहकों के रूप में bxml और sxml) और वेव डेटा होने की अपेक्षा है।

ds64 हस्ताक्षर के बाद पहला चंक होना चाहिए, क्योंकि किसी और चीज़ पर चलने से पहले रीडर को असली साइज़ पता होने चाहिए। यह पूरी फ़ाइल के साइज़ और data साइज़ के लिए 32-बिट निचले/ऊपरी हिस्से रखता है, साथ ही किसी भी अन्य बड़े आकार के चंक के लिए 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 पत्ता है और वही अकेला तत्व है जो किसी भौतिक ट्रैक से मेल खाता है।

यह रेफ़रेंस का ग्राफ़ है, नेस्टेड दस्तावेज़ नहीं, और हर गंभीर डिलीवरी ख़राबी उसमें एक टूटी हुई कड़ी है। लटके हुए रेफ़रेंस को ख़तरनाक यह बात बनाती है कि कड़ी टूटने पर कोई एक तय व्यवहार नहीं होता। ऐसा audioPackFormatIDRef सुलझाता रेंडरर जो XML में ग़ैरहाज़िर किसी पैक का नाम लेता है, पार्स रोककर फ़ाइल रिजेक्ट कर सकता है; उस ऑब्जेक्ट को छोड़कर बाक़ी सब रेंडर कर सकता है और चुपचाप एक स्टेम से ख़ाली मिक्स बना सकता है; या सामान्य परिभाषाओं पर लौट सकता है, 0x1000 से ऊपर की कस्टम रेंज में बेमेल ID पाकर उसकी जगह ख़ामोशी रख सकता है। तीनों नतीजे "फ़ाइल खुल गई" हैं। सुनकर सिर्फ़ एक पकड़ में आता है, और वह भी तभी जब आपको पता हो कि वहाँ क्या होना चाहिए था।

चार ख़राबियाँ जो ज़्यादातर रिजेक्शन की वजह हैं

fmt की ट्रैक गिनती जो chna से मेल न खाए। fmt .nChannels कहता है 16; chna.numTracks कहता है 14। फ़ाइल पहले दो चंक से ही आंतरिक रूप से असंगत है — आमतौर पर या तो ऐसा बाउंस जिसमें मेटाडेटा लिखे जाने के बाद ट्रैक गिनती बदल गई, या ऐसा टूल जिसने chna दोबारा लिखे बिना ट्रैक हटा दिए। पकड़ने का तरीक़ा है दो पूर्णांक पार्स करके उनकी तुलना करना: पाइपलाइन की सबसे सस्ती जाँच, और यह चौंकाने वाले अनुपात में ख़राबियाँ पकड़ती है। साथ ही यह भी जाँचिए कि हर trackIndex 1 … fmt .nChannels के भीतर हो।

ऐसा audioTrackUID जिसका रेफ़रेंस कोई ऑब्जेक्ट न देता हो। chna में मौजूद ऐसा UID जिसका रेफ़रेंस कोई audioObject नहीं देता, इसका मतलब है ऐसा ऑडियो मौजूद है जिसे कोई रेंडर नहीं करेगा; और उल्टा मामला — XML में ऐसा audioTrackUIDRef जिसकी कोई chna प्रविष्टि नहीं — इसका मतलब है मेटाडेटा ऐसे ट्रैक की उम्मीद कर रहा है जो है ही नहीं। chna से UID का सेट और axml से UID का सेट बनाइए और उनका सममित अंतर लीजिए; वह ख़ाली होना चाहिए। 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 (नवंबर 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-बिट साइज़ डिस्क पर फ़ाइल और 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 चंक पार्स कर सकते हैं, और यह जाँच सकते हैं कि किसी वेंडर के एक्सपोर्टर ने असल में लिखा क्या — न कि उसके डायलॉग बॉक्स ने दावा क्या किया। लगभग सारे ग़ैरज़रूरी इमर्सिव रिजेक्शन रेफ़रेंस-इंटीग्रिटी की ग़लतियाँ हैं, जिन्हें कोई वैलिडेटर एक सेकंड से कम में पकड़ लेता है।

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

स्रोत

ITU-R Recommendations

• 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 (and supplements), 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 reference implementation — 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/