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 81604 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: foo_vis_spectrum_analyzer

Reply #700 –
Quote from: pqyt on
Quote from: Defender on
In case of MCH channels SL and SR are displayed but do not show the volume anymore. This was fine in the previous version.
Have you selected the channels for display? Note the comment in the release notes:

"The level values were not calculated correctly when the selected channels did not correspond to the channel configuration of the track."

Absolutely.
In 6ch and 8ch it won't show SL+SR. For reference old Peakmeter next to it displaying 8 channels.

If 6ch has SL+SR it doesn't show SL+SR. If 6ch has BL+BR instead they do show) (unless I have DSP rear to side ON).

Re: foo_vis_spectrum_analyzer

Reply #702 –
Hi,
the peak meter shows wrong values now. When I play a track that has a true peak (calculated at 8x oversampling) at 0,3, the component shows more than 3. All other plugins show proper values (SPAN, built-in foobar peak meter and many others).
Now the componet alnmost always shows red (above 0) which is ridiculous. I have original pressings made in the 1980s that very rarely go above 0 and usually have DR12. Please reverse to the previous calculations that were correct.

Re: foo_vis_spectrum_analyzer

Reply #703 –
Quote from: Defender on
Some samples.

It just won't show values on SL and SR.
Confirmed. There was a bug in the algorithm if the channel configuration contained a non-continuous channel selection. A complicated way of saying: I messed up.

Re: foo_vis_spectrum_analyzer

Reply #704 –
Quote from: wojak on
Hi,
the peak meter shows wrong values now. When I play a track that has a true peak (calculated at 8x oversampling) at 0,3, the component shows more than 3. All other plugins show proper values (SPAN, built-in foobar peak meter and many others).
Now the componet alnmost always shows red (above 0) which is ridiculous. I have original pressings made in the 1980s that very rarely go above 0 and usually have DR12. Please reverse to the previous calculations that were correct.
I don't know what true peak and the impact of oversampling is. And multiple users who are, I assume, in the know confirmed the current results. The SOS test suite also shows that the dBFS values are correct.

Maybe there's an extra parameter that I don't know of (yet) but the current algorithm is correct.

Re: foo_vis_spectrum_analyzer

Reply #705 –
v0.7.5.4, 2024-04-13

* Peak Meter
  * Changed: Swiched the unit from dB to dBFS.
  * Fixed: Some channel configurations (e.g. with side channels) were not displayed correctly.

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

Re: foo_vis_spectrum_analyzer

Reply #706 –
Quote from: pqyt on
Quote from: wojak on
Hi,
the peak meter shows wrong values now. When I play a track that has a true peak (calculated at 8x oversampling) at 0,3, the component shows more than 3. All other plugins show proper values (SPAN, built-in foobar peak meter and many others).
Now the componet alnmost always shows red (above 0) which is ridiculous. I have original pressings made in the 1980s that very rarely go above 0 and usually have DR12. Please reverse to the previous calculations that were correct.
I don't know what true peak and the impact of oversampling is. And multiple users who are, I assume, in the know confirmed the current results. The SOS test suite also shows that the dBFS values are correct.

Maybe there's an extra parameter that I don't know of (yet) but the current algorithm is correct.

I think that others said earlier that RMS was wrong (I do not know, maybe it was, and maybe now it is ok). I say that now Peak is wrong (and it was ok earlier). All my tracks show above 0 and the newer ones are above 3. Those are lossless (not mp3 with some extended peaks).  SACDs, HDCDs, "audiophile recordings" ... all go above 0..which is just not true. Now the component shows different peaks than every other component - are all of them wrong? 
I assume that you increased RMS by 3 (maybe that is what it should be) but you also increased Peaks which were OK and now are too high by 3.

Re: foo_vis_spectrum_analyzer

Reply #707 –
Quote from: pqyt on
v0.7.5.4, 2024-04-13

* Peak Meter
  * Changed: Swiched the unit from dB to dBFS.
  * Fixed: Some channel configurations (e.g. with side channels) were not displayed correctly.

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

0,7,5,4 seems to show proper Peaks.
Thank you.

EDIT: No, it still goes very red while other meters do not with the same tracks.

Re: foo_vis_spectrum_analyzer

Reply #708 –
Quote from: pqyt on
v0.7.5.4, 2024-04-13

* Peak Meter
  * Changed: Swiched the unit from dB to dBFS.

GREAT, really great job! Thank you!
RMS meter is OK - please do not touch it and do not try to change anything in it  :) 
But PEAK meter is not correct.
Peak meter embedded in Foobar works OK and its readouts are very OK, just like in every DAW. Your PEAK meter shows values a bit higher then it should be.
Screenshot 1:
1kHz, -30dBFS
The precisely calibrated meter should show -30dBFS RMS and -30dBFS PEAK
Screenshot 2:
Pink noise -20dBFS RMS
PEAK Meter in Foobar vs your PEAK meter = different values

Re: foo_vis_spectrum_analyzer

Reply #709 –
Quote from: misio on
But PEAK meter is not correct.
Peak meter embedded in Foobar works OK and its readouts are very OK, just like in every DAW. Your PEAK meter shows values a bit higher then it should be.

Screenshot 1:
1kHz, -30dBFS
The precisely calibrated meter should show -30dBFS RMS and -30dBFS PEAK
Screenshot 2:
Pink noise -20dBFS RMS
PEAK Meter in Foobar vs your PEAK meter = different values
The peak is currently just the absolute maximum sample per chunk. Each chunk size is determined by the number of FFT bins and the sample rate.

Is there another definition?

Re: foo_vis_spectrum_analyzer

Reply #710 –
Maybe it would be good to display Peak values besides the RMS values? Either momentary (those would change a lot) or the highest value that occured in the track (that would not change a lot and it would remain unchanged after the track reached its Peak Timstamp)?

Re: foo_vis_spectrum_analyzer

Reply #711 –
I looked at the code. Analysis.cpp line 694 adds 3 dB to Peak value making it incorrect.

Re: foo_vis_spectrum_analyzer

Reply #713 –
How do I enable tooltips on this component's PeakMeters?

Re: foo_vis_spectrum_analyzer

Reply #714 –
Quote from: pqyt on
Not anymore.

What do you mean? The source still shows peak is divided by 1/sqrt(2) when converting the float to dB, which adds 3 dB to its value.

I have trouble accepting the supposed "RMS+3" standard that makes RMS show nonsensical numbers, but if pro-people really need things to works that way I suppose I have to accept it. But for peaks this is 100% wrong thing to do.

Getting off topic again, but I'd still like to see some specs explain where the idea came from to make RMS artifically match peaks. It's such a weird concept.

Re: foo_vis_spectrum_analyzer

Reply #716 –
Quote from: Case on
Getting off topic again, but I'd still like to see some specs explain where the idea came from to make RMS artifically match peaks. It's such a weird concept.
No, it is not a weird idea.
RMS+3 is used as standard RMS scale in every DAW, pro audio editor or stand alone meters like RTW. One can find it in DIGICheck by RME -> screenshot. Some VST plugins allow to chose the scale RMS/RMS+3

There is a very interesting topic, where you can find a lot of info why RMS+3 is so commonly used:
https://gearspace.com/board/mastering-forum/387136-i-need-correct-rms-meter.html
Please pay attention to Bob Katz's posts.

And maybe this help you more - AES17 / Standard method for digital audio engineering / Measurement of digital audio equipment:
https://www.tc.faa.gov/its/worldpac/Standards/aes17.pdf

Another off topic. Is it possible to fix built in Foobar RMS meter just to show values according to AES17 standard?




Re: foo_vis_spectrum_analyzer

Reply #717 –
Quote from: pqyt on
Quote from: Case on
Quote from: pqyt on
Not anymore.
What do you mean? The source still shows peak is divided by 1/sqrt(2) when converting the float to dB, which adds 3 dB to its value.
I thought you meant the dBCorrection factor. That's gone.

If the peak is not supposed to be corrected by 1/sqrt(2), I'll remove it.


It seems that you already know what is causing the wrong Peak (not RMS) measurings. Please bring back the pre 0,7,5,3 version of Peaks (it was OK).

Re: foo_vis_spectrum_analyzer

Reply #718 –
Hello! I really like your work!
I have several suggestions to improve the visual style of the indicator:
1. Please add a separator between channels. I drew a rough picture of how I see it.
2. The RMS level should be averaged not over time, but over the size of the FFT block. Let me explain:
Averaging over time causes the peaks to twitch unnaturally, as if the computer is unable to render. When I set the block size to more than 16384 in the "Transform - Fourier Transform" settings, the RMS indicator move smoothly and beautifully. And also the current numerical value of RMS does not change so often, I have time to understand what is happening.
Unfortunately, with this setting, the peak indicator also begins to “smooth out”, so I ask you to make this setting only for RMS.
And one more thing: the maximum rendering speed is 63-64 frames per second with a monitor (and settings) limit of 100 ::)
Sorry for the poor English, I try to express my thoughts as best as possible.

Re: foo_vis_spectrum_analyzer

Reply #719 –
I had read that gearspace thread before, I think multiple times too. But I had not had the IEC 61606:1997 standard mentioned there until your links the other day. The IEC paper tells procedures how to measure analog devices, the AES17 paper tells how to measure digital equipment.

Neither describe how to calibrate an RMS meter or what RMS meter should show. They specify how to measure the performance of the device and how to report the results. The AES paper says that if you use the measurement techniques from the paper you should mention that in the footnotes of the data.

And the papers report terminology they use to describe the tests. That's very important so anyone testing things using these means can perform the tests identically.
These papers don't say anywhere that the 997 Hz full scale sine wave should be reported as having RMS of 0 db FS.

What they do tell you to do is to use the 997 Hz sine as reference level against which to report the dB differences in some of the tests.

Basically the reason RMS meters should lie and show 3 dB more is because Bob Katz says that's how all ancient RMS meters worked. I can't find any historical evidence to suggest that to be true. Here's for example some very ancient RMS meter that clearly doesn't match 0 dB RMS to 1 volt: https://i.ebayimg.com/images/g/4vEAAOSwh5ViDSJT/s-l1600.jpg

Re: foo_vis_spectrum_analyzer

Reply #720 –
Quote from: kor5n on
Hello! I really like your work!
Thx
Quote from: kor5n on
1. Please add a separator between channels. I drew a rough picture of how I see it.
There's a 1 pixel gap between the bars. You want it bigger?
Quote from: kor5n on
2. The RMS level should be averaged not over time, but over the size of the FFT block. Let me explain:
Averaging over time causes the peaks to twitch unnaturally, as if the computer is unable to render. When I set the block size to more than 16384 in the "Transform - Fourier Transform" settings, the RMS indicator move smoothly and beautifully. And also the current numerical value of RMS does not change so often, I have time to understand what is happening.
Unfortunately, with this setting, the peak indicator also begins to “smooth out”, so I ask you to make this setting only for RMS.
There's an RMS window setting that goes up to 5 seconds to smooth the RMS calculation independent of the chunk size.
Quote from: kor5n on
And one more thing: the maximum rendering speed is 63-64 frames per second with a monitor (and settings) limit of 100 ::)
Another user in the thread has no problem with it even though I did not change anything. Could it be a GPU driver setting?

Re: foo_vis_spectrum_analyzer

Reply #721 –
Quote from: Case on
I had read that gearspace thread before...
There is a lot of info on internet about RMS+3 AES17 standard.
https://gearspace.com/board/mastering-forum/358907-s-aes17-not.html
https://www.soundonsound.com/forum/viewtopic.php?t=56155
https://discourse.ardour.org/t/calculating-rms-in-digital-audio/109812?page=2
But if you do not agree with the AES17 you can make a petition to the Audio Engineering Society to change the standard.
Do not forget to sent a mail to Steinberg (and also to other companies) to change theirs meters in Nuendo DAW  ;D
https://steinberg.help/nuendo/v8/en/cubase_nuendo/topics/loudness/loudness_master_meter_r.html

Re: foo_vis_spectrum_analyzer

Reply #722 –
Quote from: pqyt on
There's a 1 pixel gap between the bars. You want it bigger?
Yes! I don't see him. And on the Spectrum it is clearly visible.
Quote from: pqyt on
There's an RMS window setting that goes up to 5 seconds to smooth the RMS calculation independent of the chunk size.
Unfortunately, this is not at all what I expect to see... Please see how your setting is applied in comparison with what I want to get in the end.
Perhaps I'm thinking incorrectly. Or I turn on the wrong setting.
Sorry if Google Drive links are not allowed.
Quote from: pqyt on
Another user in the thread has no problem with it even though I did not change anything. Could it be a GPU driver setting?
I have an Intel Arc video accelerator, you can expect anything from it. All graphics applications on the system are allowed maximum performance. To be fair, on the AMD Radeon R9 390X the module behaves similarly.

Re: foo_vis_spectrum_analyzer

Reply #723 –
Quote from: pqyt on
Quote from: kor5n on
1. Please add a separator between channels. I drew a rough picture of how I see it.
There's a 1 pixel gap between the bars. You want it bigger?

In the current version 0.7.5.4 there sometimes is no gap at all. Maybe he had that situation, since Kor5n said he draw a picture with a gap.

Might be a good idea to make the interbar gap configurable.

Re: foo_vis_spectrum_analyzer

Reply #724 –
Quote from: kor5n on
Quote from: pqyt on
There's a 1 pixel gap between the bars. You want it bigger?
Yes! I don't see him. And on the Spectrum it is clearly visible.
I cleaned up the calculations in the next version to better handle edge cases. Maybe I'll make the gap configurable.

Quote from: kor5n on
Quote from: pqyt on
There's an RMS window setting that goes up to 5 seconds to smooth the RMS calculation independent of the chunk size.
Unfortunately, this is not at all what I expect to see... Please see how your setting is applied in comparison with what I want to get in the end.
Perhaps I'm thinking incorrectly. Or I turn on the wrong setting.
Sorry if Google Drive links are not allowed.
Which smoothing method do you use? ("Common" page). It should be set to "Average" to reduce jitter.

Quote from: kor5n on
Quote from: pqyt on
Another user in the thread has no problem with it even though I did not change anything. Could it be a GPU driver setting?
I have an Intel Arc video accelerator, you can expect anything from it. All graphics applications on the system are allowed maximum performance. To be fair, on the AMD Radeon R9 390X the module behaves similarly.
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.