From: moz on
Hi Everyone,

I could need a little help today.

I am currently implementing a software Audio Meter that visualizes the
signal in dB.

The signal is presented in form of a bar that fills up all the way to the
top if the signal reaches 0dBFS and is empty when it is below or equal
-60dBFS. The bar currently follows a linear approach, meaning that the
pixel difference between each unit is the same.

|-----|-----|-----|-----|
-80 -60 -40 -20 0

This all works great. I get there basically by building the RMS over a
window of x samples, convert the result to dB (via log function) and
calculate the pixel for the value on the x coordinate(where -80dB is 0% and
0dB is 100%) and fill the rectangle with color (every y millseconds).

In the next step I simply want to present the values in log scale where the
values are represented graphically like:

|-----|-----|-----|-----|-----|-----|-----|-----|-----|
-20 -10 -7 -5 -3 -1 0 1 2 3

This is a typical VU Meter as found on many hardware(software)
implementations.

I do have a hard time with transforming the linear way to present the
signal to this log way. The main problem: How would I find the amount of
pixels I would need to present each value on this log scale ?

Next question then: How could I then implement specific scales like let's
say the K-20 scale or DIN45406 ?

Any help or pointers would be appreciated.

Thanks in advance,
Mozzak



From: Les Cargill on
moz wrote:
> Hi Everyone,
>
> I could need a little help today.
>
> I am currently implementing a software Audio Meter that visualizes the
> signal in dB.
>
> The signal is presented in form of a bar that fills up all the way to the
> top if the signal reaches 0dBFS and is empty when it is below or equal
> -60dBFS. The bar currently follows a linear approach, meaning that the
> pixel difference between each unit is the same.
>
> |-----|-----|-----|-----|
> -80 -60 -40 -20 0
>
> This all works great. I get there basically by building the RMS over a
> window of x samples, convert the result to dB (via log function) and
> calculate the pixel for the value on the x coordinate(where -80dB is 0% and
> 0dB is 100%) and fill the rectangle with color (every y millseconds).
>
> In the next step I simply want to present the values in log scale where the
> values are represented graphically like:
>
> |-----|-----|-----|-----|-----|-----|-----|-----|-----|
> -20 -10 -7 -5 -3 -1 0 1 2 3
>
> This is a typical VU Meter as found on many hardware(software)
> implementations.
>
> I do have a hard time with transforming the linear way to present the
> signal to this log way. The main problem: How would I find the amount of
> pixels I would need to present each value on this log scale ?
>

Strategy 1:
Put the data into Excel, run a trendline on it which displays
the formula for the trendline. Then invert that function. If
not Excel, then choose your weapon of choice.

Strategy 2:
Define a breakpoint table and interpolate.

To be a true VU meter, you also have to match VU meter
ballistics.

http://www.tonmeister.ca/main/textbook/node755.html


> Next question then: How could I then implement specific scales like let's
> say the K-20 scale or DIN45406 ?
>
> Any help or pointers would be appreciated.
>
> Thanks in advance,
> Mozzak
>
>
>

--
Les Cargill
From: Jerry Avins on
On 7/3/2010 2:28 PM, moz wrote:
> Hi Everyone,
>
> I could need a little help today.
>
> I am currently implementing a software Audio Meter that visualizes the
> signal in dB.
>
> The signal is presented in form of a bar that fills up all the way to the
> top if the signal reaches 0dBFS and is empty when it is below or equal
> -60dBFS. The bar currently follows a linear approach, meaning that the
> pixel difference between each unit is the same.
>
> |-----|-----|-----|-----|
> -80 -60 -40 -20 0
>
> This all works great. I get there basically by building the RMS over a
> window of x samples, convert the result to dB (via log function) and
> calculate the pixel for the value on the x coordinate(where -80dB is 0% and
> 0dB is 100%) and fill the rectangle with color (every y millseconds).

You must understand something about logarithms in order to express the
signal magnitudes as logarithms.

> In the next step I simply want to present the values in log scale where the
> values are represented graphically like:
>
> |-----|-----|-----|-----|-----|-----|-----|-----|-----|
> -20 -10 -7 -5 -3 -1 0 1 2 3
>
> This is a typical VU Meter as found on many hardware(software)
> implementations.
>
> I do have a hard time with transforming the linear way to present the
> signal to this log way. The main problem: How would I find the amount of
> pixels I would need to present each value on this log scale ?

Plot the signal without taking logs, then label the points with their
(suitably scaled)logarithms. So -20 is the label for .01, -3 is the
label for .707, +3 is the label for 1.4.4, etc.

...

Jerry
--
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������
From: glen herrmannsfeldt on
moz <mymozzak(a)n_o_s_p_a_m.gmail.com> wrote:

> I am currently implementing a software Audio Meter that visualizes the
> signal in dB.

> The signal is presented in form of a bar that fills up all the way to the
> top if the signal reaches 0dBFS and is empty when it is below or equal
> -60dBFS. The bar currently follows a linear approach, meaning that the
> pixel difference between each unit is the same.
(snip)

> In the next step I simply want to present the values in log scale where the
> values are represented graphically like:

> |-----|-----|-----|-----|-----|-----|-----|-----|-----|
> -20 -10 -7 -5 -3 -1 0 1 2 3

> This is a typical VU Meter as found on many hardware(software)
> implementations.

> I do have a hard time with transforming the linear way to present the
> signal to this log way. The main problem: How would I find the amount of
> pixels I would need to present each value on this log scale ?

Usual methods would be a lookup table or a loop comparing to
breakpoints, exit the loop at the appropriate point. It depends
somewhat on the available hardware.

Discussed here not so long ago was how to do A (or other) weighting.

Also, as someone else mentioned, balistics.

-- glen