VUMeter Plugin

[BoringName]

About the needle action.

I have played around with the two new sample sliders, and it seems an interesting option.
Yet at the moment I think that some optimal setting for the two can be decided on that will work well for all needles, and it may not need to be an additionally available setting option.

Yes but when you think about it, the sole reason I added those sliders in was because you questioned the movement and I added in a method for you to adjust it. No one else mentioned it. Not saying they didn't care or that you shouldn't care but it's probably a subjective thing and even if we do come up with something that you find is accurate, someone else will say they preferred it the other way.

Here's an interesting discovery I made about this:

I was curious about the needle action of professional VU meters.
Reading some articles on it revealed that the needle should go from ∞ to 0 dB in 300 ms. (for a 1kHz sine wave)
Then I started fooling around with AIMPs MobilityNegative and MobilityPositive settings to see if I could get it to have such a response, and I found that the values that are set for those correspond to exactly that.
So if you set the value to 0.3, it takes the needle 300 ms to travel that distance.
0.1 makes it take one second, etc.
(why the hell didn't they just name it RiseTime and FallTime?)

I think the strange naming is just a translation thing.

If you set the sample number to 15 it slows the movement down a bit because it's spreading out the average which is essentially what needs to happen to slow down the needle.

At default settings it takes a sample every 15ms and averages 10 of those values. It's set to draw at 60 frames a second which is every 16.67ms. I don't do any magic to make the needle move. I just get the values from Musicbee, average them out and then draw the needle to whatever angle that average equates to. Because it's happening so fast it looks like the needle is moving around when really it's a new needle every frame drawn at a different angle. I don't keep track of previous needle locations.

Based on that, if the peak value drops from 1.0 to 0, it will take 150ms before all 10 samples are zero and the needle will get drawn 9 times to convey that movement.
Change the samples to 15 and it will take 225ms before all the samples are zero and the needle will get drawn 13 times to convey that movement.

Other than manipulating those settings I really don't know how else to do it. You are effectively changing the read out of the meter if you slow down how long it takes to get somewhere which is what changing the number of samples does. It smooths out the peaks. Which you can see in your previous post, at the beginning of the animation anyway, my meter peaks higher than the slower moving AIMP version.
https://getmusicbee.com/forum/index.php?topic=41692.msg227554#msg227554

Two other things that I hope can be improved upon:

- audio/graphics sync is still not great, the needle trailing a little bit behind the music.
- the needle often seems a bit nervous and jumpy. It's especially noticeable with thinner needles and fast moving needles.
  Could it be that the frame-rate of the needle image is a bit low?

Not sure on a solution for the sync issue. Isn't it always going to be behind the music because it's an average of the last 150ms? (at default settings)

Increasing the sample number reduces the nervousness of the meter. I have noticed I need to give the meter more time for the needle to come back down before I stop the process when the music is paused/stopped. With higher sample numbers it gets half way down and then just jumps to the end which doesn't look good.

Thinner needles are probably not going to look good in general if they are low resolution. Everything is scaled to the window size which means moving pixels around, at certain angles this might mean they appear even thinner which would probably make them look more jumpy. I did play around with Antialiasing on my other plugin but the results were not great.

(I hope you're still having fun with this ;-)

Not sure if fun is the right word, especially staring at formulas for hours at a time but I do get some satisfaction from making things work.

And a final observation for now:

I previously queried the audio device directly which would have been post everything.

Now I'm getting it from the MusicBee API. Any changes you want there would have to be done by Steven. I think he may get it from the bass.dll as he mentioned BASS in the thread when he implemented the peak value api call.

edit:
And something I thought I reported earlier, but it seems that I didn't:

I noticed that the plugin seems to ignore the value that is set for ZeroLevel?
So when e.g. having 'ZeroLevel=-3', the needle should indicate -3dB at the zero level position, but instead it always uses 0dB.
Similarly, I'm not sure what it does with MaxLevel, if anything?

It would be good if it did use/respect these values, since it is useful for some skins to be able to set e.g.  MaxLevel to 0dB and ZeroLevel to -6dB.
And same as the fall/rise aspect, it's also a factor in existing AIMP skins behaving as they are intended to.
 

I only use the ZeroLevel for calculating the logarithmic formula between MinLevel and ZeroLevel. But I think I did that before I realised you can never get a peak reading above zero with a digital source so I could have just used zero. I don't use MaxLevel at all because the max level is always zero and I can't see a reason anyone would want to set it below zero.

Can you give an example of when you would want to use those settings as you suggested? If the peak reading is 0db why would you want the meter to display -3db? Can't you just set the ZeroAngle value so it points at -3db on the meter and that will give you the same result? That will change the increment positions for all values but that will happen with either method.

After all this discussion about trying to make the meters accurate, it seems a bit weird to want options that do the opposite. I get your suggesting to make the skins work exactly as they do in AIMP but I don't see the point of mimicking something just because that's how it was unless it's actually going to be useful to people. Getting the movement better I understand, some of this other stuff not so much.

[sveakul]

I agree on having an option to display metering before and after any DSP/VST effects are applied.

With the new 1.4 plugin and the latest Hiccup meters I am finding a much lower level when set to linear; however, it seems to me that those levels resemble what the built-in MusicBee "visualiser: volume" (NOT the wavebar)  meter showed, which always seemed unusually low to me.  Whether that is due to the built-in also being "linear", or to when it took the measurement (before or after DSP/VST)  I don't know.

At any rate, the current plugin and the newest hiccup meters now have a more pleasing and higher level that seems much more realistic and in the ballpark of the bar-type VU meters that sort of "flooded" Foobar after the JavaScript3 plugin was modified last month to pass audio data.  This is with linear off and the default values of the "Sample" sliders--the latter I haven't tried experimenting with.

I do agree with hiccup that the ideal is to implement a design confidence that accurately represents the actual audio across a range of styles without the need for head-scratching "tuning" ("is it 'better' or 'worse' now?) by the user.  Of course, World Peace would be great too  

Looking forward to seeing BoringName's personal touch-ups on some of the LVU style meters.  I can confirm that there is now discussion between the AIMP developer and author of the LVU 1.2 meter (instigated by moi) on allowing the former access to the LVU source code to personally fix the problems with the DLL throwing virus detections.  While the 1.2 version's primary feature was introducing 64-bit compatibility, the author had addressed some past memory use and response issues for both the 32-bit and 64-bit versions.

[hiccup]

Yes but when you think about it, the sole reason I added those sliders in was because you questioned the movement and I added in a method for you to adjust it. No one else mentioned it.

Well, I am observing some issues with the needle movement, and I have done my best to describe and analyse that as best as I can.
That I am the first and only user that does so, doesn't make it a non-existent issue.

If you set the sample number to 15...
At default settings it takes a sample every 15ms.
if the peak value drops from 1.0 to 0, it will take 150ms...
Change the samples to 15 and it will take 225ms...

Thanks for explaining, it's interesting to get this detailed information about what is making the magic happen.
But I have the luxury to respond (and think) as an end-user, commenting on what I see in the end-result and reporting when I think something (in my opinion) is off could be improved on.

So I believe my comment about how the needle of an 'actual VU meter' is supposed to react is a valid one, and it would be a good starting point if the needle of your plugin could be made to have such action.
What sample slider settings do you suggest to get the needle moving from ∞ to 0dB in 300 ms? And vice-versa?

Not sure on a solution for the sync issue. Isn't it always going to be behind the music because it's an average of the last 150ms? (at default settings)

I have no clue.
It's just that I notice the VU meter of AIMP acting more instantly and better synced.
As some of my GIFs also demonstrated.
I also looked at the Cooledit Nostalgia plugin. It's a different beast of course, but that one also seems to respond very fast.
So they my be doing something different in sampling the audio. No idea.

Increasing the sample number reduces the nervousness of the meter. I have noticed I need to give the meter more time for the needle to come back down before I stop the process when the music is paused/stopped. With higher sample numbers it gets half way down and then just jumps to the end which doesn't look good.
Thinner needles are probably not going to look good in general if they are low resolution. Everything is scaled to the window size which means moving pixels around, at certain angles this might mean they appear even thinner which would probably make them look more jumpy. I did play around with Antialiasing on my other plugin but the results were not great.

Interesting, and all valid points of course.
But my observations are also based on the wider 'needle' of AL-65.
I noticed that when that needle moves fast, e.g. from 0 dB to ∞ in a very short time, there are very few inbetween positions that can be observed. The AIMP implementation seems to be drawing more images for the same period of time, making the needle look smoother.
But it's difficult to compare or make a proper analysis of what is going on exactly.

Now I'm getting it from the MusicBee API. Any changes you want there would have to be done by Steven. I think he may get it from the bass.dll as he mentioned BASS in the thread when he implemented the peak value api call.

Hm, that is a bit of a problem.
As I said, most of my music has ReplayGain values that decrease the volume quite a bit, so with default settings, there is not much needle action left.
Using the mouse-wheel could correct that, but the possibility for pre- vs. post would be a much better solution I think.
Pre using the original signal as it is, post using the signal after volume slider, EQ., ReplayGain, VST plugins and whatever.

Can you give an example of when you would want to use those settings as you suggested? If the peak reading is 0db why would you want the meter to display -3db? Can't you just set the ZeroAngle value so it points at -3db on the meter and that will give you the same result? That will change the increment positions for all values but that will happen with either method.

Because many AIMP meters will have been designed like that.
They will have some visual 'zero' position on the scale where they want the needle to be when the signal is at -3dB, and the needle reaching the end of the scale at 0dB.
Not saying that they could have left that out and only use 0 dB for the end point, but that is how it is.

If your plugin does not use these values, these AIMP skins will not have needle action beyond their ZeroPoint, so they will not work as intended.

After all this discussion about trying to make the meters accurate, it seems a bit weird to want options that do the opposite.

I don't really understand what you are saying here.
Hopefully my additional explanation on all these points has cleared things up some more.

I'm not trying to just 'mimic' things for the sake of mimicking.
I'm trying to be helpful with getting VUMeter to:
- look and act more like an actual VU meter in it's needle action (or at least have the option to accomplish that)
- be as much compatible with existing AIMP skins so that they will work as intended by their creators

[hiccup]

Here are just some observations on the 'red zone' of a VU meter and the purpose and usefulness of peak indicators:

While for an audio player a red zone or peak indicators are not very useful, they are of course in the audio production stages.
In audio recording and production, a VU meter will often be calibrated to 0dB actually being something like for example -17 LUFS.

The reason being that the purpose of a VU meter is to show average 'perceived' levels, and the needle moving around the 0 area is something to aim for for the loudest passages.
It may also go beyond that a bit without it creating any distortion or clipping problems, because the use of 24bit audio provides more than enough headroom for that.

This was what was causing some disconnect in my brain when considering the purpose of a red zone or peak indicators for a VU meter in a player such as MusicBee.

It's a bit of comparing apples with pears, but, since the red zone is an acceptable area for recording and production work for the needle to (briefly) be in, it would make sense to have a consumer VU meter also passing the 0dB indicator for loud passages.

I'm just sharing this thought because we've discussed the fact if the needle in a plugin like this one would (or should) ever go beyond 0dB.
I know believe that it should/could.

And peak indicators could be useful if there is an option for post-processed indicators.
Then they could give some indication when the user is using too much pre-amp or has set EQ levels too high.
In that case it might be useful to have the option for a dedicated clipping indicator light.
But that's probably a too complicated thing to have or add as a feature.

Just sharing.
 

[sveakul]

It's a bit of comparing apples with pears, but, since the red zone is an acceptable area for recording and production work for the needle to (briefly) be in, it would make sense to have a consumer VU meter also passing the 0dB indicator for loud passages.

I'm just sharing this thought because we've discussed the fact if the needle in a plugin like this one would (or should) ever go beyond 0dB.
I know believe that it should/could.

And peak indicators could be useful if there is an option for post-processed indicators.
Then they could give some indication when the user is using too much pre-amp or has set EQ levels too high.

I completely agree with all your points here.

[BoringName]

I was a bit tired yesterday and probably should have had a nap instead of posting in that mindset. I was also a little miffed after spending quite a bit of time getting those slider options working (it was more complicated than it should have been) thinking the best thing moving forward was for you to be able to adjust the movement yourself instead of me posting iterations for you to evaluate. Only to be told they probably are not necessary....

I was also a bit dismissive of things because to me it seemed some of the options are not necessary with how I have implemented it and were a result of how the original author did it. eg) with the LVU meters the start_point and finish_point values serve absolutely no purpose and in a few of the skins were not even accurate anyway.

I'll try and find a meter with values for ZeroLevel that are not 0 as I still can't get my head around what you mean. Having the ZeroLevel set to -3db doesn't mean anything to the plugin as it has no idea where -3db is on the meter (AIMP wouldn't know either). ZeroAngle is the setting that tells the addon where to point the needle when the level is zero. Same goes for MaxLevel, if it's set to anything above zero it can't have any effect because that level is never returned by musicbee or the audio device. Maybe ZeroLevel should be a way to apply a db offset? I can see a use for MaxAngle to stop the needle moving past the edge of the meter if someone uses a really high db offset. Anyway, I will look into it further.

I think I have an idea on "behind the beat" issue. I'm currently just averaging the peak values. I'll try using the formula for RMS instead. From preliminary tests I think that will allow the needle to ramp up faster without making it more jumpy.

I'm just sharing this thought because we've discussed the fact if the needle in a plugin like this one would (or should) ever go beyond 0dB.
I know believe that it should/could.

The only way to get the needle in the red is to configure the skin to overshoot zero or set a db offset with the mouse wheel. It's impossible to get peak values from musicbee or the audio device to give a reading above zero. I'm really not that keen on manipulating the value based on other plugins and/or track gain values.

edit: Thinking about it more I think ZeroLevel is just a way to change the gap between increments. Currently the needle spans from MinAngle to ZeroAngle and the level range is spread across that span. Currently I have that set from MinLevel to Zero. Setting a ZeroLevel below zero would mean the increments between levels on the meter would be further apart as there is less range to fit in the MinAngle to ZeroAngle span. I need to find a meter designed with a ZeroLevel that isn't zero so I can confirm.

[BoringName]

I had a bit of an epiphany in the universal think machine (shower) this morning and have a method to implement the mobility settings but I'm having weird results in AIMP. It seems the values for positive and negative are scaled differently. If set to the same value the needle goes from ∞ to 0 a lot quicker than 0 back to ∞. This is in AIMP so it's not something I've stuffed up.

I was curious about the needle action of professional VU meters.
Reading some articles on it revealed that the needle should go from ∞ to 0 dB in 300 ms. (for a 1kHz sine wave)
Then I started fooling around with AIMPs MobilityNegative and MobilityPositive settings to see if I could get it to have such a response, and I found that the values that are set for those correspond to exactly that.
So if you set the value to 0.3, it takes the needle 300 ms to travel that distance.
0.1 makes it take one second, etc.
(why the hell didn't they just name it RiseTime and FallTime?)

Here you can see how AIMP is correctly applying 1 sec. fall/rise, and VUMeter™ is not:

Just confirming you had the MobilityNegative set to 0.3 in that test. From what I was reading it's supposed to be in the range of 0.00 and 0.10. Setting your AcuVU skin to 0.3 MobilityNegative makes for a very erratic meter in AIMP. It's normally 0.03 which takes about 3.5 seconds to drop from 0 to ∞.

I have a feeling AIMP isn't averaging anything either. I think it's just taking the peak values and letting the mobility settings smooth out the meter which I guess has a similar effect.

Just need someone to confirm they are seeing the same thing as me in regards to the positive and negative scaling differently before I spend time on it.

edit: AIMP using the peak values and not doing any kind of average would also explain why my version is a bit behind..... I think.

[sveakul]

@ BoringName and hiccup: the AIMP LVU plugin has been updated to version 1.2.1, following the AIMP developer's direct work with its author xrEngline on fixing the issues with the virus alerts after my request/plea to him to do so.  You can download it now on the AIMP website:  https://www.aimp.ru/?do=catalog.download&id=834 .

It is presented with filename "LVU.aimppack" the extension being a zip variation like Foobar's ".fb2k-component."  It can be renamed LVU.zip if desired.  It contains both 32-bit and 64-bit versions and a couple of stock skins.  The file produced only 3 hits on Virus Total, all heuristic, and no objections at all from Windows Defender during download, installation, or use.  The DLL has had dramatic performance improvements since 1.11; CPU/GPU usage on Windows 11 x64 with an I7-13700 and Intel Graphics UHD 770 is 4%/2% here when using the stock LVU-Simple skin.

This meter the short time I've had so far to test is a very active one, with peaks regularly into the red on almost all material.  I believe it must be reading the "post-DSP/VST" signal, and I've confirmed this by turning off and on the DSP/VST and EQ in real-time while a selection is playing.  With those off, the meter peaks/reaction become extremely similar to VUMeter 1.4 almost immediately.

One kind of maddening thing was that earlier today the LVU thread contained a back-and-forth in Russian between the AIMP developers and the plugin author on tweaking needle performance, *.ini settings, etc. for the new version--but these comments have all been removed now!  I have asked if they are still available somewhere to read.

Have fun playing with this.

[hiccup]

Just confirming you had the MobilityNegative set to 0.3 in that test. From what I was reading it's supposed to be in the range of 0.00 and 0.10. Setting your AcuVU skin to 0.3 MobilityNegative makes for a very erratic meter in AIMP. It's normally 0.03 which takes about 3.5 seconds to drop from 0 to ∞.

I have a feeling AIMP isn't averaging anything either. I think it's just taking the peak values and letting the mobility settings smooth out the meter which I guess has a similar effect.

Just need someone to confirm they are seeing the same thing as me in regards to the positive and negative scaling differently before I spend time on it.

edit: AIMP using the peak values and not doing any kind of average would also explain why my version is a bit behind..... I think.

I'll do some repeated testing again tomorrow.
I would hate it if I provided false information to you.
It's quite easy to make dumb mistakes or interpret things the wrong way...
About the Mobilty+- settings that were used:
What I saw, described, and made GIFs of was with using the exact skins (and so those ini settings) that I provided in the download link for the test files.

PS
I completely understand you getting a bit frustrated when you have created something that you believe is going to be 'the solution' (I thought the sample sliders were pretty brilliant when I first saw what you did with that), and then you don't get completely enthusiastic feedback on it.
For the record: I did not say it was useless or anything like that. I only said that I believed that it might be the case that after finding some optimal balance for them, that could well be a setting that will work well for pretty much all cases,  and there might not be a need for end-users to be able to make further tweaks to them. So having (keeping) the option to adjust them MIGHT prove to be unnecessary.
But that was and still is a bit of a guess of mine.
Another consideration would be that IF different slider settings give better results for different skins or 'needle type',  users would need to adjust these sliders every time they change VU meter skins.
It would be much better (in my opinion) if such information could be derived from the skin's ini.
And Mobility+- seems to be the best and only available option for that.


It would be great if other users with interest in the matter could also do some serious and detailed testing all this and possibly confirm things or give their opinion on things.

I'll be back, probably tomorrow.

[hiccup]

@ BoringName and hiccup: the AIMP LVU plugin has been updated to version 1.2.1, following the AIMP developer's direct work with its author xrEngline on fixing the issues with the virus alerts after my request/plea to him to do so.

That's great, well done sveakul!
I myself won't probably be testing this or reporting back on it soon though. I would first like to focus my testing on the needle action.
After that I'm going to test, whine, complain and make tiring demands and suggestions about the action of peak lights ;-)

[BoringName]

One kind of maddening thing was that earlier today the LVU thread contained a back-and-forth in Russian between the AIMP developers and the plugin author on tweaking needle performance, *.ini settings, etc. for the new version--but these comments have all been removed now!  I have asked if they are still available somewhere to read.

Have fun playing with this.

I'll have a read of the thread before I think about installing it just to see if they detail how they stopped the virus reports.

There isn't much to those skins in the ini files. Nothing really related to performance exactly. The DBS section is just a list of 2 values - Decibel and pixels. |-40;200| means it should display 200 pixels of the needle image when the level is -40 decibels. The more values listed in the DBS section, the smoother the movement would be.  I've seen some with 100 values and some with 11.

As for the speed of the needle/LED there is nothing to change that in the ini file. Does the plugin have any options from within AIMP?

[BoringName]

I've got my head around the ZeroLevel thing now. I downloaded probably 30 skins and didn't find a single one that had it set to anything but zero. So I just used AcuVu and changed it's ZeroLevel to -4 and loaded it up in AIMP.

ZeroLevel is effectively an offset but it's kind of backwards. If it's set to -4, the needle will point to -16 instead of -20, if it's set to 4 it points to 24. This offset is across the whole range so when set at -4 the needle will point at zero when it would normally point at -4 decibels. It makes sense, the reason I was having issues with it was the ZeroAngle already told it where to point when at zero. But the ZeroAngle is also used to calculate the span between it and the MaxAngle because a lot of meters use a different scale above zero.


The distance between 0 and +6 is a lot smaller than -6 and 0. If you just use db offset to add 1.0db, it will end up pointing to +3 instead of where it should point (1/3 of that distance). I'll get that sorted out.

[sveakul]

I'll have a read of the thread before I think about installing it just to see if they detail how they stopped the virus reports.

As for the speed of the needle/LED there is nothing to change that in the ini file. Does the plugin have any options from within AIMP?

No, they don't "detail" how they stopped the reports, but neither did un4seen during the bass-zip "virus" false positive scare that stopped some from downloading MusicBee.  3 detections out of 67 vendors, 2 of which are heuristic and 1 "cloud",  I consider fixed.

There are no options for the meter within AIMP.  I don't have the expertise to comment on what the ini file may be able to do, and have only looked at 3 or 4.  In the right hands, who knows?  

[hiccup]

The distance between 0 and +6 is a lot smaller than -6 and 0. If you just use db offset to add 1.0db, it will end up pointing to +3 instead of where it should point (1/3 of that distance). I'll get that sorted out.

True.
When I designed that VU meter skin, I was under the impression that the area beyond 0 dB was useless since the needle (in an audio player) would never go there.
So I designed the scale to make optimal use of the available space for the  the ∞ to 0dB zone. (0% to 100%)
I even thought of leaving out any +dB 'red zone' completely, but for historical and visual reasons I thought to keep it, but minimise it as much as possible.
So since I didn't think the needle would ever travel there, and I had no idea how to possibly calibrate that part of the scale, that red zone is not calibrated in any way, and is to be considered some equivalent of the male nipple.
Not sure why it's there, but let's keep it.

Do you think I should change the scale and its red zone indicators somehow?

[BoringName]

When I designed that VU meter skin, I was under the impression that the area beyond 0 dB was useless since the needle (in an audio player) would never go there.

The same reason I didn't have much concern for the settings past zero, they seemed redundant. But as you pointed out, some users might want it to overshoot zero so they get a bit of red in their lives.

Do you think I should change the scale and its red zone indicators somehow?

The ini file might need to be changed first. You have a Maxlevel of 3 but the meter goes to +6. Which is ok if the MaxAngle is set to the 3 indicator. These 2 settings should be consistent.

Then just change the ZeroLevel to -6 and run it in AIMP with a test file. Once the level gets to -6 the needle will point to zero on your meter. Each level increase after that should correspond to where your indicators need to be placed. eg) when the level gets to -3, the needle will be pointing where you need to place the +3 indicator. -4 to +4 etc....

I haven't test it yet but the formula will probably be (MaxLevel / peakLevel) * (MaxAngle - ZeroAngle) where MaxLevel will need to be converted to peakValue but as a negative value

A few places specify 10 * log10(PeakValue) to convert peak values to decibels but I found the following formula closer based on the test files and the corresponding peak values. It's not 100% accurate but close.
decibel = 0.2119 + 8.867 * Math.Log(PeakValue);

And the other way
PeakValue = Math.EXP(-(decibel-0.2119)/-8.867);

I haven't used Excel in a while but LibreOffice has the LN and EXP functions if you want to do it in a spreadsheet.

So if you put -1 and -6 (MaxLevel). Based on your ini file, the formula would be
(0.496305364 / 0.872253390) * (55.946 - 43.609) = 7.02

The +1 decibel indicator should be 7.02 degrees past the ZeroAngle. Assuming I haven't stuffed any of that up....

edit: The angles might not line up if the MaxAngle in your ini file is actually pointing to +3 but hopefully you get the idea.

edit2: after testing in AIMP, it looks like I am completely wrong....something to sort out once I get these mobility settings figured out.