Audio Peak Level not dropping

[eclectic-tech]

I'm wanting to use the Peak Level meter in my current skin. So I've resurrected an old version. I can remember there is an issue with the Peak metering, it doesn't hold the position, it basically acts like the RMS metering, but just gets the highest value. But a proper Peak meter holds it's value for 2-3 seconds.

I have a version of that code still that someone helped with. But the issue was that onced it peaked at 0db for a few seconds it never dropped once the volume got lower. It works well, until that point, then it stops responding. I was hoping to get this fixed if anyone has a clue about it.

{clipped code}
I've changed the whole thing to use shape meters instead of graphics, in case you want to try it.
Seems to work ok, just that problem with the Peak indicators 'sticking' which I tried to find a way to reset them on max but not working out for me!

Appreciate any help

Late to see your post... but here are a few thoughts...

The reason your Peak level is 'sticking' is because you have the PeakGain (and RMSGain) set to 2.0 (displaying twice the actual level).
Reduce that to a lower level (1.0 ~1.5) to show normal Peak reactions in your skin.

Trying to hold the max peak level using IfConditions is not the way I would suggest.
There are 40 updates per second to the value that need to be tested for higher values then the last while you are pausing or disabling the display... not really a practical or efficient method.

A better approach to control the Peak display would be to create a second AudioLevel parent measure with the same Attack and Gain as the RMS measure for the Peak values, but set the PeakDelay to your desired level (3000~5000).

Something like this should give close to your desired result:

Code: Select all

[Rainmeter]
Update=25
BackgroundMode=2
SolidColor=255,255,255,20
AccurateText=1
MiddleMouseUpAction=[!Refresh]

[Metadata]
Author=sl23
Description=VU Metre
Version=2024.6.30

[Variables]
AquaDark=0,255,255,200
Green=128,255,0
Orange=255,170,0
OrangeDark=255,128,0
Red=255,100,100
White20=255,255,255,20
PeakDelayL=0
PeakDelayR=0
ActiveGainLevel=1.5

========================================
; Measures
========================================
[mAudio]
Measure=Plugin
Plugin=AudioLevel
Port=Output
RMSAttack=25
RMSDecay=300
RMSGain=#ActiveGainLevel#
PeakAttack=0
PeakDecay=0
PeakGain=1.0

[mAudioPeak]
Measure=Plugin
Plugin=AudioLevel
Port=Output
RMSAttack=0
RMSDecay=0
RMSGain=1.0
PeakAttack=25
PeakDecay=5000
PeakGain=#ActiveGainLevel#

[mLeft]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudio
Type=RMS
Channel=L

[mRight]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudio
Type=RMS
Channel=R

[mPeakLeft]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudioPeak
Type=Peak
Channel=L

[mPeakRight]
Measure=Plugin
Plugin=AudioLevel
Parent=mAudioPeak
Type=Peak
Channel=R

========================================
; Meters
========================================
[sClip]
Shape=Rectangle 0,0,5,5 | Fill Color #Red# | StrokeWidth 0
Y=r
Hidden=1

[sPeak]
Shape=Rectangle 0,0,2,5 | Fill Color #AquaDark# | StrokeWidth 0
DynamicVariables=1
Y=r

[sBar]
BarOrientation=Horizontal
BarColor=#Green#,70
SolidColor=#White20#
W=200
H=5
Y=r

;-------------------------------------
[OutBarL]
Meter=Bar
MeasureName=mLeft
MeterStyle=sBar

[ClipL]
Meter=Shape
MeterStyle=sClip
X=5R

[PeakBarL]
Meter=Shape
MeterStyle=sPeak
X=([OutBarL:X]+[OutBarL:W]*[mPeakLeft])

;-------------------------------------
[OutBarR]
Meter=Bar
MeasureName=mRight
MeterStyle=sBar
Y=2R

[ClipR]
Meter=Shape
MeterStyle=sClip
X=5R

[PeakBarR]
Meter=Shape
MeterStyle=sPeak
X=([OutBarR:X]+[OutBarR:W]*[mPeakRight])

audpeak.gif

[sl23]

Thanks for the attempt

However, it doesn't hold the peak, it drops slightly after it hits the peak and is not a stable peak indicator.

Maybe it's not being understood? I don't know how to explain better than this.

[Yincognito]

Maybe it's not being understood? I don't know how to explain better than this.

Just attach a short GIF from your Foobar / Winamp spectrum analyzer, that should make things clear visually. I suppose that is the behavior you want, regarding peaks.

[sl23]

Yes, it is the behaviour I'm looking for.
Never made a GIF before though, is there a program you recommend?
Thanks.

For now, there's the video I made!

[sl23]

Made a Gif to make it easier to see

FoobarPeaks.gif

Easier to see on the high frequencies. The Peaks go up as soon as they are 'hit' by the volume bar under it, then stay there for 1000ms, as that's the setting I made for it, then drops to the level of the next reading given by where the volume bar is at.

[sl23]

The reason your Peak level is 'sticking' is because you have the PeakGain (and RMSGain) set to 2.0 (displaying twice the actual level).
Reduce that to a lower level (1.0 ~1.5) to show normal Peak reactions in your skin.

If anything the Peak setting of 2.0 is not quite a true value and the default will barely register on any of my apps.
I checked with Foobar, MuLab and OcenAudioEditor. I used the same track on Foobar and OcenAudioEditor.
At the current setting of 2.0, here are the results of comparison.
This is of course made with the assumption that the clipping of Rainmeter's VU meter is at 0db, which is an industry standard.
System volume affects the amount shown on the VU when I use HDMI output. When output is set to Speakers, you get a constant real time value regardless of system volume, which again, is how it should be.

Foobar v2 vs Rm
System Output: HDMI
System Volume: 90%
PeakGain=2.0
Notice that the peaks of both Foobar v2 and Rainmeter are roughly the same:

RM,Foobar.gif

foobar v1.gif from above post

OcenAudioEditor vs Rm
System Output: HDMI
System Volume: 90%
PeakGain=2.0
The peaks of OcenAudio are pretty close to 0db, whereas Rainmeter's are still similar to when Foobar was playing the same track:

RM,Ocen.gif

MuLab vs Rm
System Output: HDMI
System Volume: 90%
PeakGain=2.0
Here I monitored the master rack's output. You can see it isn't far from 0db, top of the meter. But Rm's meter is a fair bit lower:

RM,ML.gif

Foobar v2 vs Rm
System Output: HDMI
System Volume: 90%
PeakGain=1.3
In contrast, here is Foobar v2, same track, at the same track position, but with the PeakGain set to 1.3. There is a huge difference between the two as now the Rm VU Peak is only halfway:

Rm,Foobar2.gif

Also notice how the Peaks work in all three apps. Nothing like Rm's Peak meters. I have had to try to emulate the proper Peak Hold to see it's true value.

The Peak meter only drops when the timer reaches 1000 ms, but rises regardless of the timing if the value exceeds it's current state.
NEVER drops until 1000 ms. ALWAYS rises, but HOLDS the highest value until either 1000 ms or a higher value is given.

I don't expect this will ever be fixed, after all, it isn't meant for real world usage, but it just doesn't look right the way it works.
All it needs is the ability to hold the peak value for a user specified time like the rest of the parameters, eg, PeakHold=1000

[Yincognito]

I don't expect this will ever be fixed, after all, it isn't meant for real world usage, but it just doesn't look right the way it works.

I know that you probably used the word because it was a short and handy way of transmitting what you think, but, just to clarify...

As I said before, the Type=Peak in AudioLevel does not need to be "fixed" just because it doesn't have a Hold setting, and whether it looks right or not is an entirely subjective matter.

Take a look here, they have professional references at the end of the page, so I reckon most of it is the standard there:
https://www.mathworks.com/help/audio/ref/audiolevelmeter-system-object.html
Nowhere on that page is a "hold peak" property mentioned, so peaks behave more or less like AudioLevel ones (bar some differences in the log10 formulas, by briefly looking at the AudioLevel source code I mentioned earlier).

On the other hand, here is an opposite example, where a hold setting does exist:
https://obsproject.com/kb/audio-mixer-technical-details

So, basically, having a hold or not has nothing to do with being right / wrong or correct / incorrect from a professional perspective, in order to need "fixing", it's simply a convenient setting to have for the user to better be aware of what the peak level is - given our "delayed" reaction when we see something (e.g. seeing right away, comprehending taking a while, translating into numbers taking a while, comparing the numbers with some other point of reference also taking a while, etc). We as humans, generally need the peak to hold because we're too slow to do the entire thinking process above in real time, or better said, as fast as the non-holding peaks move.

[sl23]

I see your point, but you also have proved mine.

Maybe fixed is the wrong word. Right and wrong don't exist. They are nothing more than human constructs, ideas. But they are useful terms to describe a correct path to your destination.

Your description of humans being too slow is indeed the whole purpose of peak hold, so we can physically see if the peak has gone over the 0db threshold and therefore clipped the signal.

As clipping is always an unwanted artifact of audio production, and that recording from noisy sources, such as mics, require you to set recording volumes high as possible, you need a peak hold so you can get as close to 0db without clipping.

So my description of Rm being 'wrong' is in fact correct from my perspective as my goal is to maximise the signal whilst avoiding clipping. But as Rm was designed purely with 'entertainment' value in mind then, yes, I understand I am also wrong for expecting it to be something it isn't.

That said, I am a perfectionist, and believe that if you're going to do something, do it right. Right in this instance is as I described above, which is from a professional audio engineers perspective. No audio engineer would be able to work from that kind of peak hold set up, it's literally not possible and is actually pointless from that perspective. So 'fixed' is the correct term from that perspective. Is it not? If the CPU monitoring wasn't right, it would be 'fixed', why? Because it has a definitive purpose. There is no room for error. But as the VU Peak meter has no defined way of working, it is open to interpretation. But the interpretation for something like this should be from the standpoint of a pro audio engineer. That is, of course, only my opinion, but shouldn't it be how it works to ensure correct and proper usage for everyone?

I'm not trying to be argumentative, or arrogant, or attack you or anyone here, sorry if it appears so. My aim is to explain that there is a perfectly valid reason why peak hold exists, and why there should be a peak hold setting in the plugin.

[Yincognito]

Yep, sure thing. I only meant that it's not technically wrong either way, but obviously it's more convenient to have a Hold setting from the user perspective.

So, do the peaks in your skin behave like you want to now? Cause the gif previews you posted don't look bad from that perspective (not sure about their precision or decrease though)...

[sl23]

It's better, but then I doubt it'll ever be how I would like it.
The decrease isn't so much of an issue really, it's mainly the increase. When louder volumes are given, the peak meters don't quite respond quickly enough. So the RMS VU meters exceed the Peak volume, which obviously shouldn't happen.
They also, occasionally 'stick' when maxed out for over the delay time.

I was just hoping that maybe this could be updated (not fixed ) so it could be used to properly gauge the peaks.