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

(Latest update: 2026-Apr-09)

Introduction

I have looked into audio data resampling on multiple occasions over the years. It is one of those topics that simply keeps popping up, whether you want it or not.

In my case the trigger was simple. One of my DACs internally converts the incoming data to a higher sample rate. That raised the obvious question whether it might be better to do the resampling outside the DAC, using a high-quality software resampler and filter settings of my own choice.

With the renewed interest in NOS and R2R DACs, the subject has gained new relevance. The question is no longer just whether resampling happens, but where it happens, how well it is done and what trade-offs come with it. Basically if you don't feed a NOS DAC with HiRes data, you'll face aliasing effects.

Applying a slight resampling of e.g. 2x to 44.1/16 base data might be worth the effort. 

During my research I found a lot of fragmented information, plenty of marketing talk and very little that helped build a practical overall picture. This article is my attempt to bring the relevant pieces together: what resampling is, why it is used, what it costs us, what a DAC might already be doing behind the scenes and how I approached the whole thing in practice by using the still state-of-the-art audio tool Sox and for real life playback the Lyrion Media Server (formerly known as Logitech Media Server).

As an engineer, I mainly look at the theory and mathematics behind the filters, at measurements and at the practical compromises they reveal. But I also consider listening indispensable. In my own tests I do hear differences between certain algorithms and settings. What I cannot yet fully explain is which measurable mechanisms are responsible for that perception in real music playback. To me, the gap between theory, common measurement practice and actual listening experience is still not satisfactorily explained.

Editorial note added in 2026: This article started in 2011. I left its practical intent intact, but revised parts of the text for clarity and now try to separate more carefully between measurable differences, theoretical implications and actual audibility.

The actual question

Before digging into theory, here is the actual question I wanted to answer:

If a DAC resamples internally anyway, most of them do, can it make sense to feed the DAC already resampled data from a potentially better software implementation and thereby bypass and improve parts of the DAC's own internal processing?

For certain DACs the answer can be: yes, it is at least worth trying. For others it won't make sense at all. 

Let's exclude the "others" quite extensive group once an forever first - the easy part. If you don't know how the resampling is done inside your DAC and you can't match the internal sample rate of your DAC to an external sample rate converter, resampling is a NoGo. You'll have a great chance to at least double the associated losses. Two SRCs in a row can't make things better. Never. 

There are "others"  DACs e.g, ESS Sabre DACs which internally upsample to 1.536 MHz. No need for you upsample. Or if you use newer AKM DACs these oversample 256x! 44.1KHz become 11.2Mhz. Don't even try - you can stop reading now - better listen to some good music !

For NOS/R2R or native DSD (out of scope!) DAC users the question to SRC or NOT-TO-SRC can become really interesting, because digital filtering and SRC decisions get pushed further up the chain and are therefore more exposed. Meaning. It's on your desk, you can steer it - you are the captain.

The whole exercise is not about finding perfection. Getting a step into that direction is part of the game though. It is about finding the better compromise, because at one point every processing chain will force you into a compromise. No matter what you do you'll face losses. This project tries to rely on theory, measurements AND listening to get a step closer towards perfection - finding a better compromise.

How much of a compromise depends: Can you hear it, notice it, care about it, is it worth the effort...

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 hand, defines the number of samples within a given timeframe. And resampling is the process of changing that number of samples within the same timeframe.

Usually one second is used as the reference timeframe. Sample rate is therefore expressed in samples per second. The unit 1/s is Hertz (Hz), which is why you see Hz or kHz used in this context.

"Resampling" is the common technical term for changing one sample rate into another sample rate.

Upsampling and downsampling simply describe the direction. Upsampling means multiplying the sample rate by n, while downsampling means dividing it by n, where n can be an integer factor, often following powers of two.

There are two basic resampling principles:

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

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

2. is the preferred choice, because it generates lower losses. You stay in an even framework. Asynchronous resampling though requires special resampler implementations to cope with the associated issues. Usually the data gets sampled to insane high samplerates where the relative losses are much smaller and from there these SRCs resample back to the target sample rate. It works.

In both principles new samples have to be generated. Just inserting zeros or just holding the level would obviously not be enough. It requires an interpolation filter to fill the added samples with meaningful content.

A very simple example would be linear interpolation. We connect two original samples by a straight line and take the in-between value from that line. It is easy to understand and easy to implement. However, waves are not linear. Waves are curves - if we talk test tones a rather ideal curve.  Much less of an ideal curve on real music or recordings though - that's where things become tricky. So even this very simple example already shows the core issue: resampling is never just about adding whatever samples, it is always about the quality of the interpolation mimicking the natural sound and the associated side effects to get there.

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 Nyquist band (sampling frequency/2) that fold back into the audible range. For 44.1kHz material that starts beyond 22.05kHz.

The required aliasing filter has to be very steep if you don't want to start filtering already inside the audible range. And steep aggressive filters usually come at a price. They can generate distortions and ringing. If those effects happen close to the audio band they might become audible.

The higher the sample rate, the less aggressive, and therefore less intrusive, the filters can be configured. And that's one major reason to give resampling a try. You push the problem up the spectrum and make the anti-aliasing filter's life easier.

2. You try to fight jitter

 DAC manufacturers (like ESS) fight incoming jitter by introducing asynchronous hardware resamplers (ASRC). The stream gets resampled to a certain fixed sample rate by using a local clock of usually very high quality. That reduces incoming jitter significantly. 

As usual, there's a catch. ASRC realtime algorithms not are not necessarily of highest quality. And hardware ASRCs are not lossless/jitter-free either. These chips can add their own noise and artifacts.

3. One sample rate for all

Certain DSP applications (including active DSP based speakers, room equalization, asf)  and operating systems such as Windows, Linux, Android or macOS often force a single sample rate in normal operation. They do it to be able to handle different streams, sources, processes and inputs at the same time. To keep the load low they usually use rather low Q algorithms by default.

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

However. Some OSes allow to change the associated quality levels or even bypass the internal SRCs.

And feeding your active DSP speakers with it's native sample rate material, resampled at best quality, will also be well worth a try.

4. You bypass a potentially lower quality hardware implementation from the software side

Usually most hardware resampling implementations are more constrained in resources than a software solution running on a general purpose CPU. That does not automatically make them bad. It simply means that implementation quality matters and should not be taken for granted. The problem: modern high quality DACs do internal resampling at frequencies out of reach from external resamplers.

5. Implementation cost

Implementation cost matters too. Built-in hardware solutions often have to meet strict cost, power and silicon constraints, whereas a software resampler on a general-purpose CPU can spend more compute on filter quality. There are numerous top quality resamplers to be found on github and elsewhere. Cost no object on this side.

Bottom line, from my experience resampling algorithms including any other DSP filters, generate rather subtle changes on a high quality audio system for the better or worse.  As long as we all as listeners conclude sessions from "like it" over "dislike it"  to "love it", we've got plenty of reasons to look into the subject more thoroughly and go after it.

Now, talking about compromises, there's no such thing as a free lunch...

Digital Losses

Any digital filter or better any DSP operation (e.g. volume control, convolution, crossover filtering, digital filters, resampling, equalization), introduce some change relative to the original signal.

Usually multiple stages of data processing are passed to accomplish the DSP task. 

Resampling is no exception. You won't just multiply your samples by a certain factor. You'll add new interpolated samples to the music and that always comes with side effects calling for more filtering.

Talking about multiple stage processing. You also have to think about attenuating all your music before you run your resampling.  Due to the math and interpolation new samples might hit the 0dB roof, that's called clipping.  We need to avoid that clipping. And we do that by "guessing" a "save" attenuation level before we do the actual sample rate conversion.  Low level detail may suffer most at this point. 

On top of all that you might add a little extra noise to shape the mess that built up at the bottom after the DSP tasks. It's called dithering. You can choose from numerous dithering algorithms and strengths. And that choice is there for a reason - a matter of taste!?!?. I know things are getting complex now. 

Besides all that DSP data manipulation, you'll see additional load on a system caused 

by more extensive data processing, from 1. the resampler and 2. from much higher data traffic and 3. a much more complex processing chain.  All that usually creates another source of trouble.

Bottom line: there's a lot to consider. Ending up with an objectively better result is quite a challenge,  and depends on quite a number of factors, plus a lot of research, measurements and listening.

For me the driving factor, even while being well aware of all these challenges, of this exercise still is to find the better compromise for the narrow group of todays applicable DACs. Which will be mainly R2R DACs running in NOS mode.

The project / DAC angle

One of my old school DACs internally converts the samples to 352.8/384kHz. And then applies this or that filter afterwards.

The datasheet shows that this DAC won't apply its internal filters at 352.8/384kHz sample rates. That means if I feed it 352.8/384kHz data, that data will bypass the DAC's internal sampler and filter.

I'm basically trying to bypass potentially mediocre on-DAC filtering by using a top quality resampler on the outside.

And that is where the DAC specifics become crucial. The vast majority of DACs and soundcards run sample-rate converters in front of the actual DAC chip. Several devices out there lift internal rates to 352.8/384kHz. Some, for example Sabre DACs, even beyond that.

You therefore need to find out what your DAC is doing. You need to know if and how your DAC resamples your data. The result of that research defines if and how you should run this exercise.

Your DAC's internal processing sample rate should then be your target sample rate.

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 first gets upsampled to just 96kHz to feed an internal DSP. In that case this could already be your real target rate and the actual DAC chip or ASRC rate wouldn't matter anymore. You need to get to know what is going on inside your DAC.

For example, one of my  Allo HAT DACs based on the TI PCM51xx family come with four filter options. These filters get bypassed at 352.8/384kHz. That's my hook. I assume that these internal filters are not of the highest quality and hope that my externally resampled material gives better results.

With ESS Sabre-based DACs things get tricky. ESS resamples to rates beyond the capabilities of sox or any other normal resampler. However, if you do not find out enough about your DAC's internals, feeding the highest sample rate it offers is at least a reasonable first experiment.

Bottom line. My goal is to explore whether I can get a better overall result by bypassing internal filters through feeding already upsampled material.

Quality

Let's see if we can find out what resampling quality even means.

A very good starting point for a rather objective approach is the Infinite Wave SRC comparison site. There you'll find pretty much all state-of-the-art resamplers compared side by side on a technical level. Read the help section first. It tells you what to look at and nicely explains the different measurements.

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.

Very high bandwidth settings with very steep filters can cause a lot of ringing. Especially the pre-ringing part deserves attention. In listening tests such filters are often described as aggressive or sharp. On the other hand filters with no or low pre-ringing often cause phase shifts, which may translate into a loss of detail. Pre-ringing is an unnatural artifact, simply derived as a result from the associated filter math. 

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

Of course, it's not all black and white. There are acceptable compromises which allow serious fine tuning. 

I scanned the net and couldn't find any common conclusion about the best SRC option based on a listening experience. You'll find theoretical and measured differences, but no common listening verdict. Yes. It's all subjective in the end. There is no single answer on the topic. All solutions are compromises, and the weighting of those compromises depends on the setup and the listener.

Comparing the different filters settings, reminds me a bit like tube rolling, every setting comes with its own signature. 

Below illustration shows the results that can be expected from different filter settings using the opensource SRC sox.

What you see are the pre- and post-ringing results of different filter options. None of these are wanted. The nasty pre-ringing effects to the left of the 0 line are worse then post-ringing. At this point you see that the solution will be a compromise. There are losses. You can't avoid it.

You'll also see the formerly highly regarded Shibatch ssrc (Shibatch examples) results at the bottom of that comparison. I won't comment much on that. Pictures say more than a thousand words. I also did listening tests comparing ssrc and sox. I've made my choice.

Below you'll see a typical impulse response (source: src.infinitewave.ca) of a minimum phase and a linear filter. In a perfect world the result would be a single upright line. The waveform to the left and right of the main peak pulse are filter-associated artifacts which get added to the original music signal.

The min-phase filter shows the obvious more prominent post ringing behavior. The linear filter the balanced lower pre- and post ringing pattern. This illustrates just a single tone at a certain volume. Running complex music signals over such a filter will cause damage, there's no question. 

Now. We could continue with phase shifts, passband restrictions, noise, intermodulations, aliasing... you name it.

There are losses. That much is clear from both theory and measurement. Many of the visible flaws show up at very low levels though, often far below what a DAC would be able to reproduce in a straightforward steady-state sense. Therefore you'll step on the term "inaudible" all over the place. Simply ask yourself why there are 100s of different SRC  implementations and configurations if all results are supposedly basically the same. 

However, that still leaves an open question which I cannot fully answer yet: why do some listeners including me report differences between algorithms and settings even when the related spectra look astonishingly great? 

My current assumption is that simple magnitude plots do not necessarily capture the whole story. Time-domain behavior, the distribution of artifacts over complex music signals, masking, nonlinearities elsewhere in the chain and perception itself may all play a role. At this point I treat that as an open engineering question, not as a settled conclusion.

What I do consider established is that different algorithms and tools produce different measurable artifacts and different trade-offs. Whether and when these differences become audible is the more difficult question, and one that requires careful listening and ideally controlled tests.

Exercise

Let's find out how to do some high quality resampling ourselves. We run offline conversion examples. Basically converting an input file to an upsampled output file. By staying offline we eliminate potential realtime processing related flaws.

You can run this exercise and the resulting files playback on any platform of choice.

The key challenge, as mentioned earlier, is to find a top level SRC and the right balance between potential losses and gains when looking at the entire resampling process.

If you compare the different SRCs listed on the earlier mentioned "Infinite Wave" site, you'll find that sox version 14.4  in its very high quality (vhq) settings can easily compete with any other, even commercial solutions such as the highly regarded iZotope SRC. 

Even tools like ffmpeg make use of libsoxr for audio resampling. sox will be our SRC of choice.

Preparations

1. You need to get sox for your platform. It's available on all platforms. 

2. You need to select a or better some testfile(s) preferably flac in 44.1kHz/16bit. 

It is good to select some different type of well recorded music files. Orchestral music. Jazz combo with double bass. A nice female voice piece. And some percussion music with HiHats, gongs, etc. and a lot of room info inside. OK. You know the drill. All of us have their specific test files.

3. You need to make sure that your playback chain is bitperfect. You'd kill the whole exercise if that's not the case.

Sox Intro

We need to explain what SRC options to use with sox. 

-L = linear phase response (pre-ringing = post-ringing; default sox setting)

-I = intermediate phase response, a compromise between minimum and linear

-M = minimum phase response (no pre-ringing, longest post-ringing). Minimum phase also changes phase response in the upper range.

-v = very high resampling quality

-a = allow aliasing above passband (causes less post-ringing)

-b xx = passband bandwidth set to e.g. 98%

-s = alias for -b 99

-p xx = phase set to 45° - as a replacement for -I, -L, -M. E.g. -L would equal -p 50

-D = suppress automatic dithering

dither -S = adding some TPDF dither

dither -S -p 23 = adding some TPDF dither with a target precision of 23 bit 

--guard = in non realtime scenarios sox runs in two passes to avoid clipping and to apply minimum attenuation.

gain -x = attenuate the signal for -x dB e.g. "-0.3" before we do SRC. It's the first option in the chain!

-t = type of file e.g. flac

-C x = flac compression level, I stick to 0

-b = output bit-depth e.g. 24

The resampled data will be converted to 24 bit. 

Keep in mind that the original 44.1/16 CD data is already dithered. Dithering is one of the final steps the mastering engineer runs in the mastering process. Adding more and mostly different noise to the track is risky. Dithering twice, once during mastering and once during resampling, with potentially two different algorithms might lead to lower quality of the data. 

On the other hand, after 32-bit/64-bit floating-point DSP it can make sense to dither again when reducing to 24 bit - to clean up the floor a bit.

Let's have a look at certain SRC cases that I developed myself and gathered on the web.

Case 1 (my preferred setting, since Jun 2020)

My favorite. After conducting several listening tests.

• Target sample rate 8x = 352800
• flac @ compression level 0 (-C 0)
• bit depth @ 24 bit (-b 24)
• very high-quality resampling (-v)
• 95.4% passband bandwidth (-b 95.4).
• phase of 45% (-p 45), slightly below towards min phase from linear (50%).
• allow aliasing to lower the post ringing effects (-a).
• a small amount of sloped TPDF dithering to wipe the floor (dither -S).
• dither with a target precision of 23 bit (-p 23)
• we run two phase non-realtime with --guard to avoid clipping

The result comes with rather low pre- and reasonable post-ringing and with just a little phase shift.

I allowed aliasing (-a) to lower the ringing effects even further. And added a little dither. 

I chose 352800 instead of 384000 as target rate because 99.9% of the material out there is 44.1kHz.

Offline command-line example:

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

That's already it. You can now play back the converted file.

Case 2 & 3

I came across an interesting discussion in thread 1 and thread 2, which led to cases Case 2 and Case 3.

A Logitech forum inmate called "viruskiller" used sox to mimick the highly regarded apodizing filters associated with Meridian and Ayre. 

Avoiding ringing artifacts has been the ultimate goal if I am not mistaken.

As you'll see, both cases slightly differ from my own Case 1 solution above. These solutions use minimum-phase filters and lower the bandwidth substantially. 

As mentioned earlier minimum-phase filters avoid pre-ringing, move more of the ringing energy after the impulse, and change phase response in the upper range. Aliasing is then allowed to reduce the post-ringing even further.

Case 2 consists of a minimum-phase filter and limits the bandwidth to 20kHz (-3dB point, 90.7). This allows for a less steep filter. Aliasing is allowed, which causes less post-ringing and should keep fold-back artifacts above the audible range at these high target sample rates. The Ayre clone goes even further down with the passband bandwidth.

Case 2 & 3 also recommend applying a slightly sloped TPDF dither. 

Case 2 

These sox settings are supposedly similar to apodizing filters offered by Meridian.

rate -v -a -M -b 90.7 352800 dither -S

Case 3 

These sox settings are supposedly similar to apodizing filters offered by Ayre

rate -v -a -M -b 87.5 352800 dither -S

Results

In my own listening tests, M = minimum phase and I = intermediate phase filter settings seemed to cause a slightly distorted presentation.

One possible reason is the phase behavior in the upper frequency range (see the Infinite Wave charts for sox M settings).

To my ears this translated into a loss of low level detail. I perceived a kind of smearing of instruments in the back row of an orchestra and less precise separation. To me it was like a softened image.

Case 1 is currently my preferred compromise. In my setup it sounded a little softer than a pure linear maximum-bandwidth approach, a little less sharp, without that minimum-phase blur and with what I perceived as a well-articulated low end.

The driving factor behind this exercise was the hope that some downstream electronics might respond well to highest quality resampled data further upstream. 

All I can say. That has been accomplished. I do prefer the synchronous upsampled approach on my Allo DACs that come with the TI-PCM51xx family DAC chips. I didn't have a chance yet  to run tests against the modern R2R DACs. I am tempted to go for a Gustard/Audalytic DR70 DAC. 

The above filter examples are, in my view, are a good starting point. I am by no means a DSP filter guru. I tried to choose high-quality configurations that made sense to me, that were technically plausible and that were available and discussed out there on the net.

I'm sure there's more fine tuning potential. From all I read there seems to be no absolute right or wrong. Many people consider the discussions around the subject rather theoretical when it comes to sound quality, and that is exactly why I think measurements and listening should stay linked. And yes the experienced changes are not earth shattering, these a more on the subtle side.

However, I do experience clear differences with pretty much every parameter change, but I present that strictly as my own listening impression, not as a universal claim. And the verdicts range from "that's good" to "no I don't like it" - and therefore it makes sense to look into it.

In practice it is often a matter of system, taste, expectations and experience which filter signature a listener ends up preferring.

I still recommend giving all that a try if your DAC architecture makes the exercise relevant. The tools are available and the experiment is easy to reverse.

Enjoy.

PLEASE: Leave a comment and communicate your own choice of SRC settings. I promise to look into it.