Login / Register  0 items | $0.00 New
Z1202
KVRian
 
808 posts since 11 Apr, 2002

Postby Z1202; Sun Oct 15, 2017 2:50 am Re: Question about sample rates from a user

aciddose wrote:One important thing to point out is that during recording (ADC) or playback (DAC) the interface hardware is essentially doing oversampling in order to get the results it does with minimal audible artifacts.
Actually this oversampling is done to optimize the hardware costs. For the end user it hardly makes any difference, which specific shortcuts were done in a particular ADC/DAC, as long as the quality is not compromised.

aciddose wrote:Regarding the abstract "infinite sample rate": in fact, the limit of many DSP algorithms is not equal to the analog prototype as the sampling rate approaches infinity because most if not all existing algorithms are based upon the signal being discrete. Many of these algorithms break down in various ways at that limit instead.
I'd agree that this may be true for some algorithms. But I'd disagree to the second statement. Many algorithms either explicitly attempt to emulate continuous time by discrete time steps or at least can be seen that way, rather than being based on discrete time. Such approximations are therefore approaching the continuous time in the limit. That includes a large amount of IIR filters, interpolators, antialiasing techniques etc.
camsr
KVRAF
 
6699 posts since 16 Feb, 2005

Postby camsr; Sun Oct 15, 2017 10:05 am Re: Question about sample rates from a user

aciddose wrote:Regarding the abstract "infinite sample rate": in fact, the limit of many DSP algorithms is not equal to the analog prototype as the sampling rate approaches infinity because most if not all existing algorithms are based upon the signal being discrete. Many of these algorithms break down in various ways at that limit instead.


Another thing that accelerates that breakdown is using a naive method inside of another.
Image
User avatar
aciddose
KVRAF
 
11515 posts since 7 Dec, 2004

Postby aciddose; Sun Oct 15, 2017 2:38 pm Re: Question about sample rates from a user

Z1202 wrote:
aciddose wrote:... the interface hardware is essentially doing oversampling in order to get the results it does ...
Actually this oversampling is done to optimize the hardware costs. For the end user it hardly makes any difference, which specific shortcuts were done in a particular ADC/DAC, as long as the quality is not compromised.


I'd say it does matter to the end user when the end user is asking about sample rates. This is because the hardware is using over-sampling ("higher sample rates") and specialty hardware to produce the result it does as efficiently as it does.

Reproducing the same process at the same quality in software computed on a general purpose CPU would be extremely expensive.

This is why I've recommended in the past that where oversampling is desired it is actually extremely inefficient to have every plug-in implementing its own unique low-quality ("real-time") interpolating filters for oversampling. It makes more sense to render the track offline at a high rate (4x, 8x, 16x) and re-sample offline back to the native rate. That unfortunately depends upon every plug-in working correctly at large ranges of sample rates rather than focusing on a single rate like 44.1 kHz.

In the past the design decisions with regard to oversampling methods have in my opinion had a severely detrimental effect on the quality of plug-ins. I would argue that including such real-time oversampling implementations is always a symptom of bad design.
Xhip Synthesizer v8 (WinXP, Linux and MacOS alpha versions are available.)
Xhip Effects bundle v6.7 New: Resizable/skinnable/configurable GUI. (Linux and MacOS alpha versions are available.)
mystran
KVRAF
 
4595 posts since 11 Feb, 2006, from Helsinki, Finland

Postby mystran; Sun Oct 15, 2017 11:52 pm Re: Question about sample rates from a user

For something like an EQ in pure LTI operation, it's computationally cheaper really to just deal with the Nyquist problems directly, rather than oversample, since a fairly short (as in: less than one branch of an oversampling kernel) special purpose FIR fit can do wonders (not to mention you can get nice "analog" phase with less latency than what you'd need for linear-phase oversampling). The downsides are that coefficient updates now become more expensive as you have to redo the FIR fitting (although if you do it right, you won't need a particularly expensive fitting process) and the results in time-varying operation won't be very meaningful.
Image <- plugins | forum
Z1202
KVRian
 
808 posts since 11 Apr, 2002

Postby Z1202; Mon Oct 16, 2017 12:56 am Re: Question about sample rates from a user

camsr wrote:Another thing that accelerates that breakdown is using a naive method inside of another.
Hmmm, if possible, could you bring an example of that? Off the top of my head I can think of only two reasons: quantization error, or the method does not purely discretize time (which in some cases could be even a bug in the algorithm). Otherwise, this would mean that the algorithm handles low frequency signals worse than high frequency signals.

aciddose wrote:I'd say it does matter to the end user when the end user is asking about sample rates. This is because the hardware is using over-sampling ("higher sample rates") and specialty hardware to produce the result it does as efficiently as it does.
Okay, probably you could see it that way: a "cheap" hardware ADC/DAC is using oversampling is digital domain to improve the quality. But then it's one more demonstration of a process, the quality of which increases with sample rate :)

mystran wrote:For something like an EQ in pure LTI operation, it's computationally cheaper really to just deal with the Nyquist problems directly, rather than oversample, since a fairly short (as in: less than one branch of an oversampling kernel) special purpose FIR fit can do wonders (not to mention you can get nice "analog" phase with less latency than what you'd need for linear-phase oversampling). The downsides are that coefficient updates now become more expensive as you have to redo the FIR fitting (although if you do it right, you won't need a particularly expensive fitting process) and the results in time-varying operation won't be very meaningful.
Regardless of how close to perfect the 44kHz version might be, I'd guess that the quality will still increase, if only marginally, at higher sample rates? ;)
User avatar
aciddose
KVRAF
 
11515 posts since 7 Dec, 2004

Postby aciddose; Mon Oct 16, 2017 1:19 am Re: Question about sample rates from a user

I suppose that is always true though in some sense, which makes it somewhat disingenuous as it is just too obvious to carry any significance.

It breaks down at some point to something equal to the question of "is there any reason to use higher sample rates for music?"

In terms of oversampling in general I would agree that it is certain there "will be some optimal algorithm" that runs most efficiently without an oversampled rate, although in many cases this algorithm may not yet be known to us. Such algorithms are almost definitely not those used in the vast majority of plug-ins on the market today.

Due to the fact 44.1 kHz, 48 kHz and any other rate is almost entirely arbitrary apart from ">20 kHz band" however it doesn't make sense to design algorithms today without the capability to operate reliably at varied sample rates. "Those who cannot remember the past are condemned to repeat it" with regard to past algorithms designed solely for 44.1 kHz.

Ultimately this is all a question of exactly how much effort users are willing to invest toward learning how their systems operate; which is sadly likely to be far less than that to "know what/why you are oversampling" well enough to operate their systems and make the best possible decisions on their own.

So things will continue as they have, impossible to change due to practical limitations. For those who are interested in the topic though there are ample resources available to learn enough to "know what/why you are oversampling" and produce in higher quality results than those otherwise possible where oversampling is of benefit.

In other words I'd say the ultimate answer is: It's complicated. Good luck.
Xhip Synthesizer v8 (WinXP, Linux and MacOS alpha versions are available.)
Xhip Effects bundle v6.7 New: Resizable/skinnable/configurable GUI. (Linux and MacOS alpha versions are available.)
Z1202
KVRian
 
808 posts since 11 Apr, 2002

Postby Z1202; Mon Oct 16, 2017 2:00 am Re: Question about sample rates from a user

I think from theoretical standpoint the question is so complicated that one cannot reliably predict anything without having studied the detailed implementation of a particular plugin. Therefore from the practical standpoint, without having to learn DSP, the rules of thumb can be rather simple:

- For purely recording/playback purposes the sample rate doesn't matter, as long as it's 44kHz or higher
- For the synthesis/processing purposes simply check how your project sounds at different sampling rates. Note that as you increase the sampling rate there will be opposing forces (reduced Nyquist artifacts vs. quantization noise), which will be also in different balance for different plugins or even for different plugin settings or different processed material. In some other plugins the change in quality may be even more complicated or, on the contrary, absent. Judge the sound of your project as a whole, paying attention to both increases and degradations in quality. Mind the automated parameter changes, which can hide or reveal certain quality changes.
User avatar
aciddose
KVRAF
 
11515 posts since 7 Dec, 2004

Postby aciddose; Mon Oct 16, 2017 2:23 am Re: Question about sample rates from a user

I'd expand on that just a touch though:

Each individual plug-in should also be considered in isolation. A whole project might have a very complex combination of pros/cons regarding different rates while individual tracks or even just plug-ins in isolation may be easier to deal with.

So in many cases it might help to place a single instrument on its own track with any inserts/sends on other tracks. The instrument can then be "frozen" or rendered offline at the best possible rate if needed to improve its quality as desired.

Sometimes it might be best to render a whole track at a higher rate such as those using distortion effects. Oversampling just the distortion will not produce the same result as oversampling the whole track including any synthesizers and other effects because the signal input to the distortion will lack content outside the band (>20 kHz) that could significantly influence the result.

Other times it might ruin a single track or simply make it N times more expensive to process without any benefit at all.

In general the best advice is probably: start at the beginning, find a problem first before you set out to solve problems that don't even exist. You have to learn to identify the situations in which the quality is negatively impacted and requires a higher sample rate by experimenting.

Trial and error may not (I'd say is 100% certain not to) be the best way to learn, but taking knowledge of the different factors at play (non-linear processing, modulation, aliasing, frequency ranges/bandwidth, ...) and applying that to experiments to verify your understanding will definitely improve things. With enough knowledge and experience via experimentation you'll intuitively begin to understand when oversampling is of benefit and when it is detrimental.

No matter what though some learning is required.
Xhip Synthesizer v8 (WinXP, Linux and MacOS alpha versions are available.)
Xhip Effects bundle v6.7 New: Resizable/skinnable/configurable GUI. (Linux and MacOS alpha versions are available.)
mystran
KVRAF
 
4595 posts since 11 Feb, 2006, from Helsinki, Finland

Postby mystran; Mon Oct 16, 2017 2:28 am Re: Question about sample rates from a user

Z1202 wrote:
mystran wrote:For something like an EQ in pure LTI operation, it's computationally cheaper really to just deal with the Nyquist problems directly, rather than oversample, since a fairly short (as in: less than one branch of an oversampling kernel) special purpose FIR fit can do wonders (not to mention you can get nice "analog" phase with less latency than what you'd need for linear-phase oversampling). The downsides are that coefficient updates now become more expensive as you have to redo the FIR fitting (although if you do it right, you won't need a particularly expensive fitting process) and the results in time-varying operation won't be very meaningful.
Regardless of how close to perfect the 44kHz version might be, I'd guess that the quality will still increase, if only marginally, at higher sample rates? ;)


The way I see it (and this is very much limited to the LTI case), the question is what quality you can get for any given CPU budget. If you spend the CPU that you would ordinarily spend on your oversampling filters on running a special purpose FIR instead, you should always expect much better quality and only need to run the IIR part at 1x rate. The key observation is that one can perform such a fit on something like a complete EQ once "in bulk" which really makes it computationally very efficient (ignoring coefficient updates, anyway).

My preferred method (which is by no means the only workable approach) is to do pole-zero mapping on a continuous time prototype, then take the log-difference of the result vs. the prototype. While the pole-zero mapping doesn't give sensible results on it's own (except at low frequencies, sort of), the resulting error function is very smooth and easy to fit against. In fact even simple least-squares will work like a dream as long as you factor in a few samples of latency (at least for phase-fit) and while least-squares fitting (or whatever you pick) is not something you want to do on per-sample basis, it's not really a problem to do it interactively as the user adjusts parameters.
Image <- plugins | forum
Z1202
KVRian
 
808 posts since 11 Apr, 2002

Postby Z1202; Mon Oct 16, 2017 2:57 am Re: Question about sample rates from a user

aciddose wrote:find a problem first before you set out to solve problems that don't even exist
I'd like to comment on that, that this statement could be misleading. E.g. one might even not realize that the track could sound better, before trying to change the sampling rate. In that sense, maybe there was no problem that one was aware of, still it could be worth trying to change things.

Also regarding your entire proposal of changing the SR per-track or per-plugin. Theoretically it makes total sense, of course. Whether it makes practical sense, depends on how much time one is willing to spend fighting for the "last bit of quality" to be squeezed out of SR changes :D
User avatar
aciddose
KVRAF
 
11515 posts since 7 Dec, 2004

Postby aciddose; Mon Oct 16, 2017 3:39 am Re: Question about sample rates from a user

Well that is where most likely it would be best to try individual plug-ins and fiddle with the sample rate, render 11025, 44100, 48000, 96000, 192000, 1008000 and so on to see what happens.

Then where you know the differences it'll be far more easy to identify which track benefits from higher rates and where not... as a first step rendering whole tracks might also help but subjectivity and confirmation bias can impact this significantly so this sort of thing sets off flashing warning lights and sirens for me, generally: DANGER!
Xhip Synthesizer v8 (WinXP, Linux and MacOS alpha versions are available.)
Xhip Effects bundle v6.7 New: Resizable/skinnable/configurable GUI. (Linux and MacOS alpha versions are available.)
juha_p
KVRist
 
429 posts since 21 Feb, 2006, from FI

Postby juha_p; Tue Oct 17, 2017 12:20 am Re: Question about sample rates from a user

Here's an example of a badly behaving plug-in at 96kHz and 44.1kHz:
Image

Looks good at 44.1kHz but wrong cutoff points at 96kHz.
Z1202
KVRian
 
808 posts since 11 Apr, 2002

Postby Z1202; Tue Oct 17, 2017 1:18 am Re: Question about sample rates from a user

juha_p wrote:Here's an example of a badly behaving plug-in at 96kHz and 44.1kHz:
Looks good at 44.1kHz but wrong cutoff points at 96kHz.
Looks to me exactly as if the plugin is simply unaware of the fact that the sampling rate is 96 and not 44. I'd think it's either a bug or the plugin is hard-coded to be operated at 44kHz (in which case I'd also consider it a bug that the plugin doesn't refuse to operate at an unsupported sampling rate).
juha_p
KVRist
 
429 posts since 21 Feb, 2006, from FI

Postby juha_p; Tue Oct 17, 2017 2:18 am Re: Question about sample rates from a user

Z1202 wrote:
juha_p wrote:Here's an example of a badly behaving plug-in at 96kHz and 44.1kHz:
Looks good at 44.1kHz but wrong cutoff points at 96kHz.
Looks to me exactly as if the plugin is simply unaware of the fact that the sampling rate is 96 and not 44. I'd think it's either a bug or the plugin is hard-coded to be operated at 44kHz (in which case I'd also consider it a bug that the plugin doesn't refuse to operate at an unsupported sampling rate).


Yes, looks like it just shifts the cutoff frequencies by 96/44.1 times.

IIRC, this example plugin is one of those which works @ 96kHz when you open it within a 96kHz project but, if you change the samplerate after loading, it don't get updated --> is it a bug or was it developed using some VST API not supporting samplerate change? I can't test this latter by using VST Analyzer because of it is initalized for 44100 Hz... as for an example, Electri-Q (free version) don't give graph in VST Analyzer when measured at any other fs but 44100Hz --> is the samplerate info read in the plug-in initalization process only?
User avatar
aciddose
KVRAF
 
11515 posts since 7 Dec, 2004

Postby aciddose; Tue Oct 17, 2017 5:10 am Re: Question about sample rates from a user

The bug could be that they do various illegal things like initialize coefficients in the constructor, fail to re-initialize coefficients during a state-change or ignore "set sample rate" instructions from the host.

It is also entirely possible your host isn't communicating with the plug-in correctly by for example responding to "get sample rate" with the incorrect value, not bothering to call "set sample rate" before state-change and processing or never calling "state changed" to inform the plug-in to recompute its coefficients.

These issues when they're encountered in VST at least are almost entirely due to the lack of documentation of the interface. Host and plug-in authors can't be expected to implement features "correctly" when there is no documentation that defines the correct implementation.

Testing it now I can report it seems to correctly respond to "set sample rate" and updates coefficients in real-time. So it's definitely your host that causes the problem.

"RubberFilter" does have numerous "bugs", but not handling varied sample rates is not one of those.

You should report the bug to your host support and have them call "set sample rate" to inform the plug-in of when the rate has changed between process calls.
Xhip Synthesizer v8 (WinXP, Linux and MacOS alpha versions are available.)
Xhip Effects bundle v6.7 New: Resizable/skinnable/configurable GUI. (Linux and MacOS alpha versions are available.)
PreviousNext

Moderator: Moderators (Main)

Return to DSP and Plug-in Development