जब कोई स्ट्रीमिंग सेवा आपके मास्टर को नॉर्मलाइज़ करती है, तब असल में होता क्या है

जिन छह स्ट्रीमिंग सेवाओं की लाउडनेस-व्यवस्था पर सबसे ज़्यादा बात होती है, उनमें से ठीक एक ऐसा नॉर्मलाइज़ेशन टारगेट प्रकाशित करती है जिसे आप उद्धृत कर सकें। Spotify −14 LUFS इंटीग्रेटेड प्रकाशित करता है, ट्रू-पीक सीलिंग −1 dBTP के साथ, जो मास्टर के −14 LUFS से तेज़ होने पर कसकर −2 dBTP हो जाती है। Apple Music, YouTube Music, Amazon Music, TIDAL और Deezer कोई नॉर्मलाइज़ेशन टारगेट प्रकाशित ही नहीं करतीं। इन पाँच के बारे में आपने जो भी आँकड़ा देखा है वह रिपोर्टेड है, प्रकाशित नहीं — और यह फ़र्क़ ठीक उसी क्षण मायने रखने लगता है जब कोई उससे यह हिसाब लगाने लगे कि उसके मास्टर पर कितना गेन रिडक्शन लगेगा।

एकमात्र प्रकाशित स्ट्रीमिंग आँकड़ा

Spotify का अपना लाउडनेस नॉर्मलाइज़ेशन पेज टारगेट को −14 LUFS इंटीग्रेटेड बताता है। वह ट्रू-पीक सीलिंग −1 dBTP बताता है, और −14 LUFS से तेज़ डिलीवर किए गए मास्टर के लिए −2 dBTP। इस लेख में स्ट्रीमिंग सेवा के नॉर्मलाइज़ेशन विनिर्देशों में सिर्फ़ यही तीन आँकड़े हैं जो ख़ुद सेवा से आते हैं।

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

वे पाँच सेवाएँ जो कुछ भी प्रकाशित नहीं करतीं

Apple Music, YouTube Music, Amazon Music, TIDAL और Deezer कोई नॉर्मलाइज़ेशन टारगेट प्रकाशित नहीं करतीं। उनके बारे में जो आँकड़े प्रचलन में हैं, उन्हें कहने का एकमात्र ईमानदार तरीक़ा यही है:

व्यापक रूप से रिपोर्टेड, सेवा द्वारा प्रकाशित नहीं: Apple ≈ −16, YouTube Music ≈ −14, Amazon ≈ −14, TIDAL ≈ −14, Deezer ≈ −15.

इन्हें जानबूझकर अलग रखा गया है, और इनके साथ चलने वाला नियम सख़्त है: इनसे कोई गेन का आँकड़ा मत निकालिए। "मेरा मास्टर −8 पर है, Apple −16 पर है, तो Apple मुझे 8 dB नीचे खींचेगा" — यह ऐसे आँकड़े पर किया गया गणित है जिसकी पुष्टि संबंधित कंपनी ने कभी नहीं की, और वह भी ऐसे एल्गोरिदम से जिसके पैरामीटर की पुष्टि भी उसने कभी नहीं की। घटाव साफ़ है; नतीजा निराधार है।

यह स्रोतों को लेकर बाल की खाल निकालना नहीं है। यही व्यावहारिक वजह है कि लाउडनेस पर इतनी सारी सलाह आपस में उलटी पड़ती है: दो लेखक एक ही सेवा के लिए दो अलग रिपोर्टेड मान उठाते हैं, दोनों घटाव करते हैं, और दोनों एक आत्मविश्वासी आँकड़ा पेश कर देते हैं।

−23, −16, −18: तीन आँकड़े जो आपस में बदले नहीं जा सकते

तीन और आँकड़े ऐसे घूमते हैं मानो वे वैकल्पिक स्ट्रीमिंग टारगेट हों। वे नहीं हैं।

• EBU R 128 −23 LUFS तय करता है। R 128 एक ब्रॉडकास्ट अनुशंसा है। यह स्ट्रीमिंग टारगेट नहीं है और कभी इसका इरादा भी नहीं था। स्ट्रीमिंग डिलीवरी की चर्चा में इसे उद्धृत करना श्रेणी की भूल है, कोई सख़्त मानक नहीं।
• AES TD1008 संगीत के लिए −16 LUFS देता है। जब लोग AES का हवाला देते हैं तो आमतौर पर वे इसी स्ट्रीमिंग-केंद्रित आँकड़े तक पहुँचना चाह रहे होते हैं।
• TD1008 का −18 LUFS वाला आँकड़ा भाषण-प्रधान सामग्री पर लागू होता है — समाचार, टॉक, ड्रामा। −18 को संगीत का टारगेट बताना एक आम और गंभीर ग़लती है। अगर कोई मास्टरिंग गाइड, प्लगइन प्रीसेट या फ़ोरम पोस्ट आपसे कहे कि AES संगीत के लिए −18 LUFS की सिफ़ारिश करता है, तो उस दस्तावेज़ ने भाषण-प्रधान आँकड़े को संगीत के आँकड़े से गड्डमड्ड कर दिया है, और उसकी बाक़ी बातों पर भी आपको भरोसा नहीं करना चाहिए।

−16 / −18 का यह भेद सही रखना यह पहचानने के सबसे तेज़ तरीक़ों में से एक है कि लाउडनेस पर लिखने वाले ने स्रोत पढ़ा है या किसी सारांश की नक़ल की है।

मापन मानक, और कौन-सा संस्करण लागू है

ऊपर सब कुछ ITU-R BS.1770 से मापा जाता है। इसके छह संस्करण हैं: -0 (2006), -1 (2007), -2 (2011), -3 (2012), -4 (2015) और -5 (नवंबर 2023)।

BS.1770-5 लागू है। अक्तूबर 2015 का BS.1770-4 अधिक्रमित हो चुका है — भले ही आज भी तैनात ज़्यादातर मीटर इसी संस्करण का हवाला देते हैं। अगर आपके मीटर की मैनुअल -4 का नाम लेती है, तो यह मैनुअल की उम्र बताता है, यह नहीं कि कौन-सा संस्करण लागू है। मौजूदा के रूप में -5 का नाम लीजिए।

एल्गोरिदम असल में करता क्या है, और मीटर कहाँ ग़लती करते हैं

विनिर्देश छोटा और सटीक है, और उसके कई विवरण इतनी बार ग़लत लागू किए जाते हैं कि आपको उन्हें जानना चाहिए।

K-वेटिंग। दो चरणों वाला फ़िल्टर: एक हाई-शेल्फ़ ("हेड" फ़िल्टर) और उसके बाद एक हाई-पास (RLB)। 1 kHz पर K-वेटिंग कर्व का गेन +0.698 dB है — रैखिक रूप में 1.0836। यही ऑफ़सेट वजह है कि 1 kHz टोन का K-वेटेड मापन उसके अनवेटेड स्तर के बराबर नहीं होता।

ब्लॉक। लाउडनेस 400 ms के ब्लॉकों पर 75% ओवरलैप के साथ निकाली जाती है।

एब्सोल्यूट गेट। −70 LUFS से नीचे के ब्लॉक सीधे हटा दिए जाते हैं।

रिलेटिव गेट — वह जिसे सबसे ज़्यादा बार ग़लत बताया जाता है। रिलेटिव गेट उन ब्लॉकों के औसत से निकाला जाता है जो एब्सोल्यूट गेट से बचे, और फिर उस पर −10 LU का ऑफ़सेट लगाया जाता है। यह अनगेटेड औसत नहीं है। जो मीटर अनगेटेड औसत के सापेक्ष गेट करता है, वह लंबी ख़ामोशियों वाले ट्रैक को उस मीटर से अलग पढ़ेगा जो विनिर्देश का पालन करता है, और दोनों के बीच का अंतर आपकी लाउडनेस के बजाय आपकी अरेंजमेंट पर निर्भर करेगा।

लाउडनेस रेंज। LRA, जो EBU Tech 3342 में परिभाषित है, −20 LU का रिलेटिव गेट इस्तेमाल करता है — −10 LU नहीं। LRA के लिए इंटीग्रेटेड-लाउडनेस वाला गेट दोबारा इस्तेमाल कर लेना एक आम इम्प्लीमेंटेशन बग है, और इससे डायनैमिक सामग्री वास्तव में जितनी है उससे ज़्यादा एकसार दिखने लगती है।

टाइम विंडो। शॉर्ट-टर्म लाउडनेस 3 s की विंडो इस्तेमाल करती है (EBU Tech 3341)। मोमेंटरी 400 ms इस्तेमाल करती है। ये अलग-अलग मापन हैं, एक ही मापन की अलग स्मूदिंग सेटिंग नहीं।

ट्रू पीक। ट्रू पीक ओवरसैंपल्ड सिग्नल पर मापी जाती है — BS.1770 के अंतर्गत न्यूनतम 4×, और 8× बेहतर है। सैंपल पीक ट्रू पीक नहीं है। इंटर-सैंपल पीक फ़ाइल के सबसे ऊँचे सैंपल मान से भी ऊपर जा सकती हैं, इसीलिए वह मास्टर जो सैंपल-पीक मीटर पर ठीक 0.0 dBFS दिखाता है, फिर भी किसी लॉसी डिकोडर पर क्लिप कर सकता है। Spotify की −1 dBTP और −2 dBTP सीलिंग ट्रू-पीक आँकड़े हैं, इसलिए सैंपल-पीक मीटर आपको नहीं बता सकता कि आप उन पर खरे उतरते हैं या नहीं।

अपवर्ड नॉर्मलाइज़ेशन: सशर्त है, हाँ-या-ना नहीं

सेवाएँ प्लेबैक पर नॉर्मलाइज़ करती हैं। टारगेट से तेज़ मास्टर को उतने अंतर से नीचे किया जाता है। इस हिस्से पर कोई विवाद नहीं है।

धीमे मास्टर वाला मामला वह है जहाँ दोनों आत्मविश्वासी जवाब ग़लत हैं। Spotify का पेज कहता है कि "Positive gain is applied to softer masters so the loudness level is -14 dB LUFS." वह यह भी कहता है: "We consider the headroom of the track, and leave 1 dB headroom for lossy encodings to preserve audio quality."

दोनों वाक्यों को साथ पढ़ें तो वे एक शर्त बताते हैं। धीमा मास्टर टारगेट तक उठाया जा सकता है। ऊँची पीक वाला धीमा मास्टर पूरी तरह ऊपर नहीं भी उठाया जा सकता, क्योंकि उसे उठाने से वही हेडरूम ख़र्च हो जाएगा जो दूसरा वाक्य आरक्षित रखता है।

तो:

• "धीमे मास्टर कभी ऊपर नहीं किए जाते" — ग़लत है।
• "धीमे मास्टर हमेशा टारगेट तक ऊपर किए जाते हैं" — यह भी ग़लत है।
• सही यह है: अपवर्ड गेन असली है, और वह ट्रैक के हेडरूम के अधीन लगाया जाता है।

अगर आपको वह अपवर्ड गेन चाहिए, तो लीवर मास्टर में पीक नियंत्रण है — औसत स्तर नहीं। जिस मास्टर में सच में हेडरूम है, वही मास्टर उठाए जाने की गुंजाइश रखता है।

ओवर-लिमिटिंग से असल में मिलता क्या है

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

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

इसका क्या करें

• कुछ भी डिलीवर करने से पहले इंटीग्रेटेड लाउडनेस और ट्रू पीक, ओवरसैंपलिंग के साथ, नापिए।
• अपने मास्टर को −14 LUFS और −1 dBTP के सामने जाँचिए (या −2 dBTP अगर आप −14 LUFS से तेज़ हैं), क्योंकि यही प्रकाशित हैं, और बाक़ी सब को अपुष्ट मानिए।
• अगर कोई टूल, प्लगइन या लेख आपको Apple Music, YouTube Music, Amazon Music, TIDAL या Deezer के लिए प्रति-सेवा टारगेट देता है और उसे प्रकाशित के बजाय रिपोर्टेड बताकर लेबल नहीं करता, तो इसे उस टूल के बारे में एक संकेत मानिए।
• जहाँ आपका मीटर अनुमति दे, वहाँ उसके रिलेटिव गेट और LRA गेट के व्यवहार की पुष्टि कीजिए। इंटीग्रेटेड के लिए −10 LU, LRA के लिए −20 LU।
• ऐसे आँकड़े के पीछे भागना बंद कीजिए जो प्लेबैक पर वैसे भी पलट दिया जाता है, और उस हेडरूम की रक्षा शुरू कीजिए जो तय करता है कि अपवर्ड गेन आप तक पहुँचेगा या नहीं।

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

स्रोत

• Spotify, "Loudness normalization" (आर्टिस्ट सपोर्ट पेज) — टारगेट −14 LUFS, ट्रू-पीक सीलिंग −1/−2 dBTP, और पॉज़िटिव-गेन तथा 1 dB हेडरूम वाले कथन। support.spotify.com/us/artists/article/loudness-normalization/ — पढ़ा गया 2026-09-07.
• ITU-R BS.1770 संस्करण इतिहास और तंत्र; BS.1770-5 (November 2023) लागू, BS.1770-4 (October 2015) अधिक्रमित। itu.int — सत्यापित 2026-09-07.
• EBU R 128 — −23 LUFS, ब्रॉडकास्ट; और EBU Tech 3341 (मोमेंटरी और शॉर्ट-टर्म विंडो) तथा EBU Tech 3342 (लाउडनेस रेंज, −20 LU गेट)। tech.ebu.ch — हमारी फ़ैक्ट शीट में कोई पढ़ने की तारीख़ दर्ज नहीं।
• AES TD1008 — संगीत के लिए −16 LUFS; भाषण-प्रधान सामग्री के लिए −18 LUFS। aes.org/community/technical-council/technical-document-aestd1008/ — हमारी फ़ैक्ट शीट में कोई पढ़ने की तारीख़ दर्ज नहीं।