इमर्सिव मास्टर असल में होता क्या है
यह कोई स्टीरियो फ़ाइल नहीं है जिस पर कोई इफ़ेक्ट लगा हो। यह BW64 कंटेनर में रखी मल्टीचैनल फ़ाइल है — वह लॉन्ग-फ़ॉर्म वेव फ़ॉर्मेट जो ITU-R BS.2088 में परिभाषित है और इसलिए बना कि मूल वेव फ़ॉर्मेट 4 गीगाबाइट से आगे नहीं जा सकता — और इसमें दो अतिरिक्त चंक होते हैं। axml चंक में ITU-R BS.2076 में परिभाषित Audio Definition Model मेटाडेटा XML के रूप में रहता है। chna चंक फ़ाइल के हर ट्रैक को उस मेटाडेटा के एक पहचानकर्ता से जोड़ता है। इन दोनों चंकों के बिना आपके पास एक साधारण मल्टीचैनल वेव फ़ाइल है, और वह इमर्सिव डिलीवरी के रूप में अस्वीकार होगी।
बेड और ऑब्जेक्ट
प्रकाशित रेंडरर अधिकतम 128 इनपुट लेता है। पहले 10 बेड होते हैं — एक तय चैनल लेआउट, आम तौर पर 7.1.2। इनपुट 11 से आगे सब ऑब्जेक्ट हैं: मोनो या स्टीरियो तत्व जो पोज़िशन मेटाडेटा लेकर चलते हैं और किसी स्पीकर से बँधने के बजाय कमरे में घूमते हैं। इससे अधिकतम 118 ऑब्जेक्ट चैनल पाथ बनते हैं। इससे नीचे संगीत के लिए कोई प्रकाशित सीमा नहीं है; संगीत को एक बेड और कुछ दर्जन ऑब्जेक्ट तक रखने की सलाह अभ्यास का प्रचलन है, नियम नहीं।
वे आँकड़े जो सेवाएँ प्रकाशित करती हैं
Apple की ऐसेट गाइड कहती है कि इमर्सिव मास्टर की इंटीग्रेटेड लाउडनेस, ITU-R BS.1770 से नापी गई, −18 से ऊपर नहीं जानी चाहिए, और ट्रू पीक −1 dBTP से ऊपर नहीं जाना चाहिए। वह 48 kHz पर 24-bit लीनियर ऑडियो माँगती है, जो ADM मेटाडेटा के साथ BW64 फ़ाइल के रूप में दिया जाए। साथ ही इमर्सिव संस्करण से सिंक की हुई एक कन्फ़र्म्ड स्टीरियो प्रति भी अनिवार्य है। शब्दों पर ध्यान दीजिए: ये लाउडनेस आँकड़े एक सीमा हैं, नॉर्मलाइज़ेशन का लक्ष्य नहीं, और यह फ़र्क तब मायने रखता है जब आप तय कर रहे हों कि कितना दबाना है।
स्टीरियो मिक्स को अपमिक्स करना अनुमत नहीं है
यही वह हिस्सा है जो लोगों को सबसे ज़्यादा बेचा जाता है और जिससे वे सबसे ज़्यादा चौंकते हैं। Apple का प्रकाशित मार्गदर्शन साफ़ कहता है कि स्टीरियो मिक्स से बनाई गई इमर्सिव फ़ाइलें अनुमत नहीं हैं। इमर्सिव मास्टर मल्टीट्रैक सेशन से, एक इंसान द्वारा, लाइसेंस प्राप्त रेंडरर में बनाया जाता है, और उसमें तय किया जाता है कि क्या बेड में जाएगा और क्या ऑब्जेक्ट बनेगा। जो भी सेवा तैयार स्टीरियो मास्टर को इमर्सिव में बदलने की पेशकश करती है, वह या तो वही कर रही है जो मानक मना करता है, या किसी और चीज़ का वर्णन कर रही है।
असल में ज़्यादातर लोग बाइनॉरल ही क्यों सुनेंगे
बहुत कम श्रोताओं के पास स्पीकर ऐरे होता है। भारी बहुमत इमर्सिव संगीत हेडफ़ोन पर, बाइनॉरल रेंडर के ज़रिए सुनता है। फ़ॉर्मेट हर तत्व के साथ ऐसा मेटाडेटा रखता है जो बताता है कि उस रेंडर में हर ऑब्जेक्ट को कैसे वर्चुअलाइज़ किया जाए — पर उन निर्देशों में से कौन-से बचे रहते हैं, यह डिलीवरी के रास्ते पर निर्भर करता है, और सबसे बड़ी म्यूज़िक सेवा पर हेडफ़ोन रेंडर उस प्लेटफ़ॉर्म का अपना होता है, वह नहीं जिस पर आपने मॉनिटर किया। व्यावहारिक नतीजा: इसे पूरा मानने से पहले असली सेवा के ज़रिए हेडफ़ोन पर अपना मिक्स सुनिए।
यह टूल किस बात का दिखावा नहीं करता
यह फ़ाइल के खुले, प्रकाशित हिस्से पढ़ता है: ITU-R BS.2088 में परिभाषित कंटेनर और ITU-R BS.2076 में परिभाषित मेटाडेटा मॉडल, दोनों सार्वजनिक रूप से उपलब्ध सिफ़ारिशें हैं। यह रेंडर नहीं करता। ऑब्जेक्ट को स्पीकर फ़ीड में बदलने वाला एल्गोरिदम मालिकाना और लाइसेंस वाला है, इसलिए कोई भी ब्राउज़र मानक के अनुरूप रेंडर नहीं बना सकता, और बिना लाइसेंस के अनुमान से निकला लाउडनेस आँकड़ा वैध डिलीवरी माप नहीं होगा। यह उन ब्रॉडकास्ट कोडेकों को भी एन्कोड या डिकोड नहीं करता जिनसे इमर्सिव संगीत ढोया जाता है, क्योंकि वे पेटेंट से सुरक्षित हैं। अपनी सीमा मान लेने वाला वैलिडेटर उस रेंडरर से ज़्यादा काम का है जो अपनी सीमा के बारे में झूठ बोले।
क्या आप उन कंपनियों से जुड़े हैं जिनके फ़ॉर्मेट यह पढ़ता है?
नहीं। फ़ॉर्मेट और कंपनियों के नाम इस पेज पर केवल इसलिए हैं कि उन फ़ाइल फ़ॉर्मेटों और प्रकाशित मानकों की पहचान हो सके जिन्हें यह टूल पढ़ता है। हम उनमें से किसी से संबद्ध नहीं हैं, न हमें उनका समर्थन, प्रमाणन या लाइसेंस प्राप्त है, और हम उनके लोगो या बैज इस्तेमाल नहीं करते। जहाँ हम किसी आँकड़े की उसके स्रोत पर पुष्टि नहीं कर सके, वहाँ टूल यही कहता है, उसे तथ्य की तरह पेश नहीं करता।