If you have 2 *.wav files (or pcm wave data, whatever), what is the proper way to sum them? Seems like straight addition would cause clipping in a hurry, and 2+2=4 but that leads to a quadruple in power, not a doubling right? And is a *.wav sine wave with amplitude 32000 twice as loud as 16000 or what -- what's the relationship (loudness or power).

When you sum wave files, it is important to first reduce the amplitudes of each file so that the sum will not clip. Check out Audacity. The online manual and wiki links provides much help in solving your problem.

I'm working on real time synthesis generation, so simply slashing the first signal in half suddenly would sound bad on the introduction of a second wave source. I guess I'll hit the Audacity forum to see if the answer is just A+B. That's how I've always done it, but I got to thinking maybe that was incorrect possibly, but I can't derive anything else that would work. 16 bits is not a lot ...

You just sum the numbers in the .WAV file. Audio mixers just add voltages together; you need to do the same.

16 bits may not seems like a lot, but it's something like a 90 dB range from hex "0001" to "FFFF".

Audacity's _internal_ representation use 32-bit _floating point_ numbers, which is more than enough.

24-bit sound cards _use_ 24 bits (fixed-point, not floating-point)because some of those bits are going to be "lost" during editing, levelling, and so on.

. Charles

0db+0db=+6db

This is the equitation if the 2 picks are reaching 0db simultaneously each one (which happens only theoretically).

If you have 2 audio files with pick level of 0 db and you want to mix them together just put the leveler to -3 of each stereo file and export or bounce them realtime.
That is it.
-3.5 db is good for precaution.

Yes, but this is for my software dp kernel, and there can be a LOT more than 2 keys sounding at a time ... like, I need to knock it back to 12 bits to handle the summation of say 16 notes (the other 4 bits, 2^4) as a reasonable peak.

That's why Audacity uses 32-bit _floating-point_ numbers, not fixed-point numbers, for all its internal manipulations.

You should do the same.

[I have an old memory that digital synths (e.g., the DX-7) with 12-bit or 16-bit computational sound generators could get into problems with "graininess". It's a peculiar digital artifact, and doesn't sound nice. ]

. charles

The DX-7 chips did many calculations in the log domain so that multiplications were simple additions. IIRC, earlier models used 12 bit converters, giving an SNR of ~12 bits * 6dB = 72 dB. I don't believe any of them tried to control aliasing.

Well, I use 32-bit int with the value shifted up by 8. That gives me resolution to 0.004 and 7 bits of headroom at the top, plus int operations are quicker than fp, though maybe I am out of date wrt new simd fp instructions (added to todo list). But all of that is not the problem.

The problem is at the end where the output value to the sound card is -32768 to 32767, and the final temp value that's held (as 32-bit fp or 32-bit fixed point int) is out of that range. I can think of a few strategies to deal with this:

(1) Scale the final output such that a single key peaks at 12 bits, etc.
(2) Some sort of gradual signal compression that equates 32767 with a larger value.
(3) Some combination of 1 and 2.
(4) Buy a 24-bit sound card.

This is a very interesting read, and demonstrates a -105dB tone using only 16 bits:
http://people.xiph.org/~xiphmont/demo/neil-young.html