Re: Calculating peak level in db
Re: Calculating peak level in db
- Subject: Re: Calculating peak level in db
- From: "James Chandler Jr." <email@hidden>
- Date: Sat, 12 Oct 2002 20:45:57 -0400
The other messages are "right on".
You can implement peak metering, average metering, RMS metering. All will
give slightly different results. Wanna get fancy, you can make composite
meters which indicate several different measurements with the same on-screen
graphic.
A "typical" software peak meter will at least indicate the recent peak
value. Using floating point samples, the 0 dB reference value would be 1.0.
PeakDB = 20.0 * Log10(abs(MaxSampleValue));
If the floating point abs(MaxSampleValue) goes above 1.0, it is nice to
provide a "Clip LED" above the bar-graph meter. Light up the "Clip LED" if
any sample value exceeds 0 dB (1.0). As long as the samples remain in
floating point format, values above 1.0 don't have bad consequences, but as
soon as the audio is converted back to 16 bit or 24 bit for sound card
output or file storage, values above 1.0 will clip, so it is considerate to
let the user know.
Some program clip indicators will latch on "permanently" until the user
clicks the clip indicator to clear it. I prefer a clip indicator that stays
on a few seconds so the user is likely to notice, but eventually clears
itself so the user doesn't have to manually clear the indicator. Some
softwares offer a user preference to define the behavior of the clip
indicator (whether it clears itself or must be manually cleared).
IMO it is overkill to refresh on-screen meters more often than 30 times per
second. Often 10 refreshes per second is adequate. The less screen-drawing
you do, the more time is available to audio DSP.
There are many possible approaches to gather the data that will be displayed
in an on-screen meter, depending on how picky you are, and how picky you
expect the customers to be.
A simple, pretty CPU economical method--
When you are notified of the samplerate of the audio, figure out how many
samples will fit in a 1/10th second interval, or however often you want to
update the on-screen meter. Every time a buffer comes thru your program,
scan the buffer looking for the max absolute value. After you have scanned
enough samples or buffers to exceed a 1/10th second interval, calculate
PeakDB = 20.0 * Log10(MaxSampleValue), and then schedule a process (or set a
flag, whatever) that will draw the current PeakDB to the on-screen meter.
This will look "good enough" for many purposes.
You can get much fancier, using attack-release constants in the metering,
add a peak-hold feature in the meter, whatever.
The ongoing tendency in modern fast systems is to use very small audio
buffers, to reduce latency. If you want to use the above simple meter
method, you should restrict meter updates to 30 updates per second or lower,
so that each update scans a sufficient number of samples to get a reasonably
valid result. Without adding a fancier attack-release envelope applied to
the samples, a really fast metering rate would cause the meter level to vary
wildly between screen-draws. This wouldn't look very good and it would not
offer very useful information to the user.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.