از میان شش سرویس پخش آنلاینی که دربارهٔ نحوهٔ برخوردشان با بلندی بیش از همه بحث میشود، دقیقاً یکی هدف نرمالسازیای منتشر میکند که بشود نقلش کرد. 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 استناد میکنند دنبالش هستند.
- رقم −18 LUFS در TD1008 به محتوای گفتارمحور مربوط است — خبر، گفتوگو، نمایش رادیویی. اعلام −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 معتبر است. BS.1770-4، از اکتبر 2015، منسوخ شده است — هرچند همان ویرایشی است که بیشتر مترهای موجود هنوز به آن استناد میکنند. اگر دفترچهٔ متر شما از -4 نام میبرد، این چیزی دربارهٔ سن دفترچه میگوید، نه دربارهٔ اینکه کدام ویرایش حاکم است. -5 را به عنوان ویرایش جاری نام ببرید.
الگوریتم واقعاً چه میکند، و مترها کجا اشتباه میکنند
مشخصات کوتاه و دقیق است، و چند جزئیاتش آنقدر زیاد غلط پیادهسازی میشود که بهتر است بشناسیدشان.
وزندهی K. یک فیلتر دومرحلهای: یک شلف بالا (فیلتر «head») و پس از آن یک بالاگذر (RLB). گِین منحنی وزندهی K در 1 kHz برابر است با +0.698 dB — یعنی 1.0836 خطی. همین آفست است که باعث میشود اندازهگیری وزندهیشدهٔ یک تُن 1 kHz با سطح بیوزن آن برابر نباشد.
بلوکها. بلندی روی بلوکهای 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 میخواند باز هم میتواند یک رمزگشای افتدار را کلیپ کند. سقفهای −1 dBTP و −2 dBTP در Spotify ارقام پیک واقعی هستند، پس متر پیک نمونه نمیتواند به شما بگوید آنها را رعایت کردهاید یا نه.
| پارامتر | مقدار | خطای رایج |
|---|---|---|
| گیت مطلق | −70 LUFS | — |
| گیت نسبی (یکپارچه) | −10 LU زیر میانگین بلوکهای باقیمانده | از میانگین بیگیت حساب شود |
| گیت LRA | −20 LU | −10 LU از یکپارچه دوباره به کار رود |
| پنجرهٔ لحظهای | 400 ms | — |
| پنجرهٔ کوتاهمدت | 3 s | — |
| بیشنمونهبرداری پیک واقعی | دستکم 4×، بهتر 8× | پیک نمونه به جای پیک واقعی گزارش شود |
نرمالسازی رو به بالا: مشروط، نه بله یا خیر
سرویسها هنگام پخش نرمال میکنند. مستری که بلندتر از هدف باشد به اندازهٔ اختلاف پایین آورده میشود. این بخش محل مناقشه نیست.
مورد مستر آرام جایی است که هر دو پاسخ قاطع غلطاند. صفحهٔ 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 برای یکپارچه، −20 LU برای LRA.
- تعقیب عددی را که هنگام پخش خنثی میشود کنار بگذارید و به جایش هدروومی را حفظ کنید که تعیین میکند گِین رو به بالا به شما میرسد یا نه.
بررسیکنندهٔ بلندی رایگان Mazufa در نشانی /loudness-checker است. تماماً در مرورگر شما اجرا میشود — هیچ صدایی بارگذاری نمیشود — و ارقام منتشرشدهٔ Spotify را به عنوان منتشرشده گزارش میکند و باقی را همانگونه که هست.
منابع
- Spotify, "Loudness normalization" (صفحهٔ پشتیبانی هنرمندان) — هدف −14 LUFS، سقفهای پیک واقعی −1/−2 dBTP، و گزارههای گِین مثبت و 1 dB هدرووم. support.spotify.com/us/artists/article/loudness-normalization/ — read 2026-09-07.
- ITU-R BS.1770 تاریخچهٔ ویرایشها و سازوکار؛ BS.1770-5 (نوامبر 2023) معتبر، BS.1770-4 (اکتبر 2015) منسوخ. itu.int — verified 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/ — تاریخ قرائتی در برگهٔ اطلاعات ما ثبت نشده است.