Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_vis_spectrum_analyzer (Read 80184 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_vis_spectrum_analyzer

Reply #725 –
Quote from: pqyt on
Which smoothing method do you use? ("Common" page). It should be set to "Average" to reduce jitter.
"Average" = 0.2. I have this setting on all modules. Increasing this parameter, of course, smooths out the RMS indicator, but reduces the jump of peaks. I consider this value is optimal.
Quote from: pqyt on
It has nothing to do with the performance of the GPU. Direct2D uses a buffer swap chain that is usually synced to the refresh rate of the monitor. In D2D I don't know of a setting to influence that.
The following plugins are always active on my screen: Waveform Minibar (mod) 1.2.58 and Oscilloscope (Direct2D) 1.1.0. The first has an update rate of 60 frames per second, the second - 100. Closing these plugins doesn't solve the problem. Maybe they should be unloaded? (i.e. delete?)

Re: foo_vis_spectrum_analyzer

Reply #726 –
I seem to remember the only difference between "mathematical" and "AES" RMS is 3dB, due to whether you reference a sine wave or a square wave. At the end of the day it's not very important/easy to add or subtract 3dB in one's head. The best pro meters are set for +3/AES by default, or allow you to choose.

Re: foo_vis_spectrum_analyzer

Reply #727 –
The wiki has been updated to provide a little more explanation about the various settings.

Re: foo_vis_spectrum_analyzer

Reply #728 –
Quote from: pqyt on
The wiki has been updated to provide a little more explanation about the various settings.
Also, don't forget about the images of what settings actually do (e.g. switching from FFT to IIR filter bank changes the shape of the spectrum response)

BTW, as the wiki is editable by everyone (not just you), these changes (necessary updates) to this wiki page shouldn't be listed on changelogs in this GitHub page nor this component repository page

Re: foo_vis_spectrum_analyzer

Reply #729 –
v0.7.6.0, 2024-04-16

* Peak Meter
  * Changed: Removed the 3.01 dB from the peak value.
  * Added: Option to allow the user to get readings compliant with IEC 61606:1997 / AES17-1998 standard (RMS +3).
  * Changed: Tweaked the coordinate calculations a bit to produce a more polished result.
  * Added: The gap between the gauges can be configured.
* Improved: The context menu will put a checkmark next to the last selected preset.

You can download it from the Component repository or from GitHub.

Re: foo_vis_spectrum_analyzer

Reply #730 –
Feature request for Peakmeter part (and to the extent, spectrum/spectrogram visualization): A feature to display Mid/Side representations of all stereo/surround pairs like this

This can be useful for letting me know if the particular song have phase-related/mono-compatibility issues, even though foobar2000 is not a DAW obviously

Re: foo_vis_spectrum_analyzer

Reply #731 –
There's some confusion with the settings in v0.7.6.0. Peak is now right as you don't do any extra calculations to it.
But RMS is incorrect. You always divide the real RMS value by 'Amax', which is the same as adding 3 dB to its value. Then in addition you offer an optional 3 dB addition to it.

Also the peak visualization bars go hidden here half the time (I have them moving horizontally from left to right). When I was playing stereo file, the right channel bar went invisible. I had to tweak the height of the UI element to make it visible. Then I played a mono file and now the size was incorrect for that size and it's invisible.
I don't think the bars should go invisible under any circumstances.

Re: foo_vis_spectrum_analyzer

Reply #732 –
Quote from: Case on
There's some confusion with the settings in v0.7.6.0. Peak is now right as you don't do any extra calculations to it.
But RMS is incorrect. You always divide the real RMS value by 'Amax', which is the same as adding 3 dB to its value. Then in addition you offer an optional 3 dB addition to it.
I just followed the article I quoted earlier. Like I said many times before: I'm not an audio engineer and don't understand this stuff half of the time. But when the specs are this confusing and 'people in the know' are debating definitions I prefer to stand by the sideline until the dust is cleared and a clear spec becomes available.

Edit: The current code produces correct(?) results with all the files I found here (https://www.soundonsound.com/techniques/sos-audio-test-files) and here (https://www2.iis.fraunhofer.de/AAC/multichannel.html).
Quote from: Case on
Also the peak visualization bars go hidden here half the time (I have them moving horizontally from left to right). When I was playing stereo file, the right channel bar went invisible. I had to tweak the height of the UI element to make it visible. Then I played a mono file and now the size was incorrect for that size and it's invisible.
I don't think the bars should go invisible under any circumstances.
It's a render bug caused by Direct2D or the driver. I thought I had solved it with the optimized calculations because I could no longer reproduce the bug here (after updating the GPU driver). It has to do with drawing the LED bitmap on odd coordinates. The filled rectangles don't have this problem, AFAIK.

Re: foo_vis_spectrum_analyzer

Reply #733 –
Quote from: pqyt on
Quote from: Case on
Also the peak visualization bars go hidden here half the time (I have them moving horizontally from left to right). When I was playing stereo file, the right channel bar went invisible. I had to tweak the height of the UI element to make it visible. Then I played a mono file and now the size was incorrect for that size and it's invisible.
I don't think the bars should go invisible under any circumstances.
It's a render bug caused by Direct2D or the driver. I thought I had solved it with the optimized calculations because I could no longer reproduce the bug here (after updating the GPU driver). It has to do with drawing the LED bitmap on odd coordinates. The filled rectangles don't have this problem, AFAIK.

I did a lot of testing this.

Horizontal peakmeter has this issue only for the bottom bar. Vertical peakmeter has the same issue for the left bar.

As you said ... does not happen when using gradient (eg no leds). Also does not happen when you display both legends on top and bottom of horizontal peakmeter (or to the left and right of vertical peakmeter).
So the issue is only when having 0 or 1 legend along the bar and you are using leds.

When this bar disappears the the Peak indicator for this disappeared bar is still shown correctly .

Easy to reproduce. Take a mono source or apply a DSP downmix to 1.0. Use only one legend on a horizontal peakmeter that has
LED mode enabled (add Peak indicator for reference).

If you allot a panel with a height of anything within 42 and 54 pixel's you will not see the mono bar at all, but you will see the Peakmeter indicator.

So you simply cannot display a mono channel PeakMeter using LED's and one legend.

The moment you change to gradients instead LEDS or display the second legend the PeakMeter appears.

Re: foo_vis_spectrum_analyzer

Reply #734 –
The Amax in the skippystudio explanation refers to maximum amplitude of the signal, which is 1.0. Their graph also perfectly shows that real RMS can't be as high as peaks.
So remove the division by Amax and things will be correct. Real RMS shows correct RMS, and the checkbox enables the 'RMS+3' mode.

I never saw disappearing bars with the old release.

Re: foo_vis_spectrum_analyzer

Reply #735 –
Like Case I also have been experimenting with varying the height of the panel that the horizontal LED Peakmeter lives in.

I use two different presets with the horizontal Peakmeter: No legend and 1 Legend (2 Legends simply takes too much space).

You cannot find a panel height that displays both presets correctly in case of 3 channel and 5 channel sources (or upmixes to 3 / 5 channels).

EDIT: By varying the panel height you can find optimums for 2ch, 4ch, 6ch and 8ch.

Re: foo_vis_spectrum_analyzer

Reply #736 –
Quote from: Case on
The Amax in the skippystudio explanation refers to maximum amplitude of the signal, which is 1.0. Their graph also perfectly shows that real RMS can't be as high as peaks.
So remove the division by Amax and things will be correct. Real RMS shows correct RMS, and the checkbox enables the 'RMS+3' mode.
Sorry @case but I'm not going to take your word for it. Removing the division causes all the test files from SOS to have a dBFS reading that is 3dB higher than their expected result. Even the tone://997 reference is wrong.

Re: foo_vis_spectrum_analyzer

Reply #737 –
Quote from: Defender on
Like Case I also have been experimenting with varying the height of the panel that the horizontal LED Peakmeter lives in.

I use two different presets with the horizontal Peakmeter: No legend and 1 Legend (2 Legends simply takes too much space).

You cannot find a panel height that displays both presets correctly in case of 3 channel and 5 channel sources (or upmixes to 3 / 5 channels).

EDIT: By varying the panel height you can find optimums for 2ch, 4ch, 6ch and 8ch.
I found a work-around by creating a bitmap that is larger than it should be (according to the documentation) and release a hotfix when it has been tested.
 

Re: foo_vis_spectrum_analyzer

Reply #738 –
Since we now have the ability to see "RMS" as text maybe it would be useful to also see "Peaks" as text. And to go further also "Peaks - RMS" - but what would that value be "equivalent" (sort of) of: momentary/short term DR (from the infamous plugin), momentary/short term PLR/PSR, momentary/short term LUFS, momentary/short term LRA or something else?

Re: foo_vis_spectrum_analyzer

Reply #739 –
Quote from: wojak on
but what would that value be "equivalent" (sort of) of: momentary/short term DR (from the infamous plugin), momentary/short term PLR/PSR, momentary/short term LUFS, momentary/short term LRA or something else?
I don't know what those readings are. Can you point me to some documentation or specs?

Re: foo_vis_spectrum_analyzer

Reply #740 –
Quote from: pqyt on
Sorry @case but I'm not going to take your word for it. Removing the division causes all the test files from SOS to have a dBFS reading that is 3dB higher than their expected result. Even the tone://997 reference is wrong.
It's not my word, that's the very definition of RMS: https://en.wikipedia.org/wiki/Root_mean_square#Definition.
You calculate the sum of values squared, divide by the number of values and take square root of that.
And removing the last division does not increase the result, I don't understand why you claim that. It causes the file labeled -20 dB to show -23 dB RMS, or -20 dB with the +3 mode enabled. And tone:// test is -3.0 dB / 0.0 dB.

Re: foo_vis_spectrum_analyzer

Reply #741 –
Quote from: wojak on
Since we now have the ability to see "RMS" as text maybe it would be useful to also see "Peaks" as text. And to go further also "Peaks - RMS" - but what would that value be "equivalent" (sort of) of: momentary/short term DR (from the infamous plugin), momentary/short term PLR/PSR, momentary/short term LUFS, momentary/short term LRA or something else?

Isn't that already available in the modern Loudness Peakmeter plugin?

https://hydrogenaud.io/index.php/topic,123953.msg1027603.html#msg1027603


Re: foo_vis_spectrum_analyzer

Reply #742 –
Quote from: Defender on
Quote from: wojak on
Since we now have the ability to see "RMS" as text maybe it would be useful to also see "Peaks" as text. And to go further also "Peaks - RMS" - but what would that value be "equivalent" (sort of) of: momentary/short term DR (from the infamous plugin), momentary/short term PLR/PSR, momentary/short term LUFS, momentary/short term LRA or something else?

Isn't that already available in the modern Loudness Peakmeter plugin?

https://hydrogenaud.io/index.php/topic,123953.msg1027603.html#msg1027603




It is there but Peak Meter (from vis...plugin) comsumes less power and is smaller on the screen and does not require the whole drawing of those readings.
Istead what we already have is graphic Peak (which I started to use instead of a built-in one), graphic RMS (which is VU meter if I understood your earlier discussion properly), text RMS (inside the graphic RMS) so I thought that it should be easy to also display the text version of Peak inside the graph (let's say beside the text RMS values). And if we have those two it should be easy to display the difference between them (but because I am not an expert I am not shure what value would it represent (LUFS/PLR (or rather PSR)/LRS/DR or something different). Just a suggestion - we would not have to use two components but one.

@pqyt - as for specs and documentation - I am sorry but someone with more knowledge that I have should help here. All Iknow comes from Wiki and other such places.

Re: foo_vis_spectrum_analyzer

Reply #743 –
Quote from: Case on
Quote from: pqyt on
Sorry @case but I'm not going to take your word for it. Removing the division causes all the test files from SOS to have a dBFS reading that is 3dB higher than their expected result. Even the tone://997 reference is wrong.
It's not my word, that's the very definition of RMS: https://en.wikipedia.org/wiki/Root_mean_square#Definition.
You calculate the sum of values squared, divide by the number of values and take square root of that.
And removing the last division does not increase the result, I don't understand why you claim that. It causes the file labeled -20 dB to show -23 dB RMS, or -20 dB with the +3 mode enabled. And tone:// test is -3.0 dB / 0.0 dB.
Again, I'm not an expert but isn't the confusion centered around dB and dbFS? Also, the mathematical RMS definition seems to get obfuscated by the audio world understanding of RMS.

If tone://997 is a pure 997Hz sine wave that is used as reference point of dBFS (the zero point), then shouldn't that show up with a 0 *dBFS* reading?

If a test file is published as -20dbFS, shouldn't that be rendered at -20dBFS?

If you want a *dB* reading and rendering, activate the RMS+3 toggle.

Re: foo_vis_spectrum_analyzer

Reply #744 –
Quote from: wojak on
Quote from: Defender on
Quote from: wojak on
Since we now have the ability to see "RMS" as text maybe it would be useful to also see "Peaks" as text. And to go further also "Peaks - RMS" - but what would that value be "equivalent" (sort of) of: momentary/short term DR (from the infamous plugin), momentary/short term PLR/PSR, momentary/short term LUFS, momentary/short term LRA or something else?
Isn't that already available in the modern Loudness Peakmeter plugin?

https://hydrogenaud.io/index.php/topic,123953.msg1027603.html#msg1027603
I thought that it should be easy to also display the text version of Peak inside the graph (let's say beside the text RMS values)
I'm not a fan of that because it will cause too much text to be drawn over the gauge. The current position of the text was decided by my laziness to write the code to give it it's own client area.

Re: foo_vis_spectrum_analyzer

Reply #745 –
Quote from: pqyt on
Quote from: wojak on
Quote from: Defender on
Quote from: wojak on
Since we now have the ability to see "RMS" as text maybe it would be useful to also see "Peaks" as text. And to go further also "Peaks - RMS" - but what would that value be "equivalent" (sort of) of: momentary/short term DR (from the infamous plugin), momentary/short term PLR/PSR, momentary/short term LUFS, momentary/short term LRA or something else?
Isn't that already available in the modern Loudness Peakmeter plugin?

https://hydrogenaud.io/index.php/topic,123953.msg1027603.html#msg1027603
I thought that it should be easy to also display the text version of Peak inside the graph (let's say beside the text RMS values)
I'm not a fan of that because it will cause too much text to be drawn over the gauge. The current position of the text was decided by my laziness to write the code to give it it's own client area.

Yes - too much text could be "annoying/ugly" but if there was an option to not display any text or only RMS or only Peak or both that would be users decision.

Re: foo_vis_spectrum_analyzer

Reply #746 –
Quote from: pqyt on
If tone://997 is a pure 997Hz sine wave that is used as reference point of dBFS (the zero point), then shouldn't that show up with a 0 *dBFS* reading?
In that reference, sure. In the so called RMS+3 scale.

Quote from: pqyt on
If a test file is published as -20dbFS, shouldn't that be rendered at -20dBFS?
Depends who published it and what it's meant to show. For example the sine waves from soundonsound have peaks at -20 dBFS so showing peaks at -20 dBFS is very valid. True RMS for such sine is 3 dB lower, -23 dB, 'RMS+3' display would be -20 dB.

Quote from: pqyt on
If you want a *dB* reading and rendering, activate the RMS+3 toggle.
When the toggle is off, you show 'RMS+3' values. When it's enabled you show RMS+3+3 dB. And adding the FS for full scale is just an accuracy increase, because dB alone doesn't tell what it is relative to. All values are of course relative to the digital full scale.

Re: foo_vis_spectrum_analyzer

Reply #747 –
Quote from: Case on
Quote from: pqyt on
If a test file is published as -20dbFS, shouldn't that be rendered at -20dBFS?
Depends who published it and what it's meant to show. For example the sine waves from soundonsound have peaks at -20 dBFS so showing peaks at -20 dBFS is very valid. True RMS for such sine is 3 dB lower, -23 dB, 'RMS+3' display would be -20 dB.

Quote from: pqyt on
If you want a *dB* reading and rendering, activate the RMS+3 toggle.
Quote from: Case on
When the toggle is off, you show 'RMS+3' values. When it's enabled you show RMS+3+3 dB. And adding the FS for full scale is just an accuracy increase, because dB alone doesn't tell what it is relative to. All values are of course relative to the digital full scale.
I have no new arguments and you still haven't convinced me. Maybe @misio can shed some light on the situation. He/She has been pushing me in the other direction. I don't care either way. But I can't follow 2 different expert opinions at the same time.

Re: foo_vis_spectrum_analyzer

Reply #748 –
Happy to say I'm not an expert.

I'm foremost interested in being able to discard the old Peakmeter Spectrum. For that I prefer this tool to mimic behavior of the old plugin. Old plugin shows 3dB less than this one (even with the +3dB disabled). So please implement it the same way or just make an extra tickbox in the configuration to do enable -3dB in order to mimic the old tool.

The old plugin has tooltips that show Peak MAX and RMS max. Can you enable those as well?

Maybe an idea to (optionally) also show LRA (or LUFS/PLR) whatever in the same tooltip. That way the user interface does not get cluttered.

Last point ... until now every version creates a hard crash to the desktop without logging when I accidentally Toggle full screen mode.
I don't care much if this will be solved, but please make it configurable not to show the Toggle Fullscreen on rightmouseclick.

Re: foo_vis_spectrum_analyzer

Reply #749 –
Ha, disappearing bottom bar seems to be fixed in 0.7.6.1 :-)

EDIT: Tested all combinations in channel based heights displaying anything between down/upmixed 1ch to 8ch. All good in preset without legend and preset with 1 legend. Thx.