Up, over, and resampling


I tried asking this elsewhere and got a few anecdotes (more are always welcome), but I was really hoping for some links to technical papers (that I may not fully grasp. I haven’t kept up my college calculus.)

Does anyone have links to educational articles or papers on upsampling, oversampling, or resampling? I know there’s no new information generated, but it still theoretically helps DAC performance, right? Is there a downside as long as the implementation is solid? And what qualifies as correct?

I had a CD player many years ago that had an upsampling add on board. Impossible to quickly A/B, but it certainly seemed to enhance the experience enough that I had zero regrets with the upgrade. I think it converted redbook CD to 24/192. So I’ve had a positive early experience, But I see NOS DACs are crowed about, while there are others embracing a more is better approach  

I’m trying to research a little because I finally got around to reading some of the manual for my new streamer. (So I don’t screw up ripping all my CDs for, hopefully, the last time.) I realized it has options for resampling during playback. If I’m using the USB output it always sends at 32bit but can also goose PCM up to 8x (384kHz max). S/PIDF output is bumped to a maximum of 24/192. I don’t hear a big obvious difference, but I haven’t spent much time looking for one either. Without any DSP down the chain is resampling really worth it? And if I were to some day splurge and get an M Scaler or similar would it make sense to disable any resampling by my streamer in favor of a presumably better dedicated component?

Because it will be asked. My virtual system is mostly current. CD player was an Ah! Njoe Tjoeb, that was mothballed years ago when the transport started getting twitchy. The streamer is an AURALiC Aries G1.1. DACs are Chord Qutest or Soekris dac1421.

cat_doorman

This is a really good overview on oversampling / upsampling from Analog Devices:

 

https://www.analog.com/media/en/training-seminars/tutorials/mt-017.pdf

 

If you need more information, I suggest using the keywords "multirate digital signal processing" when you do your online search.

I’m not sure I’m understanding where you’re going here- I had a quick look at the Aries G2 manual (couldn’t find for G1) and the only mention of “upsampling” had to do with streaming MQA files. Apparently there is a setting that will employ this action during the “unfold”.

As for passing files through I don’t believe this unit “upsamples” PCM native 16 bit to 32 but rather “supports 32 bit files” when output via USB. The standard SPDIF formats (coax,Toslink and AES) support up to the standard 24/192.

Either way- not sure how your planning on configuring your NAS storage drives or if you’re streaming across a network from another ripper/playback unit but I would always rip the music in its native format.
 

If I remember correctly the Soekris will not upsample and will accept files up to 24/192. I’ve no experience with Chord but I believe some of their units will upsample- just not sure if the Qutest will or not. 

@yage thanks for the link, I’ll need to carve out some time to focus on it properly

The current process of ripping was just what prompted me to look at the manual and discover new things. Ripping is done at native redbook to FLAC.

I find the three terms upsampling, oversampling, and resampling confusing because while I’m fairly certain they have distinct technical meanings, they are often used interchangeably. If I use one wrong then please correct me. I’m trying to get a better handle of this.

The Aries G1.1 upsamples all files, adding null bits to make bigger words. When sending S/PIDF 16 bit becomes 24 bit. For USB all samples become 32bit. This is independent of source, library files or streaming services, all are upsampled. This would be like adding trailing zeros after a decimal point. The number is unchanged but the available precision is greater for subsequent manipulation, like volume control or DSP.

The oversampling is usually a multiple of the native rate  44.1kHz can become 88.2, 176.4, or even 352.8kHz which is 8x over USB. (Similarly 48kHz can become 96,192, or a max of 384kHz.) At its crudest existing value repetition could be used, but I think the more sophisticated approaches interpolate intermediate values or try to recreate more of the original waveform by complex iterative algorithms. No idea what method the Aries uses or the computing power required. I think some DACs perform a similar manipulation allowing the use of less harsh antialiasing filters that keep artifacts well beyond human hearing

Resampling I think is both simultaneously and not necessarily in multiples and can have more issues. Changing sampling rates by non multiple factors seems like it could be especially problematic. That might be why so many devices have multiple clocks, one for 44.1kHz multiples and one for 48kHz multiples

i haven’t tried the USB with the Soekris  The Qutest is supposed to be galvanicly isolated and have a great USB input. It might be the change in streamer or going to USB or a magic cable, but there are a lot of cliched impressions I could share about first trying the Aries Qutest combo after using a Node2i for almost 4 years, 3 of them with the Qutest. Node2i will find use somewhere. Too good not to use, but not worth selling.

Ultimately I want to pick the best set of parameters for me based on theory and verified by listening (even though I’m not sure what to listen for). Hoping that if I understand it better then I’ll be less likely to do something incredibly boneheaded in the future if there are changes in affordable tech  

 

 

 

Upsampling and oversampling with respect to audio playback is essentially the same function. In the DSP world you can usually find it explained under the topic of multirate interpolation. The incoming data is zero-padded to the desired sampling rate and the digital filter interpolates the values. The interpolation step is not a ’guess’, it’s more akin to a ’recovery’ of the sample values as if you had originally sampled the signal at the higher frequency. When the interpolation filter’s impulse response is convolved with the audio data, the filter coefficients multiplied with the other samples in the signal along the length of the filter will essentially fill in those zero-padded positions.

 

Resampling by a non-integer factor doesn’t involve the system clock. It is upsampling (zero-padding) by an integer factor followed by an anti-aliasing filter and downsampling by another integer factor. The resampling ratio is given by the upsampling factor divided by the downsampling factor. Here is a link to a good overview - https://www.eetimes.com/multirate-dsp-part-2-noninteger-sampling-factors/

 

The computational load is based on how many coefficients the digital filter has (i.e. the length). The ideal filter for audio purposes is the sinc function. However, it is impossible to implement because it would have an infinite number of coefficients. The digital filter is always an approximation and there are many approaches and algorithms to construct these filters. Also note that the longer the filter, the more delay it introduces into the reproduction process.

 

Here is a free online book on DSP that you’ll probably find useful:

https://www.dspguide.com/

 

Here are some informative videos that explain some of the fundamental concepts of digital video / audio:

 

Digital Media Primer for Geeks

Digital Show and Tell

The oversampling is usually a multiple of the native rate 44.1kHz can become 88.2, 176.4, or even 352.8kHz which is 8x over USB. (Similarly 48kHz can become 96,192, or a max of 384kHz.) At its crudest existing value repetition could be used,

 

OP: Well wish you had read my post. This is the ONLY definition of OVERsampling there is. The original values are repeated. This requires no processing but improves the behavior of the output filters. If it isn’t doing exactly this it is something else.

The crudest, best and average oversampling systems all do this. The only variable is the number of oversamples per original.