For a mini-surprise, check the prime factors of 44100.
[deleted]
Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
61–70 of 79 posts
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#62Many brilliant points. Particularly about Bessel filters instead of Butterworth. And also about lowering Fc and increasing Fs, rather than increasing order. And also about considering time domain as well as frequency domain. The dense interview question I use to assess this area of knowledge: "How do you choose the stopband attenuation of a filter?" You can assess a lot from the interviewee's response. Stopband atten…
My response would be: "to validate the chosen stopband attenuation, compare the unwanted signal or interference that passes through the filter with the noise that you already have or with other factors that would make this unwanted signal or interference unnoticeable".
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#63I ran into this problem with a codec chip. We had to run the output at 48 khz, and the input and output clock had to be the same. Well we didn't have enough CPU to process the input at 48 khz, we only cared about 8 khz bandwidth for human speech. Boxcar averaging then decimating produced way too much aliasing, so much that the ML classifiers wouldn't work. The solution was putting a honking large FIR anti aliasing fi…
To clarify - you were able to run the FIR filter on the codec chip because the main CPU didn't have enough to handle the 48kHz input?
Nifty story, just wanted to validate my understanding.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#64The 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.
Bandpass sampling is a regular technique used in the RF world to mix down a signal to its final IF or baseband frequency, digitally. In this case, you are undersampling but using a well defined signal that you have apriori knowledge of where it is before and after sampling.
https://en.wikipedia.org/wiki/Undersampling#:~:text=In%20sig....
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#65I ran into this problem with a codec chip. We had to run the output at 48 khz, and the input and output clock had to be the same. Well we didn't have enough CPU to process the input at 48 khz, we only cared about 8 khz bandwidth for human speech. Boxcar averaging then decimating produced way too much aliasing, so much that the ML classifiers wouldn't work. The solution was putting a honking large FIR anti aliasing fi…
To clarify - you were able to run the FIR filter on the codec chip because the main CPU didn't have enough to handle the 48kHz input? Nifty story, just wanted to validate my understanding.
Yep that's it. The main cpu was a Cortex M3 or something like this. It's been awhile so my recollection is a little hazy.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#66If 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…
I think you're mixing up the effects of _sample rate_ and _bit depth_ here!
Everything you said about sample rate applies more to bit depth. Higher bit depth (bits per sample) results in a lower noise floor. When audio is digitally processed or resampled, a small amount of noise ("quantization distortion") is added, which accumulates with further processing. This can be mitigated by working at higher bit depths - which is why professional grade audio processing routinely uses 24 bit formats (for storage) and 32-bit or 64-bit floating point internally (for processing), even if the final delivery format is only 16 bit.
Sample rate, on the other hand, affects bandwidth. A higher sample rate recording will contain higher frequencies. It doesn't have any direct effect on the noise floor or level of distortion introduced by resampling, as I understand. (It could have an indirect effect - for example, if certain hardware or plugins work better at particular sample rates.)
A survey of ~2,000 professional audio engineers done in May 2023 showed that 75% of those working in music use 41.1 kHz or 48 kHz, while 93% of those working in post production use 41.1 kHz or 48 kHz.[1] These are the basic CD-derived and video-derived sample rate standards.
From this it's clear that even in professional audio, higher sample rates are a minority pursuit. Furthermore, the differences are extremely subjective. Some audio engineers swear by higher sample rates, while others say it's a waste of time unless you're recording for bats. It's very rare (and practically, quite difficult) to do proper tests to eliminate confirmation bias.
[1] https://www.production-expert.com/production-expert-1/sample...
EDIT: add link to survey.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#67So, we first need to find the highest motion frequency a sensor might experience in the experiment, and then make sure the sampling rate it at least twice that to avoid aliasing? Meaning, if an IMU sensor is mounted on a very slow moving, such as 2cm/s, RC vehicle then the sampling rate can be very slow. But if the sensor is on a fast moving drone, we need to estimate the highest frequency of the motion and make sure…
Yes, pretty much, but it depends. Your 2 cm/s RC vehicle might still experience high-frequency vibrations (in the range of the motor rpm) and you might want to sample that.
If we are not trying to capture motor rpm vibration - can't we just ignore it?
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#68I ran into this problem with a codec chip. We had to run the output at 48 khz, and the input and output clock had to be the same. Well we didn't have enough CPU to process the input at 48 khz, we only cared about 8 khz bandwidth for human speech. Boxcar averaging then decimating produced way too much aliasing, so much that the ML classifiers wouldn't work. The solution was putting a honking large FIR anti aliasing fi…
Did you try a simple iir filter and then decimation?
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#69If 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…
Higher sampling rate makes it easier to identify non-sound disturbances. Like vibrations or electrical, that can show up in multiple orders of some frequency.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#70Earlier quoted context omitted.
It’s been a few years but if I recall correctly the fact that there’s variation in the sampling itself makes the aliasing worse not better. At the very least should be no different.
I wonder if we're talking about different things. It sounds like one of your concerns is being catastrophically unlucky with the sampling rate: > This is because you run into aliasing with the samples being collected at unhelpful points. I interpret this as you saying "we sample at times T, 2T, ..., but there's a hotspot that hits at T+0.001, T+0.003, ..., T+0.999, 2T+0.001, ..., and we never get to visit it". I'll g…
It’s not about being unlucky, it’s the second thing you point out. It’s not the difference between 100khz and 100.001khz. You’re going to roughly alias at multiples of the sampling frequency, so you can’t tell between 2khz, 10khz, and 100khz which means that even if you collect enough signal, your 1Mhz signal with code running at 1ghz is going to potentially look like a 10khz signal leading you to make the wrong conclusions about where time is being spent.
Remember - profiling tools aren’t even giving you a frequency bin and indicating which samples you see there. It’s giving you a sample and estimating frequency. Most people are not optimizing code that’s running at millions of times per second so it’s not a common problem, but all sorts of wrong conclusions start to get made.