Peak Meter 3.1 Windows VST questions

[dts350z]

Hi,

Thanks for creating this product! I need to extract Max Peak and AVG RMS values into a spread sheet, so will use a midi recorder and software to translate the midi envelops back into db values (no one seems to have a meter that logs values to a file).

I have some questions on the 3.1 windows VST version of peak meter:

1) The global average RMS values do not agree with other tools such as the free open source RMS Buddy vst or Sony's sound forge (but those two agree with each other). Any idea why this is or what settings to change to get your peak meter to agree with sound forge?

2) I don't see a parameter to reset the cliping indicators (or the CLIP midi output). I see the other resets but the one for clip seems to be missing.

3) speaking of resets, clicking on (or reseting via parameters) the avg values don't seem to work. Peak values, yes, avg values don't change.

4) for the linear curve, translating the midi envelope values back to db would be accourding to this formula? db = .5 * Midi cc value - 60

If that's not right what is, and what are the formulas for the other curves?

For peaks, I'll want a curve that gives the most midi acuracy around 0db, but for Avg RMS around -20 to -25db is most important, please advise on which curves to use.

5) Why can't I display values above 0db? My vst host (plogue bidule) can handle values up +10 db. If the above formula is correct, it looks like the midi envelope will track upto +3db, but the gui values stop at 0.

That's it for now.

Thanks!

[Blue Cat Audio]

Hi,

thanks for your interest in the Blue Cat's Digitak Peak Meter Pro plugin! Please find below our answers to your questions.

1) The global average RMS values do not agree with other tools such as the free open source RMS Buddy vst or Sony's sound forge (but those two agree with each other). Any idea why this is or what settings to change to get your peak meter to agree with sound forge?

The RMS value depends on the time chosen for the average. The way we compute the global average is an average of computed RMS values over time, not the RMS value of the whole song. Maybe you can try to increase the "RMS average" parameter to get it closer to an average computed on the whole file. BTW do not forget to reset the average value before playing.

2) I don't see a parameter to reset the cliping indicators (or the CLIP midi output). I see the other resets but the one for clip seems to be missing.

Just click on the clip indicator to reset the value. The corresponding parameter is called "Clip Reset".

3) speaking of resets, clicking on (or reseting via parameters) the avg values don't seem to work. Peak values, yes, avg values don't change.

When you reset the average value, it's reset to the current value, so it's usually close. That's the reason why you don't see it, but I can confirm it works. You can see it if you stop the audio engine of your host (or change audio input to silence) and click on the value to reset: the average value will drop to -60 dB.

4) for the linear curve, translating the midi envelope values back to db would be accourding to this formula? db = .5 * Midi cc value - 60
If that's not right what is, and what are the formulas for the other curves?

Almost! If you do not change the settings, our plugins maps the [-60 dB ; 0 dB] range to the [0 ; 127] MIDI values. So the exact formula is:
db=(cc*60/127)-60 . For other curves, it's a bit more complex (various kinds of log and exp response curves). I guess you will not need to use them for your purpose, but if you really wish I can try to get the exact formulas for you.

For peaks, I'll want a curve that gives the most midi acuracy around 0db, but for Avg RMS around -20 to -25db is most important, please advise on which curves to use.

Hum, ok, understood the need for the formulas then . The best way will be to use the "fast" curves which give a kind of logaritmic shape to the outputs, so you will have better precision at the top of the curve. Then for the RMS values, you might want to reduce the top value from 0 dB to a smaller value so that you are closer to the zone you are interested in. BTW you can change the bounds of the output if you are not interested in the full range. 127 MIDI values for 60 dB is not very precise..! You should probably give a try to various curves and check the shape of the output (the best way to check this is to record the MIDI CCs in your host if it lets you do this).

5) Why can't I display values above 0db? My vst host (plogue bidule) can handle values up +10 db. If the above formula is correct, it looks like the midi envelope will track upto +3db, but the gui values stop at 0.

Well, it's just a matter of offset, so this is a design decision. On digital systems you usually do not care about values above 0 dB because it will clip at the output. That's the whole point of the K-system: if you need headroom above 0 dB, you can just use the K-12, K-14 or K-20 scales and offset your audio signals by reducing the volume accordingly.

Hope this helps.

Btw if you feel the need for a custom version of the Digital Peak Meter Pro that outputs data to a file, we can do it as part of our services offer. It' not free though .

[dts350z]

The way we compute the global average is an average of computed RMS values over time, not the RMS value of the whole song

I was taught that an average of averages is a bad idea.

In general, using your AVG RMS and max peak values, we are arriving at gain settings that cause clipping (compared to our our previous manual method with another meter).

We are trying RMS+3dB and various AVG RMS integration window settings but would prefer an RMS value for the entire song (as in Sound Forge, etc.).

[Blue Cat Audio]

I was taught that an average of averages is a bad idea.

Well there is no general rule, but it's true that here it would make sense to actually compute the real RMS value, that's a good point. I think this is something we want to do for the next update.

In general, using your AVG RMS and max peak values, we are arriving at gain settings that cause clipping (compared to our our previous manual method with another meter).

We are trying RMS+3dB and various AVG RMS integration window settings but would prefer an RMS value for the entire song (as in Sound Forge, etc.).

I am not sure I understand what you are doing here... What are you doing that causes clipping?

[dts350z]

We (www.dtsac3.com) are "upmixing" or converting stereo music to surround sound. The latest techniques use Plogue Bidule and several VSTs. After dividing the audio from two channels to 5.1 channels we need to rebalance the levels between channels and re-normalize the levels between tracks on an album.

Therefore, we have a multi-pass process. In the first pass, we note down the avg. RMS and Peak values for each ch. each track. All that data goes into a spread sheet that gives us per channel per track gain settings to put back into Plogue for the final pass.

This gives us max loudness track volumes that don't clip, and similar loudness track to track.

Now, we want to use Blue Cat Meters to automate this so the first pass can be album at a time, vs. track at a time. and load all the data into the spread sheet with a script, vs. manual entry.

All this is working, but the results are not satisfactory.

Again, we would prefer a Global avg. RMS value that agrees with sound forge.

We have tried two differnt methods, 1) using your global avg RMS value, 2) doing our own average of your continuous RMS values.

For any given song, I could probably make either result agree with sound forge by adjusting the avg rms millisecond knob, but any other song will not match for that setting.

Too low results can result in clipping in the 2nd pass. To high results give poor loudness/dynamic range in the 2nd pass.

[Optomadic]

..will use ... software to translate the midi envelops back into db values

Hi there, not to intrude but I was wondering exactly what software you use for this?
More importantly iirc MIDI velocity values are represented in signed or unsigned 8bit integers. How do you convert back to floating point values for RMS or AVG? If it sticks to using signed integers, some of the values are going to be incorrect I think. Or am I way off here?

[dts350z]

In Plogue Bidule we connect the midi outputs of 4 stereo BC peak meters to Plogue's Midi File recorder. Each meter is set for a different midi channel.

Orignal Stereo
Front L+R
C/LFE
Rear L+R

Then I have a perl program that parses the midi file and converts the midi values back to db. Yes, for a range of 0 to -60dB that means a midi resolution of only ~.5db, which means an audible (1db) possible error channel to channel.

We're using a 30dB range for peaks, but for RMS (when we do our own average of continuous midi RMS values) a lot of music has instantanous values below the -10 to -40 dB range we were using, so we've gone back to 60dB range for RMS.

Perl fragment:

$db = 60/127*$SummedValues{$ch}{$cc}/$CountedValues{$ch}{$cc} -59.528 if ( $cc == 12 || $cc == 2 );
$db = 30/127*$MaxValues{$ch}{$cc} -29.76 if ( $cc == 11 || $cc == 1 );

Where
$ch = midi channel
$cc = midi controler

so the top line is for avg RMS and the 2nd line is for Max Peak.

I'm using active perl on windows, and the perl midi modules from cpan.org make parsing the midi file trivial.

Another possible approach, with Blue Cat + Plogue, would be to use OSC, vs. midi. That way we would get all the available resolution of the Blue Cat meter's Output Parameters, vs. midi values.

Fortunatly there is also a perl OSC client module but It's not clear to me how we will signal track changes, etc.

I'm not going down that path yet because it seems our current problem is more with the values coming out of Blue Cat, than the poor midi resolution.

Anyway if anyone want a look a perl code I can post it.

If you compile the perl with perl2exe, you get a portable .exe and you can drag and drop a midi files onto the .exe and get your output as a .csv file, already for excel.

[dts350z]

Oh, and these are cc values not velocity. but still 0-127 are the only possible values.

[Optomadic]

Ok I see its for 5.1.

The perl frag does clear it up . Still it would be nice to not have to convert to MIDI (even though I'm a midi guy myself . I do understand the necessity as the process is on the DAW side.

Perhaps a dumb question, would this be impossible after a render (let me know)? If so, there may be better ways at getting accurate data from those channels.

I'm looking into how hard it would be to extrapolate the RMS/AVG to say txt with delimiters for cells (within DAW). If I find anything I'll report back.

[dts350z]

Perhaps a dumb question, would this be impossible after a render (let me know)? If so, there may be better ways at getting accurate data from those channels.

I'm looking into how hard it would be to extrapolate the RMS/AVG to say txt with delimiters for cells (within DAW). If I find anything I'll report back.

I didn't understand most of that.

Are you suggesting we go ahead and do a recording during the first pass, and then use an external (to DAW) tool to derive the RMS/Peak values? If so we hadn't considered that. Anything over 0dB would be cliped in a non 32bit float file, but we could record 32bit float.

I am interested in whatever you find. I have checked out every meter listed on this site, and others found via Google. As far as I can tell Blue Cat is the only one that exposes values as parameters or logs via midi or any other mechanism.

[Blue Cat Audio]

Would you be interested in checking a preview of the next version including a fix for the avg RMS value? Please PM me if you'd like to try it (it should be ready soon). Btw have you purchased the plugin or are you testing the demo (to know which version we should send to you)?

[dts350z]

PM sent

Yes!

[Blue Cat Audio]

It looks like your PM did not make it... There is nothing from you in my inbox...
I just need your email address and the version you need (demo or registered)