The Nebula tip of the month (#21 - July 2011)

Nebula tips and tricks
User avatar
Posts: 2861
Joined: Sun Mar 28, 2010 9:00 pm
Location: Lodi | Madrid | Buenos Aires

The Nebula tip of the month (#21 - July 2011)

Post by enriquesilveti » Tue Aug 02, 2011 12:24 pm

Understanding Nebula Compressors I

In software compressors each incoming sample has a gain changement so they are accurate for all audio events including transients. If there is oversampling it will be even more accurate and aliasing will be reduced accordingly.

Nebula works in a different way than other audio tools, which could be better sometimes and worse others. Being the only software with a different approach, you will achieve things in Nebula which are not possible using other software compressors and viceversa.

Nebula processes blocks of samples because it tries to be accurate on frequency and harmonic content and switching kernels too much often will lead to other unwanted effects like ringing noise or fake sounds.

How many blocks of samples? This is the PROG RATE value of the emulation preset shown in KERN page as RTE. The emulation preset rate is a parameter fixed by the library developer.

Fast emulation preset rate means that the compressor will react in a faster way. If a emulation preset is loaded with rate of a single sample you have exactly the speedness of a common software compressor, but you can't have this working correctly in Nebula unless kernels are very short and as result Nebula will add artifacts, noise and aliasing.

Slow emulation preset rate means that compressors will react in a slower way and as result less clipping issues, artifacts, troubles and aliasing but Nebula could start processing sound later, and transient could not be processed correctly (you hear something loud at the beginning because compression is not engaged yet). You loose something but you gain something, which is the sound. When emulation preset rate is slow Nebula can reproduce the whole kernel length that means harmonic distortion and frequency response accuracy.

Nebula has a program rate setting in MAST page (PROG RATE) and all Nebula emulation presets has an emulation preset rate (RTE). No one emulation preset may be set with a value less than Nebula program rate value (PROG RATE) that is 2 milliseconds. When a compressor is loaded with an emulation preset rate with a value more than 2 milliseconds, for example 20 milliseconds, Nebula will be late about 18.5 milliseconds due the look ahead setting and as result the transient could not be processed correctly (you hear something loud at the beginning because compression is not engaged yet).

User can change emulation preset rate, decreasing it up to transient be processed correctly, but remember that the emulation preset rate was set by the developer and lower the value result in less accurate behavior and more standard compressor effect.

If a compressor emulation program is based on RAWFUNS (latest compressor releases) you'll have a different behavior in Nebula2 and Nebula3 (COREI) and Nebula3PRO (COREII) or Nebula3Server (CORE3). The main differences is in COREI due times tare not sampled. If internal mode is RMS 17 you'll have strange attack and release times compared with other software compressors. Latest Nebula (all version) releases support the new mode EVF 17. So Nebula2 and Nebula3 user can tune attack and release times it directly by hand in EVF page (PROG page > EDIT > EVFS).

In conclucion, don't try to convert an horse to a dog. Sometimes the limitation is not hardware specific, but is introduced by Nebula engine. If you don't like the sound try to use a different compressor, even from an other manufacturer, and add Nebula later for the 3d effect, color and sense of spaceness.

Tip 1: When you hear ringing artifacts. In general it happens when the source is rich of low frequencies content, for example a bassline. In most commercial compressor you don't hear it because the envelope follower is measuring an high-passed source. You can emulate it using side chain and an high pass filter before the side chain input.

Tip2: If PROG RATE is big enough, for example 20 milliseconds, and it's based on SMOOTH 2, there are 2 players for H1 in KERN page, you could tune a different algorithm in PROG page > EDIT > GLOBAL > SMOOTH. Selecting a different function for cross fading between kernels switches. It will not affect harmonic distortion, it will not affect frequency response and it will not affect compression. But it will affect aliasing and ringing issues plus compressors could be slightly more responsive simply because each block is merged with next block in a different way.