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 94207 times) previous topic - next topic
Jackal29a and 10 Guests are viewing this topic.

Re: foo_vis_spectrum_analyzer

Reply #676
This is mostly offtopic, but can you explain why exactly that ancient IEC 61606:1997 spec is what should be followed, when both it and several of its replacements have been withdrawn and replaced by newer versions? Also can you point to a place where it can be acquired for free? I only see it being sold.

All the meters in pro audio world are calibrated according to AES-17/IEC 61606. This standard is not ancient! RMS meters are still in use and are implemented in every pro-DAW. Just download a demo of any pro-DAW and check it out.
Meters should be calibrated in some way. If meter is not calibrated then it is useless - it shows something but no one knows what.
For instance, a meter called "VU Meter" embedded in Foobar is not a VU meter at all. It is a RMS meter (a kind of) and its readouts are wrong. It could be repaired very simply I guess. It needs just +3dB more and RMS window = 600 ms.

Funny to how people can have different perspectives to plugins. I for instance don't care if the readouts are conforming to standard X or Y or just plain wrong. I'm here for the looks and eye candy.
I rely on things like replaygain to have a decent playing experience.

Re: foo_vis_spectrum_analyzer

Reply #677
It needs just +3dB more and RMS window = 600 ms.
@misio ,
Please explain or point me to an online resource. I'd like to learn. I never found a mention about an RMS time window.

Re: foo_vis_spectrum_analyzer

Reply #678
This is mostly offtopic, but can you explain why exactly that ancient IEC 61606:1997 spec is what should be followed, when both it and several of its replacements have been withdrawn and replaced by newer versions? Also can you point to a place where it can be acquired for free? I only see it being sold.

All the meters in pro audio world are calibrated according to AES-17/IEC 61606. This standard is not ancient! RMS meters are still in use and are implemented in every pro-DAW. Just download a demo of any pro-DAW and check it out.
Meters should be calibrated in some way. If meter is not calibrated then it is useless - it shows something but no one knows what.
For instance, a meter called "VU Meter" embedded in Foobar is not a VU meter at all. It is a RMS meter (a kind of) and its readouts are wrong. It could be repaired very simply I guess. It needs just +3dB more and RMS window = 600 ms.

Funny to how people can have different perspectives to plugins. I for instance don't care if the readouts are conforming to standard X or Y or just plain wrong. I'm here for the looks and eye candy.
I rely on things like replaygain to have a decent playing experience.
In the beginning I used to agree. But now that I get a better grasp on the math (still a very tiny grasp) why not make the effort to make it as accurate as possible?

Re: foo_vis_spectrum_analyzer

Reply #679
It needs just +3dB more and RMS window = 600 ms.
@misio ,
Please explain or point me to an online resource. I'd like to learn. I never found a mention about an RMS time window.
So called time window is scalable in ms. Usually is used 600 ms. The lower the value the speed of rms meter is faster. If the needle (bar) is moving too fast then it is hard to properly judge the loudness.
In Samplitude DAW 'time window' is marked as 'integration time'. In Samplitude default value = 2500 ms which is a bit strange.


Re: foo_vis_spectrum_analyzer

Reply #680
Please explain or point me to an online resource. I'd like to learn. I never found a mention about an RMS time window.

Just not to complicate to much it would be OK if your RMS meter shows the same readouts as so called 'VU meter' in Foobar but with values + 3dB. And the rms bar should not moving so fast.

Re: foo_vis_spectrum_analyzer

Reply #681
Fill works, thanks for the fix. Unfortunately, the artwork is disappearing again.

EDIT... I was playing with v0.7.5.1 and the artwork disappears as well, but only when you repeat a track. But the new version it just plain disappears half the time a track is played.

Re: foo_vis_spectrum_analyzer

Reply #682
The following article was more helpful: https://skippystudio.nl/2021/07/sound-intensity-and-decibels/
So it seems. To quote:
Quote
Now we have defined RMS for a sinus wave we can return to dBFS. In standard IEC 61606-3 we find the following definitions:

    Definition 3.4 dBFS. The RMS amplitude of a sinusoid described in 3.10 is defined as 0 dBFS, where the amplitude of any signal can be defined in dBFS as 20 times the common logarithm of the ratio of the RMS amplitude of the signal to that of the signal defined in 3.10.
    Definition 3.10 Full scale amplitude. Amplitude of a 997 Hz sinusoid whose peak positive sample just reaches positive digital full-scale (in 2’s complement a binary value of 0111…1111 to make up the word length) and whose peak negative sample just reaches a value one away from negative digital full-scale (1000…0001 to make up the word length) leaving the maximum negative code (1000…0000) unused.

BS EN 61606-1997 / IEC 61606-1997 - for free one can find it here:
https://www.doc88.com/p-67516226856665.html
Download is impossible but there is a full preview. Of course the main site needs translating.
Alright, I exported that to PDF and read through it a couple of times. I don't see it defining how RMS meters should work at all. It describes how to measure analog equipment characteristics.

Re: foo_vis_spectrum_analyzer

Reply #683
But the new version it just plain disappears half the time a track is played.
Aarrrgh. Sorry 'bout that. When? When a new track starts? When something happens in the configuration dialog? During normal playing? I have 3 event sources spread over 2 threads that I need to coordinate so the specific conditions do matter.

Re: foo_vis_spectrum_analyzer

Reply #684
Failed to load DLL: foo_vis_spectrum_analyzer.dll
Reason: Не вдалося знайти вказану процедуру. 

it was working fine, but after the update it crashes... i tried to install previous versions, but they all don't work now either, i installed it on a clean version of foobar - the result is the same

Re: foo_vis_spectrum_analyzer

Reply #685
1) allow to have different type of graph simultanously (ie. a spectrogram and some bars for example)
Just add another instance of the component with a different visualization.
2) allow the graphs to be rotated.
You can flip the graphs horizontally and vertically. I don't see the point of having an arbitrary rotation angle.

In fact, I wanted to be able to define a display similar to the one submitted on reply #434.
But for this, if I could easily rely on two vertically stacked component instances, I would need at least a vertically scrolling spectrogram.

In the same mood, If I want to get a bar graph at the right side of a regular scrolling spectrogram, I would need some kind of rotation.

Re: foo_vis_spectrum_analyzer

Reply #686
1) allow to have different type of graph simultanously (ie. a spectrogram and some bars for example)
Just add another instance of the component with a different visualization.
2) allow the graphs to be rotated.
You can flip the graphs horizontally and vertically. I don't see the point of having an arbitrary rotation angle.

In fact, I wanted to be able to define a display similar to the one submitted on reply #434.
But for this, if I could easily rely on two vertically stacked component instances, I would need at least a vertically scrolling spectrogram.
The waterfall spectogram is on my To Do list but not high. I haven't received any feedback about the spectogram so I assumed it was virtually not used.

Re: foo_vis_spectrum_analyzer

Reply #687
The waterfall spectogram is on my To Do list but not high. I haven't received any feedback about the spectogram so I assumed it was virtually not used.

[our messages crossed each other]

Combining the spectrogram with a musical scale (and a convenient mouse tooltip) is almost a cheatsheet for musician :)!

I understand that this would need some extra tweaks, but as the D2D1::Matrix3x2F parameter of the Element::SetTransform() method was already handling rotation (cf documentation here), I think that won't be too difficult and in any case would greatly improve your already wonderful component.

Re: foo_vis_spectrum_analyzer

Reply #688
The waterfall spectogram is on my To Do list but not high. I haven't received any feedback about the spectogram so I assumed it was virtually not used.

[our messages crossed each other]
I understand that this would need some extra tweaks, but as the D2D1::Matrix3x2F parameter of the Element::SetTransform() method was already handling rotation (cf documentation here), I think that won't be too difficult and in any case would greatly improve your already wonderful component.
If only it were that easy... true, for the bitmap that would work but not for the axes. They have to be hand-coded. Letters and numbers don't rotate that well in Western alphabets...

Re: foo_vis_spectrum_analyzer

Reply #689
The waterfall spectogram is on my To Do list but not high. I haven't received any feedback about the spectogram so I assumed it was virtually not used.

[our messages crossed each other]
I understand that this would need some extra tweaks, but as the D2D1::Matrix3x2F parameter of the Element::SetTransform() method was already handling rotation (cf documentation here), I think that won't be too difficult and in any case would greatly improve your already wonderful component.
If only it were that easy... true, for the bitmap that would work but not for the axes. They have to be hand-coded. Letters and numbers don't rotate that well in Western alphabets...
You're right. But you'll already did the hard job for an horizontal scale on the bar graph, and a vertical one for the current spectrogram implementation...

Comparing with the core spectrogram is revealing that the graphic zone is erased and redrawn quite often, noticeably at song change.

Re: foo_vis_spectrum_analyzer

Reply #690
But the new version it just plain disappears half the time a track is played.
Aarrrgh. Sorry 'bout that. When? When a new track starts? When something happens in the configuration dialog? During normal playing? I have 3 event sources spread over 2 threads that I need to coordinate so the specific conditions do matter.

It can happen in normal play and skipping tracks.

Re: foo_vis_spectrum_analyzer

Reply #691
But the new version it just plain disappears half the time a track is played.
Aarrrgh. Sorry 'bout that. When? When a new track starts? When something happens in the configuration dialog? During normal playing? I have 3 event sources spread over 2 threads that I need to coordinate so the specific conditions do matter.
It can happen in normal play and skipping tracks.
As a pop-out window? Or embedded? I really need more details. It never happens here.

Re: foo_vis_spectrum_analyzer

Reply #692
v0.7.5.3, 2024-04-13

* Improved: Peak Meter
  * Added style to display the peak and RMS values larger than 0dB.
  * Added style to display the top peak value.
  * RMS Window is now configurable. Defaults to 300ms. This makes the RMS value more stable. The RMS is relative to 0 dBFS + 3.01 dB.
  * The level values were not calculated correctly when the selected channels did not correspond to the channel configuration of the track.
* Fixed: Overlap of the X-axis labels (Regression)

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

Special thanks to @Case for helping me with the confusing results during development.

Re: foo_vis_spectrum_analyzer

Reply #693
v0.7.5.3, 2024-04-13
  * RMS Window is now configurable. Defaults to 300ms. This makes the RMS value more stable. The RMS is relative to 0 dBFS + 3.01

It is going better but still not OK.
I try to explain as simple as I can.
One picture is better then hundred words so take a look at the picture.
RMS readout embedded in Foobar meter is wrong - it shows -23dBFS
Your RMS meter shows -17dBFS
But the correct value should be -20dBFS
The Bob Katz's calibration file is prepared to show exactly -20dBFS RMS
Just download that file and check it out yourself: https://www.file.io/YGvo/download/vwcD5yyftPHK
That file in properly calibrated meter will show -20dBFS RMS and -11.3dBFS Peak

And thank you very much for scalable RMS Window!!!
It is really a great job, mate!

It will be a very useful meter if you fix the readouts.
RMS+3dB standard means that this wrong RMS readout which one can see in embedded Foobar meter (called VU meter) can be very simply fixed by just adding 3dB more.

Re: foo_vis_spectrum_analyzer

Reply #694
Quick response.

Found the color settings for >0dB and the Max (with gravity or fade-out). Very nice.

I'm (also) struggling with the much higher output levels which are not comparable to all other plugins I'm using (ChannelSpectrum, PeakmeterSpectrum, VU Meter).
Is there a setting to turn down the notch a bit?

EDIT: Hmmm, however if I play with RG set to trackmode and Preferences/Playback/PreAmp is set to 0.0dB your peakmeter go exactly to 0.0dB in the loud parts, which is I think how RG is intended.

Re: foo_vis_spectrum_analyzer

Reply #695
v0.7.5.3, 2024-04-13
  * RMS Window is now configurable. Defaults to 300ms. This makes the RMS value more stable. The RMS is relative to 0 dBFS + 3.01
Your RMS meter shows -17dBFS
That's the +3 dB (which I explicitly add to the calculated value). The scale is dB, not dBFS. Please see my previous question:

Most examples I see use dB as a unit, even though it's a relative number. Is it better practice to display dBFS?

Re: foo_vis_spectrum_analyzer

Reply #696
In case of MCH channels SL and SR are displayed but do not show the volume anymore. This was fine in the previous version.

Re: foo_vis_spectrum_analyzer

Reply #697
That's the +3 dB (which I explicitly add to the calculated value). The scale is dB, not dBFS. Please see my previous question:
Most examples I see use dB as a unit, even though it's a relative number. Is it better practice to display dBFS?

In every DAW there is always dBFS scale - always. This is the most common scale today in the world of digital audio. No matter if it is ProTools, Samplitude, Wavelab etc. you will find there meters i dBFS. Some plugins (like freeware Voxengo Span) allow to choose the scale: RMS dBFS, RMS dBFS+3, K-Metering or LUFS.

Re: foo_vis_spectrum_analyzer

Reply #698
That's the +3 dB (which I explicitly add to the calculated value). The scale is dB, not dBFS. Please see my previous question:
Most examples I see use dB as a unit, even though it's a relative number. Is it better practice to display dBFS?

In every DAW there is always dBFS scale - always. This is the most common scale today in the world of digital audio. No matter if it is ProTools, Samplitude, Wavelab etc. you will find there meters i dBFS. Some plugins (like freeware Voxengo Span) allow to choose the scale: RMS dBFS, RMS dBFS+3, K-Metering or LUFS.

Yep, dBFS is relative to the maximum value of digital audio (if you don't count floating-point formats) as no fixed-point format (including 32-bit integer obviously) would cut it when comes to peaks above 0dBFS, so I think it is the best practice to display dBFS on @pqyt's spectrum analyzer component, especially the peakmeter

BTW, the reason for having dBFS scale on linear/nth root amplitude scale peakmeter and spectrum is because I think it is still useful even if the amplitude scale is not logarithmic, especially some DAWs have peakmeters that have non-logarithmic amplitude scale to presumably display -Infinity dBFS (absolute silence)

Re: foo_vis_spectrum_analyzer

Reply #699
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."