Earlier quoted context omitted.
It's a multiple of 7? It doesn't have big factors? I don't know what I'm supposed to be surprised about.
44100 = 210^2 = (2 * 3 * 5 * 7)^2
I'm still confused.
Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
51–60 of 79 posts
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#52Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#53Earlier quoted context omitted.
What _is_ the reason people should prefer 48k over 44.1k though?
All TV and computer audio runs at it, raise for TV/Film purposes 48000 is a very nice round number.
While audio equipment and algorithms don't care about nice-looking numbers, I think the actually useful property is that 48000 has more favorable prime factors 44100 which can be a useful property for resampling and other tasks.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#54For anyone interested in an interactive tool for playing with the concepts noted, here’s something I put together a while back for demonstrating to colleagues: https://www.desmos.com/calculator/pma1jpcuv0.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#55Earlier quoted context omitted.
> 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. Surely for this to happen you'd have to be putting a lot of effort into getting a perfect 1ms sampling rate, and even a little bit of variation in that would be more than enough to handle ali…
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 grant that this could happen, altho it seems contrived, but my claim is that by sampling at "T+/- epsilon, 2T +/- 2 epsilon, ...." sooner or later you're going to start hitting that hotspot. And before too long if, say, 5% of the time the CPU is executing that code you're going to hit it, on average, 5% of the time.
It'll be aliased, sure, but in a way that smears across all frequency bins instead of getting missed. You won't be able to recover the true frequency (at least not without fancy sparse methods) but why do you care? The important question is "where is the CPU spending its time" and not "is this function being entered 100000 times per second or 100001 times".
Here's another general objection. The things being sampled are square waves: a function is either in the call stack or it's not, the program counter is either at a particular location or it's not, and so on. That means you're going to have energy at all odd partials, which you'll have to account for somehow, but however you do it it's not going to reflect the underlying behavior.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#56This is the most lucid explanation of aliasing I think I've ever read.
I mostly deal with this stuff in the realm of audio where the matter of analog vs digital rages regularly. The reason one hears "Nyquist says" so often from people defending digital audio is that the pro-analog people are imagining stair-stepped signals in which the information that is "lost" results in a noticeable degradation in sound quality. This (11-year-old) video is the gold standard for addressing this concern:
https://www.youtube.com/watch?v=cIQ9IXSUzuM
Curiously, no one ever seems to mention the actual problems (like aliasing).
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#57Earlier quoted context omitted.
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, ev…
With music, in particular, if you use any analog sources while recording, the signal will contain so much noise that any dithering signal will be far below the floor and will most likely be completely redundant. I know that people claim to hear a difference, but they also claim to hear a difference between gold and copper contacts.
I hear no difference between undithered 16 bit and anything "better" (e.g. dithered 16 bit, or more bits) and anyone who claims they do should be highly scrutinized, when we're talking about a system (media, DAC, amplification, transducer, human) playing a mastered recording at a moderate volume setting. But I certainly hear the difference (as quantization artifacts) when cranking the volume up to extremely high levels when the source material is extremely quiet, like during a fade out, a reverb tail, or just something not properly mastered to use the full range; setting the volume to something that would totally clip the amp, blow the speakers, or deafen me if it weren't a very quiet part of the recording.
Dithering (or more bits) does solve for this. A fade out of the song also lowers the captured noise floor, but the dither function keeps going.
It's akin to noticing occasional posterization (banding) in very dark scenes if your TV isn't totally crushing the blacks. With a higher than recommended black level, you will see this artifact, because perceptual video codecs destroy (for efficiency purposes) the visual dither that would otherwise soften the bands of dark color into a nice grainy halftone sort of thing which would be much less offensive.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#58Earlier quoted context omitted.
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, ev…
> even just a volume change by the listener if it's applied digitally in the 16 bit realm ... I think that "if" is doing a heavy work here.
Maybe it's an uncommon scenario these days, but not too terribly long ago I think it was fairly typical for software audio players to be 16-bit and offer volume controls, and anything other than 100% would completely ruin most benefits of dither.
Re: Sampling: What Nyquist didn't say, and what to do about it (2018) [pdf]
#59Earlier quoted context omitted.
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…
What _is_ the reason people should prefer 48k over 44.1k though?
To avoid the required non-integer resampling in software, as everything but music has basically standardized on 48k, and most platforms default to it.