Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf] • Hacker News Board

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#11

Post by [deleted] » Mon, Mar 04, 2024, 12:43 AM UTC

shampto3 wrote: post #9

f5ve wrote: post #3

If you're thinking "The highest rate I need my signal to be able to replicate is X, so I should set my sampling rate to 2X," then you're wrong and this article gives several reasons why. As far as I can tell, though, it doesn't mention what may be the most important reason (especially to the folks here at hackernews): resampling and processing. This is why professional grade audio processing operates at a sample rate…

You’re right, but I fear this idea has become prevalent in audiophile communities where they only want to listen to files that are 96kHz or higher. In my opinion, having a high sample rate only really matters during the production phase and does not have a noticeable effect on the final form factor. If the producer uses high sample rate during the creation process, I see no reason why the listener would care if the f…

[deleted]

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#12

Post by anonymous-panda » Mon, Mar 04, 2024, 12:46 AM UTC

rcxdude wrote: post #8

anonymous-panda wrote: post #5

It’s interesting to me how frequently people will talk about sampling performance profilers and not know about Nyquist. Given a CPU runs at many GHz but SW sampling profilers run at ~1 or even maximum 10khz, it’s really hard to write software if you’re targeting processing at MHz rates.

I'm not sure what you mean here, but I would say that sampling profilers are a good example of Nyquist applied correctly for the most part: your signal (the distribution of where your software is spending its time) is likely to have an extremely low bandwidth (as in, it's basically static), so why try to sample super rapidly? It's much more of a question of whether you get enough samples to represent that distributio…

You’re talking about profiling a normal running program. If you’re profiling a benchmark that’s always executing the hot path, where exactly the hot path contribution lies becomes less clear. This is because you run into aliasing with the samples being collected at unhelpful points. Maybe if you run long enough you start to see a picture but at 1khz you’re going to have to run for a very long time. The other way aliasing comes into effect is that it becomes to see the impact of “individually cheap” but often executed pieces of code (eg a simple bounds check may not show up even if it’s responsible for a 20% slowdown because the probability of your sampler hitting it is small when that bounds check takes nanoseconds to execute vs your ms profiler sample rate.

Basically a 1ms sampler can pick out a signal that’s 2ms or longer in periodicity if sampled once (all faster signals will get aliased). To get to 1ghz (once a nanosecond) would require capturing 1 million times more samples and you’re still dealing with aliasing screwing up the picture you’re getting (although maybe with stack sampling you get disambiguation to combat aliasing? Not sure).

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#13

Post by rcxdude » Mon, Mar 04, 2024, 12:46 AM UTC

markkitti wrote: post #10

rcxdude wrote: post #6

Earlier quoted context omitted.

Not just eventually: many effects, such as basically any non-linear mapping like a distortion, will create overtones that will immediately alias down if you are not oversampling. You either need to use some DSP tricks or oversample (usually a mix of both) to avoid this happening, which often happens in just one step of an effects chain.

Even the term "oversampling" implies that sampling beyond Nyquist rate is excessive. I think you would agree that one is not being excessive. It is necessary to sample well beyond accepted "Nyquist rate" in order to reconstruct the signal.

That is the term, however. You see it in many contexts where a higher sample rate is traded for some other desirable attribute. (For example, it's often desirable for an ADC to sample faster than the higher frequency content you care about in an analog signal, for the reasons detailed in the paper as well as because it can give you a lower noise ADC. delta-sigma converters being an extreme case of this, helped by a seperate trick of noise shaping).

It's worth noting it's a tradeoff, even in pure processing: almost all non-linear transfer functions will create an infinite number of overtones, so it's impossible to avoid aliasing completely: you can only reduce them to some threshold which is acceptable to the application.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#14

Post by rcxdude » Mon, Mar 04, 2024, 12:52 AM UTC

anonymous-panda wrote: post #12

rcxdude wrote: post #8

Earlier quoted context omitted.

I'm not sure what you mean here, but I would say that sampling profilers are a good example of Nyquist applied correctly for the most part: your signal (the distribution of where your software is spending its time) is likely to have an extremely low bandwidth (as in, it's basically static), so why try to sample super rapidly? It's much more of a question of whether you get enough samples to represent that distributio…

You’re talking about profiling a normal running program. If you’re profiling a benchmark that’s always executing the hot path, where exactly the hot path contribution lies becomes less clear. This is because you run into aliasing with the samples being collected at unhelpful points. Maybe if you run long enough you start to see a picture but at 1khz you’re going to have to run for a very long time. The other way alia…

I don't think what you're talking about is aliasing: it's more to do with the statistics of sampling. Though even then I still don't quite get what you mean: if a bounds check is 20% of your runtime then you're going to see it in your samples pretty quickly. If it's a small enough fraction of your runtime that you don't expect to see it in millions of samples, then why is it relevant to your performance? Now, if you're worried about latency outliers, I can see why sampling may not be a useful tool, but again I don't think the reason for that is really aliasing.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#15

Post by nofu7ur3 » Mon, Mar 04, 2024, 1:12 AM UTC

> ...there is no point to distributing music in 24-bit/192kHz format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48....

from "24/192 Music Downloads ...and why they make no sense" (2012) [1]

[1] https://people.xiph.org/~xiphmont/demo/neil-young.html

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#16

Post by hunter2_ » Mon, Mar 04, 2024, 1:21 AM UTC

shampto3 wrote: post #9

f5ve wrote: post #3

If you're thinking "The highest rate I need my signal to be able to replicate is X, so I should set my sampling rate to 2X," then you're wrong and this article gives several reasons why. As far as I can tell, though, it doesn't mention what may be the most important reason (especially to the folks here at hackernews): resampling and processing. This is why professional grade audio processing operates at a sample rate…

You’re right, but I fear this idea has become prevalent in audiophile communities where they only want to listen to files that are 96kHz or higher. In my opinion, having a high sample rate only really matters during the production phase and does not have a noticeable effect on the final form factor. If the producer uses high sample rate during the creation process, I see no reason why the listener would care if the f…

The same could be said about bit depth: 24 bits offers far less quantization artifacts than 16 bits, and those artifacts can readily show up during production processes such as dynamic range compression, but they are extremely well hidden by dithering with noise shaping which gets applied during mastering so ultimately listeners are fine either way.

However, any type of subsequent processing in the digital domain, even just a volume change by the listener if it's applied digitally in the 16 bit realm (i.e., without first upscaling to 24 bits), completely destroys the benefit of dithering. For that reason, we might say that additional processing isn't confined to the recording studio and can happen at the end user level.

I'm unsure whether this same logic applies to sampling frequency, but probably? I guess post-mastering processing of amplitude is far more common than time-based changes, but maybe DJs doing beat matching?

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#17

Post by charcircuit » Mon, Mar 04, 2024, 1:31 AM UTC

f5ve wrote: post #3

If you're thinking "The highest rate I need my signal to be able to replicate is X, so I should set my sampling rate to 2X," then you're wrong and this article gives several reasons why. As far as I can tell, though, it doesn't mention what may be the most important reason (especially to the folks here at hackernews): resampling and processing. This is why professional grade audio processing operates at a sample rate…

Another factor which I don't see mentioned is that the tech audio signal is not always directly going to your ear. Is it possible for the sound bouncing around the room to break such assumptions?

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#18

Post by duped » Mon, Mar 04, 2024, 1:35 AM UTC

shampto3 wrote: post #9

f5ve wrote: post #3

If you're thinking "The highest rate I need my signal to be able to replicate is X, so I should set my sampling rate to 2X," then you're wrong and this article gives several reasons why. As far as I can tell, though, it doesn't mention what may be the most important reason (especially to the folks here at hackernews): resampling and processing. This is why professional grade audio processing operates at a sample rate…

You’re right, but I fear this idea has become prevalent in audiophile communities where they only want to listen to files that are 96kHz or higher. In my opinion, having a high sample rate only really matters during the production phase and does not have a noticeable effect on the final form factor. If the producer uses high sample rate during the creation process, I see no reason why the listener would care if the f…

People should prefer 48k over 44.1 but not for fidelity. It would just make the world a better place if 44.1k audio files died out. The reasons it was chosen are invalid today and we're stuck with it, and now every audio stack needs to be able to convert between 44.1/88.2 and 48/96 which is a solved problem, but has a tradeoff between fidelity and performance that makes resampling algorithms a critical design feature of those stacks.

All because Sony and Philips wanted 80 minutes of stereo audio on CDs decades ago.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#19

Post by salty_biscuits » Mon, Mar 04, 2024, 1:41 AM UTC

The biggest one I have run into is that the bandwith doesn't need to be contiguous. If you know the the important bits of the signal are contained in certain frequency bands then you can get much lower sampling rates. Basically why things like l1 reconstruction work.

Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]

#20

Post by hamstergene » Mon, Mar 04, 2024, 1:47 AM UTC

nofu7ur3 wrote: post #15

> ...there is no point to distributing music in 24-bit/192kHz format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48.... from "24/192 Music Downloads ...and why they make no sense" (2012) [1] [1] https://people.xiph.org/~xiphmont/demo/neil-young.html

This could be a useful disclaimer, to say "we are talking about recording and processing and NOT about playback".

Audiophiles demand streaming services to provide 192/24 because they see the music being originally mastered at high sample rates, and from that conclude that listening to 48/16 is a loss of "original recorded quality".

I can totally envision audiophiles picking up the Wescott's article and using it as "scientific" argument to distribute more Hi-Res music, and some half-technical manager buying that. They won't even read it.