Question about sample rates from a user

[aciddose]

AFAIK, the higher the samplerate is the better the construction of audio data in human hearing range can be achieved.

That is incorrect.

BTW, I've noticed that (at least in (older) Cubase SE and Reaper) there are many VST effect plug-ins which does not work correctly in high resolution projects because of these usually gets initalized for 44.1kHz when project is opened. Another minus has been that in some cases presets are somehow samplerate specific - a preset done @ 44.1kHz doesn't give same result @ 96kHz (otherwise ok but the cutoff frequency gets changed).

That is usually due to bugs in the plug-ins. For example Xhip can be rendered at 1 mHz sample rate and should sound absolutely identical to 48 kHz. When it doesn't that is either due to: 1) aliasing or 2) bugs.

Most users would never complain about these issues because they run at 44.1 kHz and never anything else. They render at exactly the same rate.

In fact this is partially the cause: without users reporting such bugs to plug-in authors, the authors have no way to identify that they exist. This is why many plug-ins are written with absolutely stupid naive coefficient calculations that don't work correctly at any rate but "happen to sound OK" at 44.1 kHz.

[plexuss]

[snip...] without users reporting such bugs to plug-in authors, the authors have no way to identify that they exist. This is why many plug-ins are written with absolutely stupid naive coefficient calculations that don't work correctly at any rate but "happen to sound OK" at 44.1 kHz.

If I noticed an obvious difference between 96kHz and 48kHz, my first thought would be to find the 'broken' plug-in rather than putting it down to increased accuracy. Don't get me wrong, I've no doubt you are hearing increased accuracy a lot of the time! Still, so many things can change that I tend not to bother trying.

Yes. When I flip to 96k I listen for differences. if there are none, I carry forward at 96k. if there are differences I try and correct unless they are too different. In those cases I find the offending plugin, do an isolated test and then report to the dev. Some devs are good about fixing these problems and some are not. Now I test using the demo and make purchase decisions based on the plugins ability to sound the same at different project rates.

[Z1202]

It has been mathematically shown that for the purposes of recording and playback it is sufficient to have a sampling rate of 44kHz (some open questions may still remain here and there, but for all practical reasons we can believe that to be an established fact). However, nothing has been said about whether 44kHz is "sufficient for processing" and there are different factors to be taken into account. A common misunderstanding is to ignore this "for the purposes of recording and playback" and assume that 44kHz is sufficient for all audio DSP purposes, which is not really the case.

If the DSP is modelling some kind of analog processing (and a large part of audio DSP is, even if it doesn't explicitly claim to be analog modelling), then, in principle one needs to process at infinite sample rate to have results identical to continuous time ("analog"). In practice a sufficiently high sampling rate will be okay, where "how high is sufficient" will vary with details and skill of algorithm implementation. [Edit: this sholudn't be understood in the sense that an algorithm which is running above 44kHz is poorly implemented. Some kinds of processing simply require higher sampling rates. However, in many cases, there are ways to reduce the required sample rate, and this is a part of the skill.] It could be that already 44kHz is enough, or it could be that even 192kHz isn't. Generally speaking, any such modelling algorithm, should become closer to "analog" as the sampling rate increases, however higher sampling rates increase the requirements on the computation precision. If 32-bit floats are sufficient at 44kHz, one might need 64-bit starting with certain higher sampling rate (again, algorithm-dependent).

So, increasing the sampling rate makes the sound closer to "analog", however, if the computation precision is not sufficient, the quantization noise will start degrading the quality.

Many plugins will do internal oversampling. Some plugins will oversample relatively to the host rate, e.g. 2x oversampling will produce 88kHz at 44kHz host rate or 192kHz at 96kHz host rate. Some other plugins will oversample to some given target rate, e.g. a plugin can try to oversample to a rate which is equal to (or maybe is close to) 96kHz. Apparently, in the first case, the plugin will sound more "analog" at higher rates, while in the second case not much difference will be noticed.

[aciddose]

It has been mathematically shown that for the purposes of recording and playback

That is incorrect.

Any band-limited signal can be represented perfectly in a uniformly sampled discretization at twice or more the maximum frequency of the band-limited signal to be sampled.

That doesn't say anything about conversion (ADC, DAC) or processing. It's all about storage.

Technically speaking any processing other than a linear transform (gain adjustment) is not valid at all when applied to a discrete signal. All the digital filters have different spectral characteristics than their analog prototypes.

This comes down to the algorithm and processing cost and has zero to do with the sampling rate.

[matt42]

It has been mathematically shown that for the purposes of recording and playback

That is incorrect.

Any band-limited signal can be represented perfectly in a uniformly sampled discretization at twice or more the maximum frequency of the band-limited signal to be sampled

Well, we're talking audio here and a healthy pair of ears may detect content up-to around 20 kHz. Sure you will have special cases where the requirements are lower, but anyway I'm sure Z1202 is talking about audio signal reproduction, not the sampling of arbitrary band limited signals.

[aciddose]

I'm also talking about audio signal reproduction, which has absolutely nothing to do with the sampling theorem.

What the sampling theorem talks about is representation of a band-limited signal with uniformly spaced discrete samples.

Making additional statements about "reproduction" or "recording and playback" is 100% disingenuous nonsense, to be honest I would simply call it a lie.

It's important to remember that all this technology was developed for the purpose of scientific measurements and is 100% concerned about accuracy and nothing else. The Fourier transform was developed to compute the heat distribution through a plate, not to optimize some DSP for a convolution based reverberation algorithm.

Just because we apply this technology in this extremely limited niche in that way doesn't suddenly invalidate the facts which have been established approximately a century ago.

There is a major difference between what is subjective and objective. Objectively speaking the sampling theorem merely states that it is possible to accurately represent data with specific parameters in a specific format. It says nothing else.

Essentially the sampling theorem states that given a stream of uniformly spaced discrete samples, there exists only one possible continuous reconstruction of that data. That's the important part. The whole point is that if you have a measurement stored in this format it can not have multiple meanings. It only means one thing with no other possibilities and no subjectivity whatsoever. That's important.

[matt42]

Sure, so I guess that means we need a sample rate 44 kHz for high fidelity audio, or not? (assuming we're talking about humans and not bats)

[aciddose]

It means to represent anything between 1/length Hz and samplerate/2 Hz it's possible to use samplerate.

If that's 1 second at 44100 Hz, it gives: 1 Hz to 22050 Hz. The phase of the portion of the signal that was actually sampled is represented exactly if the signal is band-limited. At the edges though it isn't possible to reproduce the original signal anymore (obviously) although the representation is exact, there is no possible interpolation that would reconstruct a continuous signal matching what is represented because the reconstruction would no longer be band-limited.

In audio none of the lower frequency stuff matters, so the only number at play is 1/2 samplerate, which is any music containing no more than 22050 Hz can be stored exactly.

What Z1202 mentioned is also correct: while the signal is represented perfectly that doesn't mean it can be modified/transformed/processed or reconstructed perfectly.

Just that the statement about "recording and playback" is incorrect because those count as transformations.

[Zaphod (giancarlo)]

When I render a project in 44.1k and then compare it to a render at 96k, I find the 96k version sounds, as I mentioned smoother, sweeter, clearer. Making an assumption that "44.1k is good enough" (as many people contend), I was wondering what else might cause this increase in percieved fidelity with the 96k render.

If it sounds any different it is only because of the increase in bandwidth. So the anti-aliasing filters (if any) used by the software in question aren't good enough.

I often render at 192k rather than 48k where I'm using a lot of distortion, audio rate modulation or similar effects that produce a lot of aliased frequency content.

Where I'm not using them though: there is absolutely zero audible difference whether I render a track at 48k, 192k or 1000k (1 mHz).

There is a computational difference though, usually to render at 4x the rate requires at least 4x as much processing time and often even more due to overhead.

For example rendering the latest Xhip demo clip I posted to sound cloud:
Edited to replace with a comparison using higher modulation depths and feedback:
https://soundcloud.com/aciddose-1/sets/ ... comparison

There is a lot of aliasing here because of cross-modulation (FM), but this is actually a good thing. If I increase the rate to 192k the cymbal and bass sound very different and not "old-school FM" anymore but way too pure and boring. Most of the noise in the cymbal is actually aliasing noise and the high-frequency aliasing in the bass is what makes it sound so interesting with a ressy filter sweep.

So you need to be aware of exactly what and why you're using oversampling because sometimes a lower sample rate produces the effect you want while a higher one will be too pure.

Nebula is mostly a fir, it doesn't need antialiasing.
44.1 filters and sr conversion have an impact on phase. On iir plugins the situation is even worse because the filter is real-time, si there are more constraints (being fir, we can calculate them offline at an higher precision)

[Z1202]

Just that the statement about "recording and playback" is incorrect because those count as transformations.

Those are transformations, for which the sampling theorem proves the possibility of a fully transparent roundtrip, given we are not interested in the content above Nyquist. In that sense, it's mathematically proven that for recording and playback of audio signals 44kHz is sufficient. For other transformations (processing), there is no such proof, hence the generalization of the same statement about 44kHz being sufficient doesn't hold.

[FabienTDR]

In that sense, it's mathematically proven that for recording and playback of audio signals 44kHz is sufficient. For other transformations (processing), there is no such proof, hence the generalization of the same statement about 44kHz being sufficient doesn't hold.

Of course it is! For example, all linear processes will handle perfectly well at any rate (given they consider the effect of Nyquist warping in their design). Easily proven. It's when nonlinear systems come into play that additional processing bandwidth is required. But this too is easily proven and explained.

[Z1202]

In that sense, it's mathematically proven that for recording and playback of audio signals 44kHz is sufficient. For other transformations (processing), there is no such proof, hence the generalization of the same statement about 44kHz being sufficient doesn't hold.

Of course it is! For example, all linear processes will handle perfectly well at any rate (given they consider the effect of Nyquist warping in their design).

Hmmm, besides linearity that also requires time-invariance. Given that in music DSP not so many processes are linear and even less are time invariant, and even less of the remaining ones take care to properly avoid the warping artifacts... I agree that in theory for LTI processes this holds, but I wonder e.g. how many practical EQ implementations (if any) bother to reach the same precision in avoiding the response artifacts (which costs the more extra design and computation complexity the more precisely you want to avoid them), as the practical resampling algorithms (let alone ADCs and DACs) achieve in avoiding the aliasing. Maybe there are some, but as a rule of thumb, I'd rather say that one can assume that plugins sound better at higher sampling rates (with the mentioned reservation about quantization errors).

Edit: what I'm trying to say is that both perfect recording/playback and the perfect LTI processing require infinite complexity of algorithms. Typical ADCs and DACs go pretty far in trying to get close to that perfection (something like 128 or more points resampling FIR? I don't really know details). I would be very surprised if many 44kHz-based LTI effect implementations go to the same extent. So transparent recording/playback is something we can take for granted, the rest we cannot.

Edit2:

It's when nonlinear systems come into play that additional processing bandwidth is required. But this too is easily proven and explained.

Which means that 44kHz no longer suffices, right? (The word "proven" in the context where I used it was referring to the possibility of a 44kHz implementation, so I guess it's not applicable here).

Edit3: probably you theoretically can expand any oversampled algorithm in terms of the 44kHz sampling rate and formally claim that it's a 44kHz implementation. So formally, I would be wrong with my statement. However I hope that I made clear what I was getting at.

[Max M.]

but I wonder e.g. how many practical EQ implementations (if any) bother to reach the same precision in avoiding the response artifacts

JFYI, for EQs (in oppose to "Synth Filters") it's a lot actually. And the first such EQ was available in VST yet in 1999. (Not meaning anything you wrote is invalid of course - after all a perfect ''N-unwarping" is impossible).

[Z1202]

I guess my statement about mathematical proof was not 100% formally correct. But I'll try to explain what I meant, particularly for non-DSP experts, now with corrections arising from the discussion.

The digital audio recording/playback is based on the long-time proven sampling theorem and its direct surroundings. The respective practical techniques are well developed and commonly employed, ensuring recording/playback without noticeable artifacts at 44kHz.

For other kinds of processing the sampling theorem (and its "direct surroundings") is not sufficient and one needs more tools. While it can be formally claimed that any kind of digital processing can be done without oversampling, this claim is rather formal (see my previous post), and often may imply ridiculously huge CPU consumption. Also, there are no well established and clear practical answers about how to do processing without artifacts (except in certain cases). There are more choices and associated tradeoffs. The amount of CPU which one is willing to spend to ensure quality sound is subject to hard limitations (since there is no dedicated hardware unit for each plugin instance, whereas recording/playback is done by dedicated hardware). The tradeoff decisions acceptable to some people may not work for others.

Therefore, in practice, the statement about 44kHz being sufficient for artifactless recording/playback cannot be applied "for granted" to other kinds of processing and synthesis.

[aciddose]

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.

This is because the hardware is specially designed to run special filters at very high rates. This allows a cheap analog filter to provide more than enough band-limiting to reduce aliasing below the target noise floor (24-bit for example) with minimal effect on the audible pass-band. The over-sampled input (possibly sampled at 192 kHz or far more) is then digitally filtered by highly parallelized DSP chips to get the target signal rate.

Identical over-sampling filters could be implemented in software but are generally cost-prohibitive. Likewise it is possible to use algorithms at common low rates (44.1 kHz, 48 kHz) which produce near-ideal results, even better than naive oversampled algorithms, this again being generally cost-prohibitive.

So while such statements are true: "in practice, the statement about 44kHz being sufficient for artifactless recording/playback cannot be applied 'for granted' to other kinds of processing and synthesis" ... while that is simply another way to assert that "you can't take for granted that that other kinds of processing and synthesis are implemented correctly or bug-free."

Obviously if we were limiting ourselves to perfection: absolutely none of the current DSP software would exist at all.

No non-LTI DSP algorithm could ever be considered "bug-free" compared to its analogous analog prototype process because we're attempting to mimic one medium with another. It is simply impossible to flawlessly "emulate" a continuous system with a discrete one because that is what defines them as different in the first place. This is why I hold terms like "virtual analog" in extreme derision: they're contradictory nonsense.

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.