Resampling - If you can't avoid it...

(Latest update: 2021-Dec-02)

Introduction

I have recently delved into the topic of audio data resampling on multiple occasions. It seems that it is an area that cannot be overlooked for various reasons.

In my particular situation, my hardware setup (DAC) recommended experimenting with resampled data in order to potentially enhance overall performance.

During my online research, I came across a plethora of fragmented and incomplete information. It is evident that a significant portion of the available resources have a marketing bias. Additionally, there are numerous conflicting opinions regarding the most effective approach to handling this matter.

In this article, I aim to address specific elements, including the concepts of resampling, upsampling/downsampling, and oversampling. Additionally, I will explore the reasons behind the utilization of resampling, as well as the factors and targets related to quality. Furthermore, I will delve into the tools and applications involved in this process, particularly focusing on the implementation on LogitechMediaServer. Moreover, I will discuss the significance of offline resampling and provide illustrative examples. Now, let us commence our exploration.

Resampling !?! What are we talking about?

A digital audio sample reflects the digitally coded value of an analog signal at one point in time. The sample-rate on the other side defines the number of samples over a given time-frame. And resampling is the process of changing the number of samples in that given timeframe.

 Usually a second is used as the reference timeframe. The unit of sample-rate is therefore x/s. 1/s on the other hand is defined as Hertz (Hz). That's why you see the unit Hz/kHz/mHz being used in the context of sample-rates.

"Resampling" is the common technical term being used for changing a given sample-rate to another sample-rate. 

Up- and downsampling are giving resampling directions. Upsampling would be sample-rate x n and downsampling sample-rate / n. Where n follows the binary exponential function (n=2^x, for x =1,2,3,4)

For an upsampling factor of n=2 we'd double the total number of samples. 

4 samples at values 1-3-5-2 will become 8 samples at 1-0-3-0-5-0-2-0

There are different kind of methods to go up or down. 

1. Asynchronous resampling (44.1kHz  to 48    x N or    48kHz to 44.1 x N)

2. Synchronous resampling   (44.1kHz  to 44.1 x N and 48kHz to 48 x N) 

As ususal a Wikipedia article explains quite well what we're talking about.

Basically "N-1" samples will be added after each sample. 

At a resampling factor of N=2 we'll add one extra sample after each sample. 

4 samples at values 1-3-5-2 will become 8 samples at 1-0-3-0-5-0-2-0

Yep. I know. Just adding 0s or keeping the new samples at the same level wouldn't 

be of any help.

It requires a so called interpolation filter to fill the added samples with relevant content. 

Let's apply a interpolation filter.

Starting with 1-3-5-2  would get us to 1-2-3-4-5-(4?or 3?)-2-1  

Hmmh. You can see that we also run into issues with this interpolation method:  

This approach would be called linear interpolation. As you can see at certain values the situation gets ambiguous.

We just connect 2 original samples by a line and use the in-between value on that 
line for the new sample. 

Since there's nothing linear on waves you can see that this method will also cause losses/distortions. We end up with a sine wave of a finer granularity staircase that shows some linear slopes. Not perfect. But potentially a bit better. 

How much of impact of these flaws we'll notice ( or better hear) later on is a different question.

Let's keep it for later.

Why resampling?

There are several "good" reasons why audio designers and manufacturers resample the incoming data.


1. You fight aliasing effects

     Aliasing effects are frequencies in the audio band that don't belong there.

     It starts with frequencies higher than the Nyquest band (sampling frequency/2) 
     >> 22.05 kHz for 44.1kHz data that fold back into the audible range.

     That's the short version. ;) Have a look at Wikipedia for more on that.
     
    The required aliasing filter has to be very steep. It would require a very steep
    filter at about 100db attenuation to get all the dirt out from 20 to 22.05kHz  - in theory

    if you don't want to start the filtering in the audible audio band.

    Steep and aggressive filters usually come at a price. Usually they generate plenty
    of distortions. And if you're close to the audio band that's not good. These distortions
    might become audible.

    If you start your filter lower than 20kHz, you will obviously not just impact the distortions,
    no  you'll also impact the audio signal.

    The filter quality can make a huge difference. There's a so called "Filter Brewing" thread
    over at DIY-Audio. The discussions show what differences a filter. Usually you'll get a good
    picture when looking at the transition band graph.

    The higher the samplerates, the less aggressive - thus less intrusive - the filters
    can be configured. 

    And that's the 1st reason to give resampling a try. Replacing aliasing filters that otherwise
    could have impact in the audible frequency range and move them up the spectrum.

2. You try to fight jitter

    I guess you heard about jitter. I simply quote Wikipedia:

    "jitter is the deviation from true periodicity of a presumably periodic signal"

    Low jitter in the single digit picosecond or femtosecond area is what a good
    DAC needs to deliver in 2020+.

    Many DAC manufacturers are trying to fight incoming jitter by introducing
    asynchronous HW resampler (ASRC). The whole stream will then be resampled to a certain
    samplerate by using a highest quality clock.

    That ASRC chip, which ususally sits right in front of the DAC chip. In most cases this method
    reduces jitter seriously. Sideeffect:  You'll also end up with a single samplerate. 

    As usual there's a catch. Usually the ASRC sampling algorithms are not of highest quality.
    And HW-ASRCs are not lossless and jitterfree either. These chips can introduce jitter or noise
    on their own. Another viable reason trying to feed external SRCed data.


3. One samplerate for all 

    Certain DSP applications (e.g. MiniDSP) and operating systems such as Windows, Linux
    Android, OSX can only work with a single samplerate in normal operation mode.
    They do it to be able to handle different samplerates from different streams, sources, processes,
    inputs at the same time. 

    Don't expect highest quality from these usually quite basic on-the-fly resamplers! 


4. You bypass a potentially lower quality HW implementation from the SW side

    See 2. 
    Usually most HW resampling implementations do not have sufficient horsepower
   (resources) to offer highest quality resampling algorithms. That can lead to mediocre
   results.

5. (Implementation) Cost



Plenty of reasons to give it a try.

However. There's no such thing as a free lunch...

Digital Losses

Any digital filter  - respectively its related algorithms and calculations (e.g. volume control, convolution, crossover filtering, digital filters, resampling, equalization) - introduces losses to the original signal.

Usually multiple stages of data processing are passed to accomplish the resampling task.
E.g. if you resample your data, you won't just multiply your samples by a certain factor.
No, you'll add some new (artificial) interpolated samples that usually come with nasty side effects calling for more filters. 
And then you also have to attenuate the signal before upsampling to avoid clipping. 
Low level detail will suffer most at this point. And on top you might add a little noise (dither).

Beside that you'll see additional load on a system caused by more extensive data processing. Usually this causes another type of distortion (e.g. noise).


Bottom line. There's a lot of stuff to consider. Ending up with an objective better result will
depend on quite a number of factors and a lot of in-depth research, measurements and listening.


For me the driving factor of this exercise is to find the "better compromise".

The project

One of my DACs internally converts the samples to  352k8/384kHz. And then applies this or that filter afterwards.
The datasheet shows that this DAC won't apply its internal filters at 352k8/384kHz samplerates . 

That means if I now feed 352k8/384kHz data, these data will bypass the DACs internal sampler and filter.

I'm basically now trying to bypass these potentially mediocre on-dac filters, by using a top quality resampler on the outside. 

The challenge at this point is, you won't find many IMO useful information of how to configure the resampler in the best possible way. 
There are infinite ways of configuring your SRCs. Pretty much all of them end up with
a slightly different compromise. These compromises - as the term suggests -  are all flawed - some more some less. 

And that's why there's no "that's it" solution. It'll be a matter of taste and environment if
a solution works for you or doesn't.

A good starting point for a rather objectve approach is the infinite wave site. 
Over there you'll find pretty much all state-of-the-art resamplers compared side-by-side 
on a technical level. They show the most relevant graphs for a huge selection of SRCs.

Sound differences are not discussed! For a good reason! These discussions never really
end up well.

So. What resampler should we use then??  To make a long story short:

We are going to use the very powerful sound processing tool called sox.

sox IMO, and according to infinte wave, can compete with the best commercial audio resampling tools out there. You get an idea once you've been on the infinite wave site.

I also compared quite a while ago sox with e.g. Izotope, Adobe Audition and Voxengo r8brain -- highly regarded commercial tools "soundwise". For me there was no reason to switch to either of the commercial siblings.

sox is very flexible, fast, runs headless, it's free and it's available on all computer platforms.

It's also part of e.g. Logitechmediaserver or can be used with squeezelite or MPD. Even JRiver Media Center under Windows makes use of sox and there you have t pay for  it!.

DACs

The vast majority of DACs and soundcards run samplerate converters in front of the actual
DAC chip. Several devices out there lift internally samplerates up to 352.8/384kHz. Some (E.g. Sabre DACs) even higher than that.

You'd actually need to find out what your DAC is doing. You'd need to find out if and how your DAC resamples your data. As far as I know iFi DACs, with the Burr Brown chips inside, do not touch the data at all. The result of your research defines if and how you should run this exercise.

Your DACs internal processing samplerate, should then be your target samplerate.

There are traps of course.

Some devices do internal DSP processing prior to the DA or even ASRC process.
It might happen that the data gets upsampled to just 96 kHz first to e.g. feed an internal DSP. Than this could be your target samplerate and the actual DAC chips or ASRC rate wouldn't matter anymore. You need to get to know what's going on inside your DAC is all I'm saying.

E.g. my Allo HAT DACs  based on the TI PCM51xx DAC family come with 4 filters options
These filters get bypassed at samplerates of 352.8/384kHz.  That's my hook.
I just assume that these internal filters are not of highest quality and hope that my resampled
material just gives better results.

On ESS Sabre based DACs things get tricky. ESS resamples the samplerates beyond the capabilities of sox or any other resampler. 

However. If you don't find out about your DACs internals. Feed the highest sample rate it offers.

Bottom line. 

My goal would be to experience a better soundquality through bypassing the internal filters by feeding upsampled material.

Quality

Let see if we can find out about different resampling qualities.

First I already mentioned  the  infinte wave  site. You'll find many resamplers and resampler configurations listed. It's the best place to get an idea about resampler quality.
Read the help  section over there first to understand what they are talking about.

You need to realize though that not just one parameter makes a good resampler.
A perfect graph in one area might cause artifacts in another area.
E.g. Very high bandwidth settings with very steep filters are causing a lot of bad ringing due to the filters. Especially the pre-ringing part is bad. Usually things sound quite aggressive and sharp.
On the other hand filters with no or low pre-ringing are causing serious phase-shifts, which usually translates into loss of details. 

Yep. You can't have it all. For that very reason the industry out there continuously tries to improve the filters btw.

Of course it's not all black and white. There are acceptable compromises.

You'll see that the  different 14.4.x sox resampling modes listed over at infinte wave perform quite well.

Our task is now is to find the "best" resampling options.


I scanned the net and couldn't find any kind of common conclusion about what would be the best (compromise) set of resampling options for sox.
You'll find out about the theoretical and measured differences. But no common opinion about the best method from a listening perspective.

As I suggested earlier. Perhaps there's none. They are all compromises.
It might be a matter of taste after all, since all settings add their own sound signature!!!
It's a bit like rolling tubes.

But again. For me the task is to find the best compromise for a certain situation. If we cannot avoid resampling, we at least should get it done in the best possible way.

Below a copy of Sox resampling mode comparisons.

What you see is the pre- and post ringing filtering results of different options.
Ringing (pre-and post) effects are one type of filter losses they're talking about in above graph.
The nasty pre-ringing effects that you see to the left from the 0 line (purely mathematical leftovers)  should be avoided as much as possible.


You'll also see the formerly "highly regarded" ssrc resampler results at the bottom in above comparison. ssrc is ( or perhaps used to be) used by dbPoweramp btw. I won't comment on that: Pictures say more then thousand words. I also did listening tests comparing ssrc and Sox. I've taken my choice.


Below you'll see an typical impulse response (source: inifinitewave.ca) of a linear filter. The result should be a straight single upright line in a perfect world.
The waveform (ringing) to the left (pre-ringing) and right (post-ringing) of the center of the pulse are filter associated flaws. These artifacts will be added to the original music signal!!

We can continue with phase shifts, pass-band restrictions ( not the entire frequency band is transferred ) , noise , inter-modulations, aliasing... ...you name it.


There are losses. No question. We need to find the best compromise.
Most flaws are popping up at extremely low levels of -170db  if highest quality SRCs are used.
Levels, much lower then any DAC out there would be able to reproduce. And of course these should be inaudible.

However. Why do people hear differences !?!? I don't know. We look at  of a mix of complex signals/artifacts at a certain time. A complex audio sound, not a simple 1kHz test signal, might cause a lot or artifacts. At one point the related issues fold back into the audible range. Who knows!??

Fact is. There are audible differences between the different algorithms and tools.

Exercise

I put together some instructions for those of you, who'd like to play around a bit with resampling your 44.1/16 base data to higher samplerates on-the-fly.

Let's see how to implement resampling on a Logitechmediaserver to feed a SB Touch, Transporter or e.g. Squeezelite.


The key challenge as mentioned earlier is to find the right balance between potential losses and gains when looking at the entire resampling process. It's not only about the above mentioned filter associated losses.

Note: For those readers who run piCorePlayer. You can skip below part of the article and exercise. You should switch now to the piCorePlayer and squeezelite specific article "the converter" of The Audio Streaming Series.

III. Platform independent conversion rule cases

Below you'll find some conversion rule examples.
Everything will be resampled  from 44.1/16 ( or any other rate) to 354800/24 and sent down to the DAC as flac!!

If you like you can change the target sample rate up 2 384khz, by swapping the corresponding numbers within below examples. 

The actual key difference between case 1. and 2.  are the "-I" and "-L" options.

L=  linear phase response (pre=post echo)(=default sox setting)  and 
I =  intermediate response which is supposed to be a good compromise to 
M= minimum phase response ( no pre-echo, longest post-echo). (see also sox manual).
     Minimum phase introduces phase shifts in the higher range ( > 4khz).

-v      = very high sampling quality
-a      = allow aliasing above passband  (causes less post ringing)
-b 98 =  bandwidth of passband is set to 98 ( I tried 85, 90, default 95 - for now it's 98)
-s     = alias for -b 99
-D   = suppress automatic dithering


I skipped gain adjust in all cases. That might cause some clipping on a few samples. Of course you better should add e.g. the option " gain -1 " for attenuating the signal prior to resampling it. See Case 3.


Note: 

The resampled data are converetd to 24bit. This helps avoiding dithering (artificial noise) !!!

Keep in mind that the original 16bit CD data is dithered already. 
Dithering is the final task the mastering engineer does in the mastering process.
Basically there's quite an amount of artificial noise on your CD already.

Dithering twice - original and now during resampling - with potentially two different dithering algorithms might lead to lower quality.

However. There are opinions that say that all DSP calculations are done in 32bit/64bit floating point. Getting these down to 24bit again would justify to add a certain amount of dither. 

Again. As many opinions as options out there. 


Let's have a look at the cases.

Offline resampling

For your initial tests the easiest approach would be to convert a single test 

file manually, thus "offline".

Below example shows how you can accomplish offline resampling of a file from a Linux command line.

There are also GUI based sox tools available to accomplish this task. Try to google "sox GUI"

Offline Case 1 (my preferred setting- Jun/2020 )

Upsampling a flac file to 352800 Hz. I use my favorite filter settings.

• the flac will be re-compressed to compression level 0 (-C 0)
• the target bit depth will be 24bit (-b 24) (most DACs even support 32bit nowadays)
• very high quality resampling (-v) is chosen (requires powerful CPU!)
• 95.4% bandwidth (-b 95.4)
• a phase shift of 46%  (-p 46) slightly away from linear (50%)
• allow aliasing (-a) (no issue at 352k8 Hz)
• a tiny bit of sloped TPDF dithering (dither -S)
• dither with a target precision of 23bit (-p 23)
            

The result comes with rather low pre and reasonable postringing and with just a little phaseshift. I allowed aliasing (-a) to lower the ringing effects even further. And added a little dither. I have chosen 352800 instead of 384000 as target rate because 99% of the material out there is 44.1kHz. 

In most cases I therefore see synchronous upsampling.

Note: You need to swap the filenames matching your filenames in below command

##offline resampling - command line########################

sox  test1.flac -t flac -C 0 -b 24 test1-src.flac rate -v -b 95.4 -p 45 -a 352800 dither -S -p 23

#####################################################

That's already it. Now you can playback your new and converted file.

Realtime Resampling

Below cases show how the realtime conversion can be accomplished on a Logitechmediaserver.


Case 1 (my preferred setting- Jun/2020 )

Realtime Case 1 is the same case as the Offline Case 1.
   
Below you see the matching Logitechmediaserver conversion rules for target formats
.flac and .wav. These rules must be added to the custom-convert.conf file (see Annex 1 for help). The server has to be restarted after adding these lines.

Note: The "# F" means only local files get converted. No streams!

##copy below into custom-convert.conf########################

flc flc * *
             # F
             [sox] -q -t flac $FILE$  -t flac -C 0 -b 24 - rate -v -b 95.4 -p 45 -a 352800  dither -S -p 23


flc pcm * *
             # F
             [sox] -q -t flac $FILE$  -t wavpcm -e signed  -b 24 - rate -v -b 95.4 -p 45 -a 352800  dither -S -p 23

#copy above########################


NOTE1: 

You can do selective routing and resampling on a per client basis by adding your
clients MAC address to above rules like this:  

The 2nd asterisk gets replaced with your clients MAC:

flc flc * b9:af:e1:70:08:31


flc pcm * b9:af:e1:70:08:31


Having just two asterisks would mean that all your clients would receive resampled material.

NOTE2: 

For resampling to work for flac to pcm (wav) on LMS you need to add "-W" to the squeezelite startup options!
squeezelite than reads the samplerate info from the data file header and neglects the info send by the server.




OR



Case 2

   I = Intermediate phase is supposed to be the best compromise between
   M = minimum phase and L = Linear. 
   It stands for rather small pre-ringing, reasonable post ringing
   It still comes with the phase shift!

##copy below########################


flc flc * *
             # F
             [sox] -q -t flac $FILE$ -t flac  -C 0 -b 24 - rate -v -I -b 90 -a 352800  


#copy above########################



Case 3

  This is Case 1 with signal attenuation of 1db prior to resampling

##copy below########################


flc flc * *
              # F
             [sox] -q -t flac $FILE$  -t flac -C 0 -b 24 - gain -1 rate -v -b 90 -p 50 -a 352800  dither -S

#copy above########################



I stepped over an interesting discussion over here or here,  which led to cases 4a and 4b.
Basically a guy called "viruskiller" tried by using sox to mimic the highly regarded resampling  "apodizing" filters done by Meridian and as done by Ayre.
Avoiding ringing artifacts is the ultimate goal.

As you'll see cases 4a/b differ from above solutions. These solutions use minimum phase filters first of all and also lower the bandwidth substantially.
Minimum phase filters supposedly have no phase shift in the passband. And won't cause
preringing. Then there's aliasing allowed to reduce the postringing even further

Case 4a consists of a minimum phase filter and the bandwidth is limited to 20khz (-3db point) (90.7) which allows for less steep filters - aliasing is allowed which is causing less post-ringing, and shouldn't folds back artifacts in the audible range at these high target samplerates.

The examples 4a/b also recommend to apply a slightly sloped TPDF dither.

Usually you just need dither if you go down to 16 bit again. I left it in. It won't hurt I guess.


Case 4a (supposedly similar to filters offered by Meridian)


##copy below########################


flc flc * *
              # F
             [sox] -q  -t flac $FILE$ -t flac -C 0 -b 24 - rate -v -a -M -b 90.7 352800 dither -S



#copy above########################


Case 4b (supposedly similar to filters offered by Ayre)

##copy below########################


flc flc * *
         # F
         [sox] -q  -t flac  $FILE$ -t flac -e signed -C 0 -b 24 - rate -v -a -M -b 87.5 352800 dither -S



#copy above########################




#####################################################


Results


Using M - minimum phase  and I - Intermediate phase filter settings seemed to cause slight distorted sound to me. 

Maybe the phaseshift in the upper frequency range's causing it ?? (see infinite-wave charts for Sox M settings)

It translates into loss of low level details. I experience disappearing (smearing) of instruments in the back row of an orchestra . The separation suffers. To me it's like a softened image.

Case 1 is my currently best idea. It's little softer then a pure linear maximum bandwidth approach, a little less sharpness, without that minimum phase blur and it also comes with
a very nice articulated low end.

The basic idea behind of all this was the slight chance that some downstream electronics might respond better to resampled data. That's been accomplished in my case. I do prefer the synchronous upsampled approach on my Allo DACs that come with the TI-PCM51xx family DAC chips.


Above filter examples are IMO a good starting point. I am by no means a DSP filter guru. 

I tried to choose highest quality configurations, which made sense to me and which were available and discussed on the net.

I'm sure there's some more fine-tuning potential. From all I read during the last days there seems to be no right or wrong. Many people consider the discussions around the subject of theoretical nature when it comes to soundquality.

I for myself can hear clearly differences with pretty much every parameter change.

It's usually a matter of system, taste, expectations, experience what filter signature sounds best to you.

I highly recommend to give all that a try. You can't do anything wrong. It's all there. And it's all free of charge.


Enjoy.


##################################################
##################################################
Annex 1: Custom convert-conf


Let's prepare your server for introducing the conversion rules to the custom-covert.conf file. 

I. Windows 7

1. Open notepad with admininistation rights ( right click on app within submenu accessories)
2. load convert.conf from c:\Program Files <x86>/Squeezebox/server
3. Save as "custom-convert.conf"
4. delete everything inside ( make sure that you don't delete your original convert.conf contents!!!!)
5. Copy one of below conversion rules into the editor
6. Save your "custom-convert.conf"
7. Restart your server 
8. Select "flc flc" option "flac/sox" in "file type" advanced settings and push "Apply".  

Deactivation:
9. To disable the setting just remove custom-convert.conf or its content and restart the server.

II.  Linux (Debian based systems)

You need to  generate an /etc/squeezeboxserver/custom-convert.conf
file with either of below conversion rules (lines between hashes).
The settings within this file will override the default 
/etc/squeezeboxserver/convert.conf settings. If you'd do the changes inside the
convert.conf, which would be an option,  your changes would be gone with the next SB server update/upgrade. Beside that it's not that easy to disable those
settings. By using the custom-convert.conf  you just move the file to e.g.  custom-convert.conf.bak and restart the server.

1. Open a terminal
2. sudo touch /etc/squeezeboxserver/custom-convert.conf
3. sudo chmod 666 /etc/squeezeboxserver/custom-convert.conf
4. sudo gedit /etc/squeezeboxserver/custom-convert.conf
5. Copy one of below conversion rules into the editor

6. Save your "custom-convert.conf"
7. Restart your server 
8. Select "flc flc" option "flac/sox" in file type settings and push "Apply".

Deactivation: 
9. sudo  mv /etc/squeezeboxserver/custom-convert.conf /etc/squeezeboxserver/custom-convert.conf.bak
10. reboot 




#############################################