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 69333 times) previous topic - next topic
Musique-Rabbit and 3 Guests are viewing this topic.

Re: foo_vis_spectrum_analyzer

Reply #750
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.
Have you considered the old Peakmeter was wrong?

The old plugin has tooltips that show Peak MAX and RMS max. Can you enable those as well?
I put it on the list.

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.
No x64/x86/CUI/DUI crashes here.

Re: foo_vis_spectrum_analyzer

Reply #751
Hello pqyt
I have detected an anomaly in the latest version. If you enable Leds in Peak Meter mode (Image1) and mark Left and Right (Image2) it does it correctly, but if you disable Left and Right (Image3) only the Left channel is displayed. In the previous version it did it correctly.

Re: foo_vis_spectrum_analyzer

Reply #752
Have you considered the old Peakmeter was wrong?

Of course. But the value of the old Peakmeter Spectrum (easy to check in the tooltip) is exactly the same as the one from the modern Loudness Peakmeter plugin.

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.
No x64/x86/CUI/DUI crashes here.

I thought it would have something to do with foo_ui_hacks but that is not the case. Only thing that's probably different in my CUI/x86 is the fact I use transparency. I tested by disabling transparency on the panel that your  plugin(s) live in, but that did not help.
Disabling transparency on all panels that depend on it for a small test is just way too much work (all SMP panels and all splitters and a lot of plugins that support it have transparency enabled).

Re: foo_vis_spectrum_analyzer

Reply #753

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.

Consider me no expert - I just judge those readings by eye/ear and in comparison to other known (established?) meters. For ex. if I measured the files (with RG) and they say they have peak (true-peak) at -0,5 and your plugin and other "similar" plugins say that it is more or less -0,5 - I'm happy. There were two previous version of this plugin that said it was 2,5 (by eye) so it was different than RG and every other player plus those files did not clip (I suppose they should with peaks at 2,5). So I reported that your peaks were to high. Now they look OK to me.

As for RMS - I just made a live comparison of readings while playing a track and it was like that:
- your component with +3 disabled showed the same values as VST TT Dynamic Range Meter and the same as VST dpMeter5 and the same as VST Span (that one with DBFS+3 set). If I  changed Span to DBFS (without +3) it showed 3 more than all the others (inluding yours which was with +3 disabled). So it seems (again judging by eye) that your RMS set to 0 shows what other show and when set to +3 it shows different values than others.

So to me (as an amateur) it seems that Peaks now are OK and RMS might be too high by 3. Or in other word: to make all those 4 meters show the same values I have to set yours to 0 (+3 disabled) and Span to DBFS+3. Other two do not have those options to change but show the same values.

Re: foo_vis_spectrum_analyzer

Reply #754
As for RMS - I just made a live comparison of readings while playing a track and it was like that:
- your component with +3 disabled showed the same values as VST TT Dynamic Range Meter and the same as VST dpMeter5 and the same as VST Span (that one with DBFS+3 set). If I  changed Span to DBFS (without +3) it showed 3 more than all the others (inluding yours which was with +3 disabled). So it seems (again judging by eye) that your RMS set to 0 shows what other show and when set to +3 it shows different values than others.

So to me (as an amateur) it seems that Peaks now are OK and RMS might be too high by 3. Or in other word: to make all those 4 meters show the same values I have to set yours to 0 (+3 disabled) and Span to DBFS+3. Other two do not have those options to change but show the same values.
@wojak, would you please download one of the test files from https://www.soundonsound.com/techniques/sos-audio-test-files, preferably one with a dBFS number on the file name (e.g. 1_mono tone 1kHz -20dBFS 44k.wav or 19_Pink Noise stereo 20Hz_20kHz -23dBFS 44k.wav) and let us know what readings you get with other plugins?

Re: foo_vis_spectrum_analyzer

Reply #755
As for RMS - I just made a live comparison of readings while playing a track and it was like that:
- your component with +3 disabled showed the same values as VST TT Dynamic Range Meter and the same as VST dpMeter5 and the same as VST Span (that one with DBFS+3 set). If I  changed Span to DBFS (without +3) it showed 3 more than all the others (inluding yours which was with +3 disabled). So it seems (again judging by eye) that your RMS set to 0 shows what other show and when set to +3 it shows different values than others.

So to me (as an amateur) it seems that Peaks now are OK and RMS might be too high by 3. Or in other word: to make all those 4 meters show the same values I have to set yours to 0 (+3 disabled) and Span to DBFS+3. Other two do not have those options to change but show the same values.
@wojak, would you please download one of the test files from https://www.soundonsound.com/techniques/sos-audio-test-files, preferably one with a dBFS number on the file name (e.g. 1_mono tone 1kHz -20dBFS 44k.wav or 19_Pink Noise stereo 20Hz_20kHz -23dBFS 44k.wav) and let us know what readings you get with other plugins?

1_mono tone 1kHz -20dBFS 44k.wav:
- your component at 0: 20/20 (RMS/PEAK)
- your component at +3: 17/17
- vst TT Dynamic Range Meter: 20/20
- Span at DBFS: 23/20
- Span at DBFS+3: 20/20
- dpMeter: 23/20
- youlean loudness meter: 23/20

So it seems that RMS should be as @Case said - lower by 3 (or third option: -3).
Peak seem OK but one strange thing that your component also shows 17 as peak when +3 while all others show 20 no matter if +3 or not.

Re: foo_vis_spectrum_analyzer

Reply #756
As for RMS - I just made a live comparison of readings while playing a track and it was like that:
- your component with +3 disabled showed the same values as VST TT Dynamic Range Meter and the same as VST dpMeter5 and the same as VST Span (that one with DBFS+3 set). If I  changed Span to DBFS (without +3) it showed 3 more than all the others (inluding yours which was with +3 disabled). So it seems (again judging by eye) that your RMS set to 0 shows what other show and when set to +3 it shows different values than others.

So to me (as an amateur) it seems that Peaks now are OK and RMS might be too high by 3. Or in other word: to make all those 4 meters show the same values I have to set yours to 0 (+3 disabled) and Span to DBFS+3. Other two do not have those options to change but show the same values.
@wojak, would you please download one of the test files from https://www.soundonsound.com/techniques/sos-audio-test-files, preferably one with a dBFS number on the file name (e.g. 1_mono tone 1kHz -20dBFS 44k.wav or 19_Pink Noise stereo 20Hz_20kHz -23dBFS 44k.wav) and let us know what readings you get with other plugins?

1_mono tone 1kHz -20dBFS 44k.wav:
- your component at 0: 20/20 (RMS/PEAK)
- your component at +3: 17/17
- vst TT Dynamic Range Meter: 20/20
- Span at DBFS: 23/20
- Span at DBFS+3: 20/20
- dpMeter: 23/20
- youlean loudness meter: 23/20

So it seems that RMS should be as @Case said - lower by 3 (or third option: -3).
Peak seem OK but one strange thing that your component also shows 17 as peak when +3 while all others show 20 no matter if +3 or not.
OK. I fold. ;-)

Re: foo_vis_spectrum_analyzer

Reply #757
But the Peaks seem OK to me (by eye), those also seemed OK from the beginning. Only two or three version from a few days ago seemed wrong and now it seems OK again with music (and weird with this one test file but only with +3 which should not change peaks as it is supposed to recalibrate RMS only).

I again propose to implement text peak values as it would make the comparison with other meters easier. Other meter usually show the max value of the track up to the present point (the highest value reached from the beginning of the track to "now") and not the actual momentary value.

Re: foo_vis_spectrum_analyzer

Reply #758
But the Peaks seem OK to me (by eye), those also seemed OK from the beginning. Only two or three version from a few days ago seemed wrong and now it seems OK again with music (and weird with this one test file but only with +3 which should not change peaks as it is supposed to recalibrate RMS only).

I again propose to implement text peak values as it would make the comparison with other meters easier. Other meter usually show the max value of the track up to the present point (the highest value reached from the beginning of the track to "now") and not the actual momentary value.
See the screenshots from the quick hack above. I never expected this to be more difficult than the curve representation of the spectrum...

Re: foo_vis_spectrum_analyzer

Reply #759
Hello pqyt
I have detected an anomaly in the latest version. If you enable Leds in Peak Meter mode (Image1) and mark Left and Right (Image2) it does it correctly, but if you disable Left and Right (Image3) only the Left channel is displayed. In the previous version it did it correctly.

Apparently you missed this message:
https://hydrogenaud.io/index.php/topic,125031.msg1043133.html#msg1043133

Just download and install the newest version 0.7.6.1.

Re: foo_vis_spectrum_analyzer

Reply #760
Ok
Thank you

Re: foo_vis_spectrum_analyzer

Reply #761
I just let Foobar v2.2 x64 and 1.6.17 both update from version 0751 to 0762 of Spectrum Analyzer, and while I only use the spectrum bars format I find its display is now the best to date.  FWIW, the only non-identical adjustments I have between the two Foobars is that in v2.2 for Common I use smoothing method Peak/.9 and in 1.6.17 I use Average/.3.

Great work on 0762, pqyt!


Re: foo_vis_spectrum_analyzer

Reply #763
Please provide more details about what you think is wrong.
There are multiple Gaussian-like curves (asides the sidelobes from window function) that is not present in my own spectrum analyzer project on CodePen, even on the same window function and FFT settings (4096 samples Hann-windowed FFT) on a 50Hz test tone (though not tested on my own fb2k with foo_vis_spectrum_analyzer as it is obvious on the screenshots by someone else even if the audio source is not a test tone)

Maybe you can do rigorous testing to make sure that the results between these two are the same so long as the settings between your component (a C++ port of my own project, algorithm-wise) and my own project (not just this, but also another one) are the same as eachother (if applicable)?
Ah, I forgot to attach the 50Hz tone file and BTW, this should look like this within the default configuration (aside the color scheme resembling fb2k built-in "Spectrum" visualization and 20Hz-20kHz range):
X

Re: foo_vis_spectrum_analyzer

Reply #764
Hi, I got a crash while adjusting this parameter to the extreme high


Re: foo_vis_spectrum_analyzer

Reply #765
Hi, I got a crash while adjusting this parameter to the extreme high
Not trying to be "smart" but if you play with putting wild settings in the parameters you can crash almost anything.

Re: foo_vis_spectrum_analyzer

Reply #766
Hi, I got a crash while adjusting this parameter to the extreme high
@Fabcore , that's not extreme high. Can you attach a preset that causes a crash? Also, which version of the component are you using?

Re: foo_vis_spectrum_analyzer

Reply #767
Not trying to be "smart" but if you play with putting wild settings in the parameters you can crash almost anything.
I'd say valid reason to crash because of "wild" settings is very rare. Running out of memory can potentially be an ok reason to crash, but for a normal PC that would usually require allowing the user to do something totally insane. For example if the component allowed user to scale the background image to something requiring gigabytes of memory to store, allocating the memory for that would most likely fail. If such allocation fails the component could quietly disable the album art, show an error, or crash. It all depends on how or if the programmer decides to handle errors.
I'd also call it a bug if a component allows selecting settings it can't handle.

I'm not claiming foo_vis_spectrum_analyzer does anything wrong, just commenting generally about your statement.

Re: foo_vis_spectrum_analyzer

Reply #768
Hi, I got a crash while adjusting this parameter to the extreme high
@Fabcore , that's not extreme high. Can you attach a preset that causes a crash? Also, which version of the component are you using?
I realize that the value he had in the screenshot is not "extreme"--heck mine is higher--but he referred to the "parameter" itself so I don't know what he had been inserting there that provoked the post.

Case, point taken, and Fabcore, no accusation intended, but I just get peeved when I get the impression that a brilliantly performing app is just getting poked to death by attempts to "let's see what way-off entry can make it misbehave."

Re: foo_vis_spectrum_analyzer

Reply #769
@pqyt

First of all thank you for this excellent tool. I can (almost) get rid of 18 instances of PeakMeter Spectrum by substituting them with 6 instances of yours.
 
Since peakmeter is working perfectly in 100% windows scaling, I moved on to testing this plugins behavior with different windows scaling and encountered problems in all scaling (except 200% and 300%). Happens both in horizontal and vertical peakmeters. The rest of this message will only address the vertical peakmeter (without axe legends).

See the attached jpg's that also displays some debug information. I also included the code I use to determine the panel width for the number of channels and windows scaling.

The following text looks quite complicated but is more easy if you look at the jpg.
Based on how your plugin behaves/displays I guess you are calculating barwidth (vertical peakmeter) by first determining the total gauge gap by first multiplying the (unscaled) configuration value gauge gap times the number of channels (bars) to be displayed minus 1. Then I guess you scale this total gauge gap, subtract that value from the panelwidth and divide the result by the number of channels to find barwidth per bar. By scaling a calculated unscaled total gauge gap this value will be to high (except winth 200% and 300%), and subsequently your barwidth/barheight will be lower than I intended.
When you display bars, you apply single gauge gaps between channels leading to pixels that are left over and are distributed to the left of leftmost bar and to the right of rightmost bar.

In the attached jpg I included my scaled total gauge gap is 14 and I'm pretty sure you use 15.75 either truncated to 15 or rounded up to 16. Which leads to the behavior I described above.

Code: [Select]
// UNSCALED
$ifgreater($get(channels),7, $puts(px.h_bar, 13), // 13 max to display Above logo with Top plugin disabled
$ifgreater($get(channels),5, $puts(px.h_bar, 13), // 13 max to display Above logo with Top plugin enabled
$ifgreater($get(channels),4, $puts(px.h_bar, 14), // 15 max to display Above logo with Top plugin enabled
$ifgreater($get(channels),3, $puts(px.h_bar, 16), // 20 max to display Above logo with Top plugin enabled
$ifgreater($get(channels),2, $puts(px.h_bar, 21), // 27 max to display Above logo with Top plugin enabled
$ifgreater($get(channels),1, $puts(px.h_bar, 21), // 41 max to display Above logo with Top plugin enabled
$puts(px.h_bar, 32) // 83 max to display Above logo with Top plugin enabled
))))))

$puts(mx.w_bar,         6) // Unscaled - Single bar width - Desired unscaled bar width for PeakMeter vertical

$puts(wh_gauge_s,       1) // Unscaled - Single gauge gap - Desired unscaled gauge gap
$puts(wh_gauge_t,       $mul($sub($get(channels),1),$get(wh_gauge_s))) // Unscaled - Total  gauge gap

$puts(px.h_std,         $add($get(wh_gauge_t), $mul($get(px.h_bar),$get(channels)))) // Unscaled - Panel height needed - PeakMeter horizontal
$puts(mx.w_std,         $add($get(wh_gauge_t), $mul($get(mx.w_bar),$get(channels)))) // Unscaled - Panel width  needed - PeakMeter vertical


// SCALED
$puts(wh_gauge_s,       $muldiv($get(wh_gauge_s),%scale%,100)) // Scaled - Single gauge gap - truncated
$puts(wh_gauge_t,       $mul($sub($get(channels),1),$get(wh_gauge_s))) // - Total  gauge gap - calculation based on truncated scaled single gauge gap / NOT BASED BY SCALING UNSCALED TOTAL GAUGE GAP

$puts(px.h_bar,         $muldiv($get(px.h_bar),%scale%,100)) // Scaled - Single bar height - truncated - PeakMeter horizontal
$puts(mx.w_bar,         $muldiv($get(mx.w_bar),%scale%,100)) // Scaled - Single bar width - truncated - PeakMeter vertical

$puts(px.h_std,         $add($get(wh_gauge_t), $mul($get(px.h_bar),$get(channels)))) // Scaled - Panel height needed - PeakMeter horizontal - calculation based on truncated scaled single bar height / NOT BASED BY SCALING UNSCALED TOTAL BAR HEIGHT
$puts(mx.w_std,         $add($get(wh_gauge_t), $mul($get(mx.w_bar),$get(channels)))) // Scaled - Panel width  needed - PeakMeter vertical - calculation based on truncated scaled single bar width / NOT BASED BY SCALING UNSCALED TOTAL BAR WIDTH


In my opinion calculation should be as follows:
1) Scale the single gauge gap and store the result truncated in an integer.
2) Calculate total gauge gap by multiplying the value of 1) times the number of (channels minus 1)
3) Deduct from the panel width the value of 2) and width needed for 1/2 axe legends
4) Divide the value of 3) by the number of channels and store the result truncated in an integer (barwidth per bar)
5) ... continued with total leftover pixels and distribution to the left & right of the panel

I think the issue lies in 1) and 2). In my code it is the two lines under // SCALED.

Please investigate ...

Re: foo_vis_spectrum_analyzer

Reply #770
@pqyt

When you use a horizontal peakmeter (in 100% scaling) alignment is perfect if you do not use a legend on top or bottom. The topmost bar will align with the top of the panel and the bottom bar will align with the bottom of the panel when panel height is allotted by me calculated by channels x barheight + gauge size x (channels-1).

The moment I display 1 or 2 horizontal legends the bottom bar does not align anymore with the bottom of the window you paint in the panel I allotted. There is always a gap of 2 pixels between the bottom of the bar and the bottom of the window you paint (left side legend displays channels in full panel height). The same gap is on top, but that one is not noticed that much because the legend is on top of it.

As a result I cannot align the bottom of the bottombar with all other plugins I display. I cannot compensate for this behavior since 1) I do not know if a legend is displayed and 2) even if I lower the panel by 2 pixels that would still not align since in that case the left legend would be displayed too low.

Can you please change this behavior and use the 2 pixels below bottombar and 2 pixels above topbar (and under top legend) for bar display (there's still plenty of space to the legend on top of the topbar)?

 

Re: foo_vis_spectrum_analyzer

Reply #771
Hi @pqyt

thank you for your awesome plugin. I have a newbie question, I have installed v0.7.6.2 (Foobar2000 v2.1.4 32bit), if I set the Frame Counter on and at the same time I try to change the Refresh Rate Limit to 100Hz or 200Hz the counter always shows about 60 fps. My monitor refresh rate is 144Hz (correctly set in Windows display options). Is the bar animation always capped to about 60 fps maximum ? Thank you in advance