Level meter that averages multiple peak levels

[David Kissam]

I am building a rather large virtual instrument and I need a very simple tool that, as far as I know, doesn't exist.

I need a level meter that reports peak levels of the left channel, right channel, and a sidechain channel, and the average of those three peak levels (the sum of those 3 numbers divided by 3). I can obviously use an ordinary level meter for this, and do the math with a spreadsheet, but I have to measure thousands of files so having a plugin do this will save much time.

I do not need any graphical component in the plugin; all I need is text.

Does anything like this exist? If not, would anyone be willing to make it, and how much would you charge?

[mystran]

I would highly doubt such a meter exists, simply because it is rather difficult to think of a situation where the average peak level of left,right and side (as you specify) would be useful.

There's also a little tricky detail with regards to comparing side with left/right... namely the scaling of mid/side levels is kinda arbitrary. If we assume both left and right contain the same signal at 0dB, then three common choices give +6dB (simple sum), +3dB (equal power rule; this one gives the same RMS whether you compute it from left,right or mid,side) and +0dB (average) maximums for mid (and side if the signals are out of phase)... and as it turns out, the "correct" choice for your case probably depends on exactly what the averaging of left,right and side is supposed to compute.

That said, if you simply need one peak value per file and you have a large number of files, would it perhaps be easier to have a simple application (or even a command line utility) that simply takes a list of files and finds the peaks for each?

[David Kissam]

I would highly doubt such a meter exists, simply because it is rather difficult to think of a situation where the average peak level of left,right and side (as you specify) would be useful.

Thanks for the reply. I think you misread "sidechain" as just "side". To clarify, I'm not doing anything with the side channel. I have samples of a piano recorded with 3 microphones - left, center, and right. Left & right are recorded in stereo files, and center is recorded in mono files. I want the average peak level of these three mics for every sample. I thought the simplest way to do this would be to insert a level meter on the L&R track, with a sidechain input coming from the Center track, so I can have the level meter read all three signals.

I'm working with the samples in a DAW, and my method involves naming every audio event in the DAW with information that includes the volume of that sample. I need one number that best represents the volume of each sample, not 3 separate numbers (one for each mic). My testing has indicated that an average peak level of left, right, and center may provide the most accurate and consistent result. Any one of the mics in isolation is prone to unpredictable and misleading variations, and any mix of the signals is even worse, as that brings correlation into play.

It would be nice to automate this naming of audio events, but my DAW (Studio One) does not give me this kind of access as far as I know. Reaper probably would, but it's too late to switch now. Thus, I think a VST plugin will be fine, at least for this project.

[Dwomoh]

I can code this plugin you are looking for in JSFX and then you will use the free ysfx vst3 plugin to load it up in studio one. I want to help you, how much will you be willing to pay? We can chat privately if you are ok with this proposal?

[mystran]

I need one number that best represents the volume of each sample, not 3 separate numbers (one for each mic). My testing has indicated that an average peak level of left, right, and center may provide the most accurate and consistent result. Any one of the mics in isolation is prone to unpredictable and misleading variations, and any mix of the signals is even worse, as that brings correlation into play.

Have you tried computing the maximum combined power (with or without perceptual weighting) over a short-term sliding window... ie. basically what LUFS meters call "momentary" and the rest of the world calls sliding RMS window?

That's insensitive to crest ratios, phase correllations between channels, etc.. and existing meters (eg. Youlean) can compute the value if you feed the three channels as L+C+R of a 5.1 mix. The LUFS "short-term" and "integrated" values are longer term averages with some other funny business, but the "momentary" (and specifically "max momentary") might be quite good for your purposes.

[David Kissam]

Have you tried computing the maximum combined power (with or without perceptual weighting) over a short-term sliding window... ie. basically what LUFS meters call "momentary" and the rest of the world calls sliding RMS window?

That's insensitive to crest ratios, phase correllations between channels, etc.. and existing meters (eg. Youlean) can compute the value if you feed the three channels as L+C+R of a 5.1 mix. The LUFS "short-term" and "integrated" values are longer term averages with some other funny business, but the "momentary" (and specifically "max momentary") might be quite good for your purposes.

One of the measurements I've been testing is max momentary LU. It doesn't seem to be the best option, because it's influenced by the loudness of the audio over a period of time (400ms I think). This means that it will tend to give a higher value to the sustain-pedal-down samples (as compared to the sustain-pedal-up samples with the same initial amplitude), because the the volume often decays slower when the sustain pedal is down.

I'm still using Studio One 5, which doesn't support 5.1 mixing, so I don't think I could use Youlean in that way. Thanks for bringing it to my attention though.

[David Kissam]

I can code this plugin you are looking for in JSFX and then you will use the free ysfx vst3 plugin to load it up in studio one. I want to help you, how much will you be willing to pay? We can chat privately if you are ok with this proposal?

I have two other requirements for the plugin that I didn't mention. I'd like it to measure "true peaks" and I need it display the last measured peak until the next time playback is started. It must reset every time playback starts.

[mystran]

One of the measurements I've been testing is max momentary LU. It doesn't seem to be the best option, because it's influenced by the loudness of the audio over a period of time (400ms I think).

Well, any RMS-measure is over some period, since you have to smooth over at least one period of the waveform, but .. yeah I can see the 400ms rectangular window (as specified by LUFS standards) perhaps being a little sluggish for this.

The windows typically used by RMS compressors where you basically use something close to the wavelength of the lowest "audio frequencies" you care to reject (eg. 50ms wavelength for 20Hz, or 25ms for 40Hz) might work better for you, but I'm not sure if any off-the-shelf meter will do these (and track max) .. since visually such a window is kinda "too fast" (eg. even in an RMS compressor, if you had a meter for the envelope, you'd probably smooth the metering further to "stabilize the needle").

[David Kissam]

The windows typically used by RMS compressors where you basically use something close to the wavelength of the lowest "audio frequencies" you care to reject (eg. 50ms wavelength for 20Hz, or 25ms for 40Hz) might work better for you, but I'm not sure if any off-the-shelf meter will do these (and track max) .. since visually such a window is kinda "too fast" (eg. even in an RMS compressor, if you had a meter for the envelope, you'd probably smooth the metering further to "stabilize the needle").

That's an interesting idea but I don't know how to test it at the moment, so I think I'll go ahead with my peak average idea.

I've never coded a plugin before (my coding experience consists of writing a script in Lua that automatically maps samples in Kontakt based on their filenames) but this seems pretty close to the easiest place to start. Would you recommend any particular tools to start with? I was looking at JUCE.

[G-Spot]

I'm working with the samples in a DAW, and my method involves naming every audio event in the DAW with information that includes the volume of that sample.

This doesn't seem an efficient method: a meter plugin, apart from being nontrivial to procure/implement, can only show measurements at the current time, and for samples that you loaded into tracks of your DAW. Mistakes and repeated manual steps seem unavoidable.

If you are preparing samples in order to build a virtual instrument with them you should aim to automatically rebuild the complete instrument from code and sample files, in order to audition the complete instrument (with progressively improved samples) rather than raw recorded samples.

Integrating batch processing of all samples (to report various measures of how loud they are and find abnormal ones that require modifications or re-recording, to apply corrective compression, gain etc. according to those measurements, and possibly other purposes) in the build process of your instrument plugin, without unnecessary manual steps, would allow quick iteration in the development of your actual project.

[David Kissam]

This doesn't seem an efficient method: a meter plugin, apart from being nontrivial to procure/implement, can only show measurements at the current time, and for samples that you loaded into tracks of your DAW. Mistakes and repeated manual steps seem unavoidable.

If you are preparing samples in order to build a virtual instrument with them you should aim to automatically rebuild the complete instrument from code and sample files, in order to audition the complete instrument (with progressively improved samples) rather than raw recorded samples.

Integrating batch processing of all samples (to report various measures of how loud they are and find abnormal ones that require modifications or re-recording, to apply corrective compression, gain etc. according to those measurements, and possibly other purposes) in the build process of your instrument plugin, without unnecessary manual steps, would allow quick iteration in the development of your actual project.

Yes, manually renaming the events in the DAW is not efficient. Among other reasons, making a VST plugin that does what I have described seemed easier to me than making a program that renames files. In the case of the plugin, I know this can be accomplished with JUCE. In the case of a batch analysis/renaming program, I have no idea where to even start. Could you point me in the right direction?

[resynthesis]

I think C++ is still the recommended language for JUCE development so that's a place to start. maybe have a poke around some of the open source offerings which do something like you need and go from there.

[G-Spot]

Writing a batch processing tool operating on audio files and reports is much easier than writing a VST plugin:

• no GUI
• a generic script or executable rather than a carefully crafted dynamic link library
• unconstrained, natural file system access instead of the narrow interface of events and audio streams available to plugins
• not real-time, you can process whole files at once
• reuse of existing tools, glued together by scripts
• any combination of programming languages and libraries

Managing files might seem more work compared to a mere power measurement, but it is automation of work that you would be doing by hand and, if you use good libraries (e.g. Boost Filesystem or its standard successor in C++, or pathlib in Python), not too difficult.

[David Kissam]

Managing files might seem more work compared to a mere power measurement, but it is automation of work that you would be doing by hand and, if you use good libraries (e.g. Boost Filesystem or its standard successor in C++, or pathlib in Python), not too difficult.

I originally wanted to do this measuring of peaks and renaming by automation, but for various reasons (mostly because I couldn't figure out how), I resigned myself to doing it manually.

I have a tiny bit of familiarity with Boost Filesystem already. What I don't understand at all is this: how do I get access to the contents of an audio file in my code? To find the peak level, I just need to find the highest sample value, but how do I access the samples? Ideally I would like to oversample the audio within my script/program, as that would give me a "true-peak" value, but doing that is even more of a mystery to me.

[ahanysz]

I agree: it sounds like you could really benefit from a command line batch tool. If you literally just want the maximum sample value of each channel and the average of those three numbers, then it's about 20 lines of python:

Code: Select all

import sys
import numpy as np
from scipy.io import wavfile

if len(sys.argv)==1: # there were no command line arguments
  sys.exit("Please specify one or more .wav format files as command line arguments")

filenames = sys.argv[1:] # specify any number of files as command line arguments
peaks = [] # start with a blank list and append peak values for each file as we go

for f in filenames:
  samplerate, values = wavfile.read(f)
  # "values" is a numpy array, 1-d for mono and 2-d otherwise
  if len(values.shape)==1: # mono
    m = max(abs(values))
    print(f'Reading mono file {f}. Peak sample value is {m}')
    peaks.append(m)
  else: # assume stereo, but we could easily modify the code for multichannel
    m_left = max(abs(values[:,0]))
    m_right = max(abs(values[:,1]))
    print(f'Reading stereo file {f}. Peak sample values are {m_left} and {m_right}.')
    peaks.append(m_left)
    peaks.append(m_right)
print(f'Average of peak levels is {sum(peaks)/len(peaks)}')

To use this:

• Install python if you don't have it already. (This is probably the hardest step! Details vary depending on whether you're on Windows, Mac or Linux. Google is your friend here.)
• Save the above code into a plain text file. Call it something like "levels.py". Make sure windows/notepad doesn't trick you into calling it "levels.py.txt".
• On the command line, type

  Code: Select all

  python levels.py monofilename.wav stereofilename.wav

  (adjusting the names to match your actual filenames).

You should see output that looks something like:

Code: Select all

Reading mono file monofilename.wav. Peak sample value is 32611
Reading stereo file stereofilename.wav. Peak sample values are 3862 and 3494.
Average of peak levels is 13322.333333333334

If you've got hundreds of files, then you'll want to modify the code to loop through all your files, and perhaps save the results to a CSV file, rather than typing a command for each pair of files. Likewise, you can add more code for renaming your audio files according to whatever system you have going, and for reading inputs in formats other than .wav.

I don't know how confident you are with running things from the command line and rewriting other people's code. But if you were considering learning C++ and JUCE, I'm sure this option is much easier!