当所谓的响度战争肆虐时，限幅器和音频压缩器在制作人和音频工程师中的受欢迎程度达到了新高。降低音轨的动态范围并非出于艺术目的，而是为了将作品的音量提高到极限，这已成为一种常态。

在响度战争期间，艺术家和制作人以及听众开始抱怨这种无意义的响度竞争，直到事情最终开始改变。试图使音轨比竞争对手更响亮曾经是最重要的目标，而现在赋予音轨适当的动态范围才是目标。尽管在2005年左右的响度高峰之后，音乐中动态范围的重要性经历了一次复兴，但像Spotify、Tidal、YouTube或Apple Music这样的流媒体平台的兴起，以及它们对响度正常化的使用，最终结束了响度的战争。

什么是响度正常化？

流媒体平台希望他们的听众在浏览音乐时有一个流畅和一致的听觉体验--即使他们在不同艺术家、专辑和流派之间不断跳跃。保证流畅的听觉体验的一个关键因素是在连续的曲目中拥有相似的响度，这样听众就不必摆弄音量，而可以简单地享受音乐。

为了实现稳定的流媒体响度，平台对所有上传的曲目应用所谓的响度标准化。他们把比某个参考响度值更大（或更小）的曲目调低（有些平台还调高）。这个值通常是以LUFS（响度单位全量程）为单位，这是一个代表音轨感知响度的标尺。因此，具有相同综合LUFS值（=在整个音轨上测量）的音轨很可能被听众视为具有相同的响度。

规范化做法对音乐制作人意味着什么？

很多制作人认为，他们必须制作每条音轨，以准确地达到流媒体平台的参考响度（例如，Spotify、YouTube、Tidal和Amazon Music的-14 LUFS）。否则，他们的曲目将被平台调低（或调高），这肯定是一件坏事，对吗？(在大多数情况下)

请记住：每条轨道都被规范化为相同的感知响度水平，这意味着在规范化之后，没有一条轨道比另一条更响亮。是的，流媒体服务将把一个响度为-11 LUFS的曲目降低3dB。但这只是一个简单的增益降低，以确保该轨道与所有其他轨道一样响亮。它不会对精心制作的动态范围或轨道的特性产生任何影响。这就像调低播放设备的音量--因此，没有什么可担心的。

但是为什么我们说 "在大多数情况下"？这是因为如果综合响度低于流媒体平台的参考响度，响度规范化可以对您的曲目产生不必要的影响。比方说，一条响度为-18 LUFS的曲目被上传到Spotify。在这种情况下，该曲目将被调高4分贝，使其与所有其他曲目一样响亮。然而，这可能是一个问题，因为将你的原始信号调高4分贝很可能导致获得的信号超过0dBFS--在这种情况下，自动限制器将被应用。其他平台不会将过于安静的音轨调高，但这也是一个问题，因为你的音轨将低于大多数其他音轨的响度水平，这对感知的音轨质量有不利影响。

如果动态范围很好，我为什么要使用动态工具？

动态范围是实现透明度和让你的音轨呼吸。这就是为什么具有精心设计的动态范围的音轨比过度压缩的歌曲听起来更活泼、更有力。同时，没有经过任何动态处理的音轨，由于不同部分的响度差异很大，很快就会崩溃。同样，这些曲目在动态范围有限的播放系统上听起来会很糟糕，如手机、笔记本电脑或小型蓝牙音箱。因此，关键是要找到正确的平衡点，在驯服音轨的峰值和响亮部分的同时让音乐呼吸。

限制通常是音频制作的最后一步，它允许你微调这种平衡。它将动态范围和响度联系起来。

一些流派，如EDM、HipHop或流行音乐，不仅比古典、爵士或演讲等流派更难限制，它们的特点是动态范围更窄。因此，在使用限制器进行微调时，你基本上必须记住所有这些。动态范围、流派和流媒体服务的响度要求。

用数字告诉我！

当准备发布曲目时，有些人倾向于用具体的数值来告诉他们应该怎么做，以确保没有流媒体服务、平台或发布媒介会 "破坏 "他们的曲目。虽然有很多数字和提示，但简单地专注于实现它们往往对你的创作不起作用。和音乐制作中的情况一样，事情很少是一成不变的。这就是为什么我们建议采用以下简单的准则：

• 首先，完全按照你想要的方式混合你的歌曲。

• 当你为了准备出版而达到限制的阶段，并且你的曲目的响度（LUFS）位于参考响度之上时，一切都很好。

• 如果响度低于参考响度，你可能要稍微增加限制器的增益，以提高响度。

• 最后但并非最不重要的是，确保较大真实峰值电平不超过-1 dB（对于安静的歌曲）或-2（对于较响的歌曲），以避免轨道使用有损音频格式编码时的削波问题。

记住：

• 不要试图较大化你的音轨的响度，专注于找到合适的动态范围，并简单地确保你的音轨 "足够响亮"；这意味着响度至少应该达到流媒体平台的参考水平。

• 如果你的音轨比流媒体平台的参考响度大，而且你没有牺牲动态范围来达到这个响度，就没有必要担心。

• 总之，响度正常化是一件好事，因为它鼓励制作人和艺术家使他们的音乐更有活力，减少压缩。

相关产品 Sonible smart:limit 限制器 https://www.prettysound.net/ai-3103.html

Posted in: Study Case