आपका मीटर आपकी पीक के बारे में झूठ बोल रहा है, और वजह गणित है

जिस फ़ाइल का सबसे ऊँचा सैंपल 0.0 dBFS दिखाता है, वह ऐसी फ़ाइल नहीं है जिसका सिग्नल 0 dB तक पहुँचता है। किन्हीं दो सैंपल के बीच पुनर्रचित वेवफ़ॉर्म दोनों से ऊपर उठ सकता है, और सैंपल-पीक मीटर ढाँचागत रूप से उसे देख ही नहीं सकता। फिर एक लॉसी कोडेक — वही चीज़ जो हर स्ट्रीमिंग सेवा किसी के सुनने से पहले आपके मास्टर पर लगाती है — उन उछालों को और ऊपर धकेल देता है। नतीजा वह मास्टर है जो आपके DAW में साफ़ नापा गया और प्लेबैक पर विकृत होता है, और इसमें कुछ भी राय का मामला नहीं है। यह इस बात का नतीजा है कि सैंपल किया गया ऑडियो पुनर्रचित कैसे होता है।

यह लेख बताता है कि सैंपल पीक और ट्रू पीक असल में हैं क्या, दूसरी को नापने का इकलौता रास्ता ओवरसैंपलिंग क्यों है, 4× मीटर क्या देख सकता है और क्या नहीं, और तीन मानकीकृत लाउडनेस मीटरों में कौन किस सवाल का जवाब देता है। हर सेवा टारगेट के रूप में क्या प्रकाशित करती है, और धीमे मास्टर के साथ क्या होता है, यह अलग से आपके मास्टर के साथ असल में क्या होता है में देखा जा सकता है।

सैंपल पीक फ़ाइल का सबसे ऊँचा बिंदु है। ट्रू पीक फ़ाइल में है ही नहीं।

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

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

इसीलिए "कुछ भी क्लिप नहीं हुआ" और "कुछ भी क्लिप नहीं करेगा" दो अलग दावे हैं। ऐसी डिजिटल रूप से सुरक्षित फ़ाइल जिसके सैंपल −0.1 dBFS पर रुकते हैं, उसकी ट्रू पीक 0 dBTP से काफ़ी ऊपर हो सकती है। फ़ाइल में कुछ भी सीमा से बाहर नहीं है। आगे की हर वह चीज़ जो वेवफ़ॉर्म को पुनर्रचित करती है — कोई DAC, कोई सैंपल-रेट कन्वर्टर, कोई लॉसी डिकोडर — उसे क्लिप कर सकती है।

व्यावहारिक कसौटी दो-टूक है: जिस मीटर में स्पष्ट ट्रू-पीक या dBTP मोड नहीं है, वह सैंपल-पीक मीटर है, चाहे उसकी मैनुअल कुछ भी इशारा करे। इसमें DAW में बने ज़्यादातर लेवल मीटर आते हैं, और बहुत सारे लिमिटर का सीलिंग नियंत्रण भी।

लॉसी एनकोडिंग इसे तटस्थ नहीं, और बदतर क्यों बनाती है

स्ट्रीमिंग आपकी WAV नहीं पहुँचाती। वह उसकी AAC, Ogg Vorbis या MP3 एनकोडिंग पहुँचाती है, और लॉसी कोडेक आपके वेवफ़ॉर्म को सैंपल-दर-सैंपल दोबारा नहीं बनाता। वह उसके जैसा प्रतीत होने वाला एक वेवफ़ॉर्म बनाता है। डिकोडर का आउटपुट एनकोडर के इनपुट से नियमित रूप से आगे निकल जाता है।

वह आगे निकलना किसी ख़ास एनकोडर का बग नहीं है। यह स्पेक्ट्रल विवरण को क्वांटाइज़ करने और छोड़ने का अपरिहार्य नतीजा है, और — मास्टरिंग के फ़ैसलों के लिए यही हिस्सा मायने रखता है — यह इस बात के साथ बढ़ता है कि स्रोत को कितनी सख़्ती से लिमिट किया गया था। आपने सिग्नल को सीलिंग से जितने ज़ोर से चपटा किया, कोडेक वापस निकलते वक़्त उतना ही ज़्यादा उछाल पैदा करेगा।

तो ठीक 0.0 dBTP पर बैठा मास्टर 0 dBFS से ऊपर की पीक के साथ डिकोड होता है, और डिकोडर उन्हें क्लिप कर देता है। यह आप अपनी फ़ाइल पर कभी नहीं सुनते। आप इसे उस वर्ज़न पर सुनते हैं जो श्रोता को मिलता है।

इस पर बात करने वाला हर प्रकाशित विनिर्देश एक ही निष्कर्ष पर पहुँचता है। AES TD1008 कहता है: "For all content, it is recommended that the Maximum True Peak level not exceed −1 dBTP at the codec input of lossy-encoded streams." Spotify आपसे ट्रू पीक "below −1dB TP (True Peak) max" रखने को कहता है, और −14 LUFS से तेज़ मास्टर के लिए "keep True Peak below −2dB to avoid extra distortion."

Spotify का दूसरा आँकड़ा ही दिलचस्प वाला है। वह ठीक इसलिए मौजूद है कि ज़्यादा सख़्ती से लिमिट की गई सामग्री कोडेक में ज़्यादा उछलती है। सीलिंग कोई जमी हुई अंधविश्वासी संख्या नहीं है; सामग्री जितनी सघन होती जाती है, वह उतनी ही कसती जाती है।

ओवरसैंपलिंग कर क्या रही है, और 4× क्या नहीं देख सकता

ऐसी पीक नापने के लिए जो फ़ाइल में है ही नहीं, आपको सैंपलों के बीच का वेवफ़ॉर्म पुनर्रचित करना पड़ता है। ITU-R BS.1770 इसे ओवरसैंपलिंग से करने को कहता है — अतिरिक्त सैंपल बिंदुओं का प्रक्षेप करके फिर उस सघन सिग्नल की पीक नापना।

यह अनुशंसा 48 kHz पर न्यूनतम 4× ओवरसैंपलिंग तय करती है, और यह भी बताती है कि "Higher sampling rates and over-sampling ratios are preferred."

इसे जैसा लिखा है वैसा ही पढ़िए। 4× अनुरूपता की फ़र्श है, सटीक जवाब नहीं। 4× मीटर सैंपल-पीक मीटर से ज़्यादा पकड़ने की गारंटी देता है, सब कुछ पकड़ने की नहीं; 4× पर मापन असली पीक को अब भी dB के कुछ दसवें हिस्से तक कम पढ़ सकता है। वे दसवें हिस्से ठीक उतने ही बड़े हैं जितना मार्जिन लोग सीलिंग से छीलने की कोशिश करते हैं।

अगर आपका मीटर 8× या 16× ओवरसैंपलिंग देता है तो उसे इस्तेमाल कीजिए। अतिरिक्त CPU लागत मामूली है और अतिरिक्त सटीकता मामूली नहीं।

लिमिटर की तरफ़ एक साथी जाल भी है। −1.0 dBTP पर सेट की गई ट्रू-पीक सीलिंग का मतलब तभी है जब लिमिटर सचमुच ट्रू-पीक लिमिटिंग कर रहा हो। बहुत सारे लिमिटर के सीलिंग नियंत्रण सैंपल-पीक हैं, और उन्हें −1.0 पर सेट करने से आपको −0.5 dBTP से कहीं ऊपर इंटर-सैंपल पीक मिलती हैं — कोडेक के फ़ाइल छूने से पहले ही आपका आधा मार्जिन ग़ायब।

आपका मीटर मानक के किस संस्करण का हवाला दे रहा है

BS.1770 के छह संस्करण हैं: 2006, 2007, 2011, 2012, 2015 और 2023। BS.1770-4 (अक्तूबर 2015) वह संस्करण है जिसका हवाला तैनात ज़्यादातर मीटर देते हैं; BS.1770-5 (नवंबर 2023) वह संस्करण है जो इस समय लागू है। यहाँ बताई गई 4× ओवरसैंपलिंग की फ़र्श, फ़िल्टर चरण और दोनों गेट, प्रकाशित BS.1770-5 के सामने सत्यापित हैं।

यह जानना मुख्यतः इसलिए ज़रूरी है कि आप अपने मीटर का दस्तावेज़ीकरण सही ढंग से पढ़ें। -4 का हवाला देता मीटर इस वजह से ग़लत नहीं हो जाता, लेकिन -5 मौजूदा पाठ है और किसी दावे को किसी दस्तावेज़ के सामने जाँचते समय नाम उसी का लेना चाहिए।

मोमेंटरी, शॉर्ट-टर्म, इंटीग्रेटेड: तीन मीटर, तीन सवाल

समस्या का दूसरा आधा यह है कि ज़्यादातर लोग जो फ़ैसला ले रहे होते हैं उसके लिए ग़लत लाउडनेस मीटर पढ़ते हैं। EBU Tech 3341 तीन विंडो परिभाषित करता है, और वे सचमुच तीन अलग सवालों के जवाब देती हैं।

मोमेंटरी (M) — 400 ms, अनगेटेड। वही विंडो जो BS.1770 का गेटिंग ब्लॉक है। मोमेंटरी लाउडनेस अलग-अलग घटनाओं का पीछा करती है: कोई स्नेयर, कोई गायन-व्यंजन, कोई डाउनबीट। इसे चीज़ें पकड़ने के लिए इस्तेमाल कीजिए — ऐसा किक जो आसपास की हर चीज़ से 6 LU ऊपर उछले, कोई हिस्सा जो बाहर निकल आए। स्तर के फ़ैसले लेने के लिए इसका इस्तेमाल मत कीजिए। यह कहीं ज़्यादा चंचल है, और मोमेंटरी मीटर के पीछे भागने से ठीक वही ओवर-कंप्रेस्ड नतीजा बनता है जिसे प्लेबैक नॉर्मलाइज़ेशन दंडित करता है।

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

इंटीग्रेटेड (I) — पूरा प्रोग्राम, दोहरा गेटेड। यही वह आँकड़ा है जिसके सामने सेवाएँ नॉर्मलाइज़ करती हैं और अकेला ऐसा जो किसी डिलीवरी स्पेक में आना चाहिए। यह पूरे ट्रैक पर, पहले सैंपल से आख़िरी तक नापा जाता है, किसी चुने हुए हिस्से पर नहीं। इंटीग्रेटेड लाउडनेस एक डिलीवरी विनिर्देश है, मिक्सिंग का औज़ार नहीं; अगर आप काम करते हुए इसे देख रहे हैं, तो आप ग़लत मीटर देख रहे हैं।

इससे निकलने वाला नियम: शॉर्ट-टर्म से मिक्स और मास्टर कीजिए, इंटीग्रेटेड से सत्यापित कीजिए, और विसंगतियों की जाँच मोमेंटरी से कीजिए।

यह असल में जो ग़लती कराता है

आम ग़लती यह है कि मास्टरिंग करते हुए इंटीग्रेटेड लाउडनेस देखी जाए और तब तक लिमिटिंग बढ़ाई जाए जब तक वह उस आँकड़े पर न पहुँच जाए जो किसी ने आपको बताया था। उस बर्ताव में दो अलग ख़राबियाँ एक के ऊपर एक चढ़ी हुई हैं।

पहली यह कि इंटीग्रेटेड लाउडनेस दोहरी गेटेड है, और गेटिंग का मतलब है कि वह वह नहीं नाप रही जो लोग मान लेते हैं। −70 LKFS से नीचे के ब्लॉक सीधे हटा दिए जाते हैं। फिर बचे हुए ब्लॉकों का औसत निकाला जाता है, उसमें से 10 घटाया जाता है, और उस सापेक्ष सीमा से नीचे का हर ब्लॉक भी हटा दिया जाता है। रिलेटिव गेट एब्सोल्यूट-गेटेड औसत से 10 LU नीचे बैठता है, पूरी फ़ाइल के अनगेटेड औसत से 10 LU नीचे नहीं। आपके काम करने वाले सेशन पर इसका सीधा नतीजा है: आपके ट्रैक की इंटीग्रेटेड लाउडनेस असल में उसके तेज़ हिस्सों की औसत लाउडनेस है, पूरे ट्रैक की नहीं। फुसफुसाहट भरे 40 सेकंड के इंट्रो और दीवार जैसी आवाज़ वाले कोरस वाला गाना लगभग पूरी तरह अपने कोरस पर नापा जाता है। तैयार मास्टर में धीमा इंट्रो जोड़ने से इंटीग्रेटेड पाठ मुश्किल से हिलता है, और जो इंजीनियर उससे हिलने की उम्मीद करते हैं वे चौंकते हैं।

दूसरी ख़राबी यह है कि लाउडनेस रेंज एक और अलग गेट इस्तेमाल करती है। LRA, जो EBU Tech 3342 में परिभाषित है, शॉर्ट-टर्म लाउडनेस वितरण के 10वें और 95वें प्रतिशतक के अनुमानों का अंतर है, और Tech 3342 उसकी सापेक्ष सीमा एब्सोल्यूट-गेटेड लाउडनेस स्तर से −20 LU नीचे रखता है, −10 LU नहीं। चौड़ा गेट जानबूझकर है — LRA विविधता का चरित्र बता रही है, इसलिए उसे उन धीमे हिस्सों को भीतर लेना ही होगा जिन्हें बाहर रखने के लिए इंटीग्रेटेड मापन बनाया गया है। जो मीटर LRA के लिए इंटीग्रेटेड वाला −10 LU गेट दोबारा इस्तेमाल करते हैं, वे व्यवस्थित रूप से बहुत छोटे मान बताते हैं। अगर आपका मीटर उसी फ़ाइल पर किसी दूसरे मीटर से साफ़ तौर पर कम LRA बताए, तो शक कीजिए कि वहाँ −20 LU की जगह −10 LU का गेट लगा है।

इसे आप चंद मिनटों में जाँच सकते हैं। ट्रैक के मुख्य हिस्से से 15 LU नीचे की 20 सेकंड सामग्री जोड़ दीजिए। सही इम्प्लीमेंटेशन का LRA काफ़ी बढ़ जाएगा। टूटा हुआ मुश्किल से हिलेगा।

असल में डिलीवर क्या करें

मार्गदर्शन छोटा है, और इसका हर आँकड़ा प्रकाशित है।

1. सीलिंग पहले तय कीजिए: −1.0 dBTP, ट्रू-पीक, ओवरसैंपल्ड। इस सूची में सचमुच कठोर बंदिश यही अकेली है। अगर आपका मास्टर −14 LUFS इंटीग्रेटेड से तेज़ है तो −2.0 dBTP इस्तेमाल कीजिए — कसा हुआ आँकड़ा इसलिए है कि ज़्यादा सख़्ती से लिमिट की गई सामग्री कोडेक में ज़्यादा उछलती है।
2. संगीत के लिए मास्टर कीजिए। संतुलन, टोन और डायनैमिक्स ठीक कीजिए, लिमिटर से जितना कम हो सके उतना कम काम लीजिए, और इस चरण में इंटीग्रेटेड मीटर मत देखिए।
3. नतीजा नापिए। आप जिस भी इंटीग्रेटेड लाउडनेस पर पहुँचे हैं, वही आपका उम्मीदवार है। अगर वह मोटे तौर पर −14 और −9 LUFS के बीच बैठती है, तो हर प्रकाशित टारगेट और हर रिपोर्टेड आँकड़ा आपसे कुछ ही LU के भीतर है। −9 LUFS से तेज़ हों, तो पूछिए कि लिमिटिंग से मिला क्या।
4. मास्टरिंग बदलकर समायोजित कीजिए, लिमिटिंग जोड़कर नहीं। मीटर के सही आँकड़ा दिखाने तक लिमिटिंग बढ़ाकर किसी LUFS संख्या को साधना ठीक वही बर्ताव है जिसे बेमानी बनाने के लिए नॉर्मलाइज़ेशन बनाया गया था।

दो चीज़ें जो नहीं करनी हैं। −0.1 dBTP की सीलिंग स्ट्रीमिंग के लिए डिलीवरी की ग़लती है, शैली की पसंद नहीं। और अलग-अलग सेवाओं के लिए अलग-अलग मास्टर मत काटिए — प्रकाशित और रिपोर्टेड टारगेट मोटे तौर पर 2 LU में फैले हैं, किसी आँकड़े पर ठीक-ठीक पहुँचने से सुनाई देने वाला कुछ नहीं बदलता, और समझदार डायनैमिक्स वाला −1 dBTP का एक मास्टर हर जगह सही है।

अगर आप डिलीवर करने से पहले तैयार फ़ाइल जाँचना चाहते हैं, तो मज़ुफ़ा /loudness-checker पर मुफ़्त लाउडनेस और ट्रू-पीक चेकर रखता है। यह पूरी तरह आपके अपने ब्राउज़र में चलता है और कोई ऑडियो अपलोड नहीं करता।

स्रोत

ITU-R BS.1770 — मापन एल्गोरिदम, K-वेटिंग, गेटिंग, ट्रू पीक

• Recommendation ITU-R BS.1770-5 (11/2023), Algorithms to measure audio programme loudness and true-peak audio level (पूर्ण पाठ PDF): https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf
• BS.1770 अनुशंसा पृष्ठ और संस्करण इतिहास (BS.1770-0 से BS.1770-5 तक): https://www.itu.int/rec/R-REC-BS.1770/en

EBU — मीटर विंडो और लाउडनेस रेंज

• EBU Tech 3341, Loudness Metering: EBU Mode metering to supplement EBU R 128 (मोमेंटरी 400 ms, शॉर्ट-टर्म 3 s): https://tech.ebu.ch/publications/tech3341
• EBU Tech 3342, Loudness Range: A measure to supplement EBU R 128 loudness normalisation (−20 LU गेट; 10वाँ/95वाँ प्रतिशतक), PDF: https://tech.ebu.ch/docs/tech/tech3342.pdf

AES — कोडेक इनपुट पर ट्रू-पीक सीलिंग

• AES TD1008.1.21-9, Recommendations for Loudness of Internet Audio Streaming and On-Demand Distribution (कोडेक इनपुट पर −1 dBTP), PDF: https://aes2.org/wp-content/uploads/2024/01/20210924_TD1008_v3.13.pdf
• AES TD1008 दस्तावेज़ पृष्ठ: https://aes.org/technical-council/technical-document-aestd1008/

Spotify — प्रकाशित ट्रू-पीक सीलिंग

• Spotify for Artists, Loudness normalization (−1 dBTP; −14 LUFS से तेज़ मास्टर के लिए −2 dBTP): https://support.spotify.com/us/artists/article/loudness-normalization/