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

# Audio Metering implementation

Started by ●July 3, 2010

Reply by ●July 3, 20102010-07-03

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

Reply by ●July 3, 20102010-07-03

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

Reply by ●July 3, 20102010-07-03

moz <mymozzak@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