9 replies to this topic

[Endemoniada]

Hi guys,

How do I properly combine a bunch of sound events (sounds occuring at specific times) without overloading the amplitude ? I'm not doing this in real time.

For example, if two sounds occur at the same time I would conceptually multiply their amplitudes by 0.5 and add them. What happens if a third sound comes in halfway through the first two sounds ?

If I simply add all the amplitudes and then normalize the entire sequence the sounds that are not overlapping and pretty low in volume (amplitude).

To be clear about what I'm doing here is a diagram:

time - filename.wav (duration)

00:00 - boom.wav (6s long)
00:05 - beep.wav (3s long)
00:05 - blip.wav (4s long)
00:07 - bop.wav (2s long)
00:12 - beep.wav (2s long)

...pretty much a sequencer. I want to combine that into a single wav file using my own code (I already know how to read/write wav files.) Sometimes a single sound will be playing, other times there will be multiple sounds overlapping, and others when no sound is playing.

Thanks.

[Cornstalks]

Read this article on mixing audio. [edit: see l0calh05t's post below... I'm not qualified to say what's better (which is why this seemed like a good article with I read it), but I think l0calh05t is right]

Edited by Cornstalks, 26 November 2012 - 09:30 AM.

[l0calh05t]

Read this article on mixing audio.

Don't. The author obviously doesn't have a clue about audio mixing. A + B - AB adds massive distortion because you are adding a ring modulated signal (AB) to your mix. Yes, it prevents clipping but it just distorts differently (and constantly!). I would suggest using a proper brickwall limiter (easy enough to implement). And don't normalize everything...

[Cornstalks]

Read this article on mixing audio.

Don't. The author obviously doesn't have a clue about audio mixing. A + B - AB adds massive distortion because you are adding a ring modulated signal (AB) to your mix. Yes, it prevents clipping but it just distorts differently (and constantly!).

You might be totally right about that, as I'm not overly experienced in this area. Thanks for the heads up.

I would suggest using a proper brickwall limiter (easy enough to implement). And don't normalize everything...

If I'm understanding you right, you're suggesting adding the signals A and B, applying a brick-wall limiter, and then clipping. Right?

[l0calh05t]

If I'm understanding you right, you're suggesting adding the signals A and B, applying a brick-wall limiter, and then clipping. Right?

Actually, the brickwall limiter would prevent clipping (for short transients clipping can be preferable, but the brickwall limiter option is "safer" for general audio)

[Cornstalks]

If I'm understanding you right, you're suggesting adding the signals A and B, applying a brick-wall limiter, and then clipping. Right?

Actually, the brickwall limiter would prevent clipping (for short transients clipping can be preferable, but the brickwall limiter option is "safer" for general audio)

Ah, I see, my understanding of brickwall limiters was wrong. Thanks!

[Aressera]

In addition to brickwall limiting (which requires some lookahead of a few ms), check out soft clipping/saturation. A properly coded saturation algorithm will function similarly to a compressor but is time-invariant. Therefore it will keep transients from hard clipping, no matter how fast they are, since it operates on individual samples. This produces a small amount of distortion but is way less audible than hard clipping, and perhaps even sounds better than a pure brickwall limiter because it doesn't squash transients in the same way. It's also way easier to implement. It is a similar effect to analog tape saturation (a desirable quality used to good effect by recording studios).

In practice, I would use a compressor with a moderate attack and short release followed by a saturation function for a mix bus output. The compressor will keep the saturator from distorting too much while the saturator catches the fast transients of the signal.

Here is my implementation for a variable-hardness soft clipping function. Is has the following tunable parameter:
* threshold - the amplitude threshold at which the soft clipping curve begins (below this the transfer function is linear). This should be between 0 and 1, 0 indicates the softest clipping transition, while 1 indicates true hard clipping. I'd recommend a value of 0.707, -3dB below full scale.

[source lang="cpp"]Float inverseHardness = 1.0f - threshold;Float hardness = 1.0f / inverseHardness;Float offset = threshold / hardness;for ( Index c = 0; c < numChannels; c++ ){ const Sample32f* input = inputBuffer.getChannelStart©; Sample32f* output = outputBuffer.getChannelStart©; const Sample32f* const outputEnd = output + numSamples; while ( output != outputEnd ) { Float in = *input; if ( in > threshold ) *output = inverseHardness*math::tanh(hardness*in - offset) + threshold; else if ( in < -threshold ) *output = inverseHardness*math::tanh(hardness*in + offset) - threshold; else *output = in; input++; output++; }}[/source]

[l0calh05t]

which requires some lookahead of a few ms

It doesn't. It's perfectly possible to make a zero-lookahead brickwall limiter. (A brickwall limiter with lookahead might sound better though)

[Aressera]

which requires some lookahead of a few ms

It doesn't. It's perfectly possible to make a zero-lookahead brickwall limiter. (A brickwall limiter with lookahead might sound better though)

True, I've made one. They don't sound very good at all though when pushed hard which is why most of them have a lookahead setting.

[l0calh05t]

It's not *that* bad. The jsComp VST (http://electric-snow.net/plugins.html) which I wrote also contains a zero-lookahead brickwall and so far no one complained about the sound and many people liked the fact that it is more suitable for live use.