Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!


Combining Sound Objects ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 Endemoniada   Members   -  Reputation: 312

Like
0Likes
Like

Posted 25 November 2012 - 10:11 PM

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.

Sponsor:

#2 Cornstalks   Crossbones+   -  Reputation: 6991

Like
0Likes
Like

Posted 25 November 2012 - 10:16 PM

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.

[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#3 l0calh05t   Members   -  Reputation: 797

Like
1Likes
Like

Posted 26 November 2012 - 03:55 AM

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...

#4 Cornstalks   Crossbones+   -  Reputation: 6991

Like
0Likes
Like

Posted 26 November 2012 - 09:28 AM


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?
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#5 l0calh05t   Members   -  Reputation: 797

Like
2Likes
Like

Posted 27 November 2012 - 08:01 AM

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)

#6 Cornstalks   Crossbones+   -  Reputation: 6991

Like
0Likes
Like

Posted 27 November 2012 - 10:09 AM


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!
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#7 Aressera   Members   -  Reputation: 1461

Like
1Likes
Like

Posted 27 November 2012 - 04:25 PM

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]

#8 l0calh05t   Members   -  Reputation: 797

Like
0Likes
Like

Posted 27 November 2012 - 05:47 PM

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)

#9 Aressera   Members   -  Reputation: 1461

Like
1Likes
Like

Posted 28 November 2012 - 01:03 AM


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.

#10 l0calh05t   Members   -  Reputation: 797

Like
0Likes
Like

Posted 29 November 2012 - 03:45 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS