"Loading..."

烧坏喇叭?——除了管好右手你还需要一台限幅器

在音响人的菜鸟生涯中,总会遇上至少一次的音箱单元因为各种“合理”和“无理”被烧坏,令菜鸟们郁闷不已?然而对于久经“沙场”而成的老鸟,对于防烧喇叭,除了基础的理论知识耍得出神入化之外,他们还会善用一样“终极”神器——限幅器。今天,小灵就跟你们(就是特指菜鸟们啦)扒一扒这个神奇的“限幅器”。

微信图片_20190316093154


何为“限幅器”?

限幅器(Limiter)是在信号电平达到特定的阈值时对音频信号增益进行限制的一种设备。设计优秀的限幅器会尽可能让声音悦耳,把由挤压信号造成的可闻失真效果最小化。

微信图片_20190316093158


限幅器主要用于限制作用在另一台设备上的信号电平峰值,例如磁带录音机、无线电发射机或音箱。本文仅涉及保护音箱所用的限幅器。


为何使用限幅器?

当你给音箱输入过大信号时,限幅器可以帮助你防止音箱损坏。损坏音箱的方式主要有两种:


撕毁它——单个音频瞬态过度且过快推动音箱锥盆单元,使锥盆遭受永久损伤,从而造成严重的失真——或者更糟的是,彻底损坏。

微信图片_20190316093201


烧掉它——高电平信号持续时间过长,造成音圈过热并烧毁。

微信图片_20190316093203


【瞬态】瞬态是指幅度比其他信号高出很多的短暂信号——信号中的一个“尖峰”。


限幅器的另一个用途是避免号筒负载音箱在其操作范围的一部分频段上工作,因为它在这些频段工作会由于号筒喉管处的紊乱气流而造成严重失真。尽管驱动单元不会因此而遭受永久损伤,但造成的声音效果是人们很不愿意听到的。


关于功率放大器和音箱额定功率

在限幅器设置之前,你需要了解你的音箱和功放的额定功率。这比看上去更复杂,因为所有的音箱制造商并非使用同样的方法测量功率。

微信图片_20190316093205


情况1:你的功放功率太高,使音箱过热

在这种情况下,你需要调整增益结构和功放灵敏度,从而在功放的削波点以下安全使用音箱。如果你将功放调整得过于灵敏,将会承担风险,偶发事故(如掉落话筒或线缆断掉)会把过大信号传送到音箱,并且这样还会造成必须以较低信号电平操作调音台,导致更多噪声。如果将功放调整得过于灵敏,你将无法充分利用全部的功率能量。

微信图片_20190316093207


情况2:你的功放功率太低,使音箱过热

可能很出人意料,功率过低同样也很危险。实际上这甚至可能更加危险,特别是在有着无源分频器的系统中。如果功放没有足够的功率,你很可能会提升电平直到发生削波,这样会产生巨大的高频瞬态,它足以毁坏你的驱动单元。一个典型的例子就是,低音吉他或低音鼓的信号电平过大,造成了功放削波:低频驱动单元没有问题,但是高频信号电平大得足以损坏高音单元。

微信图片_20190316093208


在全面采用有源分频器的系统中,削波现象发生的几率小得多,这是这种系统的一项巨大优势。


那么是否应该让功放从不发生削波?

一些工程师刻意让功率放大器发生削波,为了让超低频音箱输出更大声压级。这种方法是有效的,但是如果你不知道你到底在做什么,这样做极具风险,并且总是会降低音质的。许多超低频音箱的箱体设计会消除产生的额外谐波成分,但要确切预测如何进行消除比较困难,并且经过细致计算而设定好的限幅器阈值和分频器频段增益很可能都会失效。只有你对自己的系统设备很熟悉并拥有丰富的使用经验时,这项技巧才能发挥作用,即便如此也不是总能成功的。

微信图片_20190316093210


非常确定的一点是,除了超低频音箱外,不应该在任何音箱上让功放发生削波——除了可能造成的损坏外,声音实在是太糟糕了!


【声压级】SPL,即声压级,是对声压的度量值,以dB为单位——在空气中的参考声压取为20微帕。


应当如何设置限幅器电平?

现在已经确定你需要限幅器了,那么该如何设置它呢?你的主要控制,通常就只有一个,就是设置阈值。


如果限幅器阈值被设置好之后,当音量升高而限幅器努力工作时,信号电平能刚好处在音箱的过载点以下。要把这个临界值计算出来是很困难的,因此你需要依靠经验或者使用制造商提供的数据,来为特定的功放音箱组合设置阈值。

微信图片_20190316093213


如果使用限幅器来避免号筒喉管失真,你需要认真聆听,将阈值设在你认为失真开始变得不可接受的那个点。一定要尝试不同类型的节目材料。还可以使用一支测量话筒,将信号馈送给失真度分析仪。你可以从较低的限幅器阈值开始,然后向上调直到开始出现失真。


一旦你对限幅器进行了正确设置,功放和音箱就会相对安全而不容易发生过热现象,但是这里有一个隐藏的问题:如果你粗心大意或者太过兴奋,将限幅器调整过度,那么你实际上是把限幅器当作一个粗糙的压缩器来使用了。


Processed in 0.080282 Second , 53 querys.