Yes, that's what I did in my first post. Do we have similar relationship for non-periodic signals (but band-limited at low and high freq.)?
Not really. For an arbitrary signal anything is possible. Image an isolated square pulse for instance, which is bandlimited but could have both a full scale change between two samples (the rising/falling edges), and then no change for several samples (the top of the pulse).
However, it still does not appear to work for russian encoding
Edit: seems like it's actually an old version made before Foobar 1.4 was released, it's just hard to keep track of Japanese components.
You can easily calculate the minimum step size for a given frequency and sampling rate by the way. It's just the change in amplitude between two sequential samples on either size of the maximum or minimum of a sin wave. When that step size gets less than the quantization level, and if you are not dithering or using noise shaping, the step size will be zero.
I expressed my idea not clearly. I wanted to talk about different aspect of quantization. So, I will ask another way.
If we take any band-limited signal sampled at 44100 and normalized to 1.0, what will be the minimum distance between two neighboring samples. I noticed that there is a clear bottom limit for that distance even for 64bit signals. And my thought was that this min distance is determined by the lowest frequency component of the signal.
My request had nothing to do with ReplayGain or adjustment for listening (although I do use that when I make a dinner party playlist), I just wanted the pure Integrated LUFS value readout in the playlist. As ReplayGain now uses LUFS to work out its values, it was possible to derive the figure from the ReplayGain one. Some very kind souls helped me out there!
init_stages::before_config_read seems awfully early in the process for most services to be available.Welp, the code is mostly identical to the official sample:
Do you know if there is a better example?
The definition of objects with static storage duration in your stats.h seems a bit sketchy as you include that header in multiple translation units and as such, have duplicate registrations of objects.Yes, this is most likely the cause, thanks!