Is there an easier way to calculate a frequency on a set of wav samples?

Hi,

I'm trying to measure the maximum volume of a real-time wav output using 16
bit signed integers.

I have heard that running them through a FFT could get me a frequency, but I
don't have the CPU power to accomplish this in real time.

Could I do something more crude that would give me an estimate of frequency
but at much less CPU time cost.

How about counting the number of times the samples when from positive to
negative and back to positive again.  Could I use this to determine a rough
frequency?

If I took 50ms samples, estimated the frequency using this technique and
then ran them through an equal loudness curve, would this be a rough way to
determine the perceived volume?

Thanks,

SA Dev

On Mon, 29 Mar 2004 10:07:55 -0600, "SA Dev" <nospam38925@forme.com>
wrote:

>Hi,
>
>I'm trying to measure the maximum volume of a real-time wav output using 16
>bit signed integers.
>
>I have heard that running them through a FFT could get me a frequency, but I
>don't have the CPU power to accomplish this in real time.
>
>Could I do something more crude that would give me an estimate of frequency
>but at much less CPU time cost.
>
>How about counting the number of times the samples when from positive to
>negative and back to positive again.  Could I use this to determine a rough
>frequency?

If the signal has only one frequency component, then counting zero
crossings will work perfectly.  Or, if the signal is otherwise in some
special catgory, such as square waves, then it will work fine.  But in
general, counting zero crossings won't even get you close.  You would
probably end up counting something related to the frequency with the
highest amplitude, or most likely, you will get complete garbage.


-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

SA Dev wrote:

> Hi,
> 
> I'm trying to measure the maximum volume of a real-time wav output using 16
> bit signed integers.
> 
> I have heard that running them through a FFT could get me a frequency, but I
> don't have the CPU power to accomplish this in real time.
> 
> Could I do something more crude that would give me an estimate of frequency
> but at much less CPU time cost.
> 
> How about counting the number of times the samples when from positive to
> negative and back to positive again.  Could I use this to determine a rough
> frequency?
> 
> If I took 50ms samples, estimated the frequency using this technique and
> then ran them through an equal loudness curve, would this be a rough way to
> determine the perceived volume?
> 
> Thanks,
> 
> SA Dev

1) To measure volume, what do you want with frequency?
2) You write of real-time output. Do you want to simulate a meter that
    shows the actual volume at any instant?
3) So-called equal-loudness curves depend very much on the gain settings
    when the material was recorded. What you need to do is much simpler
    if you can ignore Fletcher-Munsen.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Hi Jerry,

> 1) To measure volume, what do you want with frequency?
> 2) You write of real-time output. Do you want to simulate a meter that
>     shows the actual volume at any instant?
> 3) So-called equal-loudness curves depend very much on the gain settings
>     when the material was recorded. What you need to do is much simpler
>     if you can ignore Fletcher-Munsen.

My goal is to "normalize" the volume from different sources (video games) so
that the loudest parts of each one are similar.  The problem is that some
games have sounds that are very low such as old discrete electronics
explosions to sounds that are very high.  Given this, do you think I could
ignore Fletcher-Munsen?  What technique would you recommend I try?

Thanks,

SA Dev

SA Dev wrote:

> Hi Jerry,
> 
> 
>>1) To measure volume, what do you want with frequency?
>>2) You write of real-time output. Do you want to simulate a meter that
>>    shows the actual volume at any instant?
>>3) So-called equal-loudness curves depend very much on the gain settings
>>    when the material was recorded. What you need to do is much simpler
>>    if you can ignore Fletcher-Munsen.
> 
> 
> My goal is to "normalize" the volume from different sources (video games) so
> that the loudest parts of each one are similar.  The problem is that some
> games have sounds that are very low such as old discrete electronics
> explosions to sounds that are very high.  Given this, do you think I could
> ignore Fletcher-Munsen?  What technique would you recommend I try?
> 
> Thanks,
> 
> SA Dev

You can't normalize a whole file to make its loudest sound match the
loudest sound in some other file in real time. I can't even imagine what
that might mean. AGC was discussed in this connection before, but that
doesn't seem to do what you want. There is probably a design for a
digital VU meter somewhere that you can have; look for it with Google.
If you want to account for the ear's selective sensitivity, Google for
an A-weighting filter. For a simple approximation to the whole setup,
make a filter with a broad peak around 1.5 KHz, square the samples out
if it, and feed them to a leaky integrator aka a simple low-pass, and
remember the largest output from that. That number will pretty well
indicate the loudest that file ever gets. After you have a number for
each of your sound tracks, use the inverses to set the playback gain.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

SA Dev wrote:
> My goal is to "normalize" the volume from different sources (video games) so
> that the loudest parts of each one are similar.  The problem is that some
> games have sounds that are very low such as old discrete electronics
> explosions to sounds that are very high.  Given this, do you think I could
> ignore Fletcher-Munsen?  What technique would you recommend I try?

As I recall, the presense of DC is what was tripping you up before.  I 
recommend that you run the signal through a high-pass filter, calculate 
the power in the result, and use that as the gain control.

I also don't see why you need to do this in real-time.  You could simply 
adjust the volume manually on each game until it sounds right to you, 
and then save and use the adjusted results.  Then you could throw the 
CPU at other tasks (such as video rendering).

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com          (703) 779-7770
The secret to enjoying your job is to have a hobby that's even worse
   - Calvin's Dad

Jim Thomas <jthomas@bittware.com> wrote in message
news:106h28brqevda47@corp.supernews.com...
> SA Dev wrote:
> > My goal is to "normalize" the volume from different sources (video games) so
> > that the loudest parts of each one are similar.  The problem is that some
> > games have sounds that are very low such as old discrete electronics
> > explosions to sounds that are very high.  Given this, do you think I could
> > ignore Fletcher-Munsen?  What technique would you recommend I try?
>
> As I recall, the presense of DC is what was tripping you up before.  I
> recommend that you run the signal through a high-pass filter, calculate
> the power in the result, and use that as the gain control.
>
> I also don't see why you need to do this in real-time.  You could simply
> adjust the volume manually on each game until it sounds right to you,
> and then save and use the adjusted results.  Then you could throw the
> CPU at other tasks (such as video rendering).

I think the idea was to automate this, i.e. no matter what video game was
playing, the volume sounded "right" with no need to tell the software what the
game was.  I get the impression that the OP doesn't have access to the original
sound effects at all, he just gets an audio feed.  If I'm on the right track, I
think Jim's suggestion of a AGC based on a high-pass version of the audio is
right on the money.  However, based on previous posts, I'm not sure the OP has
the know-how to make this work without quite a bit more research...

Hi Jon,

> I think the idea was to automate this, i.e. no matter what video game was
> playing, the volume sounded "right" with no need to tell the software what
the
> game was.  I get the impression that the OP doesn't have access to the
original
> sound effects at all, he just gets an audio feed.  If I'm on the right
track, I
> think Jim's suggestion of a AGC based on a high-pass version of the audio
is
> right on the money.  However, based on previous posts, I'm not sure the OP
has
> the know-how to make this work without quite a bit more research...

Yes, that is exactly right.  Can you post some links where I can investigate
"AGC based on a high-pass version of the audio"?  I'm willing to learn...

Thanks,

Alan

Jon,

> sound effects at all, he just gets an audio feed.  If I'm on the right
track, I
> think Jim's suggestion of a AGC based on a high-pass version of the audio
is
> right on the money.

Ok, I think I'm understanding at least what you are suggesting.  If I create
a high-pass version of the audio (a version of the audio which cuts out the
lower frequencies leaving only the higher ones?), and run an AGC on this
higher version, it will determine a ratio I can use to alter the original
version of the audio?  I'm guessing that the reason for the high-pass
version is because these are the sounds that are loudest to the ear and in a
sense I will be ignoring the low frequency rumbles that have been throwing
me off?

If this is right, do you have any C code examples of producing a high pass
version (is this a low pass filter?), and/or AGC code?

Thanks,

SA Dev

SA Dev wrote:
> Ok, I think I'm understanding at least what you are suggesting.  If I create
> a high-pass version of the audio (a version of the audio which cuts out the
> lower frequencies leaving only the higher ones?), and run an AGC on this
> higher version, it will determine a ratio I can use to alter the original
> version of the audio?  

Yes.

> I'm guessing that the reason for the high-pass
> version is because these are the sounds that are loudest to the ear and in a
> sense I will be ignoring the low frequency rumbles that have been throwing
> me off?

Well... kinda.  The ear is completely deaf to DC, but a typical AGC 
circuit is not.  The high pass removes that.

> 
> If this is right, do you have any C code examples of producing a high pass
> version (is this a low pass filter?), and/or AGC code?

How about some psuedo code?
First calculate the DC value (init dc to 0):

dc = a * dc + (1-a)*input;

Here, "a" should be a number close to but less than 1.0.  The closer it 
is to 1.0, the sharper the filter, but the longer it will take to 
converge.  Once you have the DC, you can subtract it out from the input 
to get the output:


hp_out = input - dc;

Now for the AGC portion.  This is untested code, and it could probably 
be done better.  It certainly needs tuning.

rect = abs(hp_out);     // rectify the high pass
if (rect > envelope)    // if it's bigger than the envelope, attack
{
   envelope += (rect-envelope) * attack;
}
else                    // the signal is smaller than envelope, so decay
{
   envelope *= decay;
}

attack and decay are tuneable constants.  decay should be a little less 
than 1.0.  The closer it is to 1.0, the longer it will take for the gain 
to rise up in the presense of a weak signal.  attack should also be less 
than one.  The closer it is to one, the quicker the gain will decrease 
with the onset of a strong signal.  I guess it could be pretty small. 
Once you have the envelope of the signal, you can come up with a gain 
value, but you need to have both a maximum and a minimum gain.

if (envelope < too_weak)
   gain = max_gain;
else if (envelope > too_strong)
   gain = min_gain;
else
   gain = env2gain(envelope);

I'm too lazy to figure out the env2gain function for you, but it should 
produce max_gain when passed an envelope == too_weak, and it should 
produce min_gain when env==too_strong.  You will probably want 
too_weak*max_gain < too_strong*min_gain, so that quiet parts ARE quieter 
- just not so MUCH quieter than before.

Finally, apply the gain to the signal.  You can use either the original 
signal, or the output of the high pass.  I'd be inclined to use the 
high-pass output - otherwise, you might clip:

output = hp_out * gain;

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com          (703) 779-7770
I'm Jim Thomas, and I approve this message.