the audio streaming series

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 




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

23 comments:

  1. Klaus, hi, thanks for these experiments. I wondered if there was a tool to do this in Windows, rather than through the SB Server? I tried to convert a file in Foobar using the Sox plugin and I can resample to 96000 but cannot change the 16-bit to 24-bit.

    Thanks

    ReplyDelete
  2. I figured out how to do it in Foobar. Was previously transcoding to wav. Changed it to FLAC and selected the 24-bit option. Not quite certain if I can hear any differences in my setup, though I should think this experiment will be highly DAC dependent.

    ReplyDelete
  3. Hi again - last from me! I got Sox installed and read the documentation. I think in your Case 1 and Case 2, the -v rate switches are redundant as they are overwritten by your -s switch which changes the bandwidth to 99%.

    Still can't hear any differences, though!

    ReplyDelete
  4. Thanks Klaus, great mod for my Touch. Everything sounds better with this mod. Only thing I really would like to see in a future Touchtoolbox mod is the possiblity to switch off the optical out when the touch is powered off, this way my dac can also go to sleep. This was a existing feature on the SB2 but not on this Touch. I already posted this issue on the Logitech website, together with several other DAC users, but untill now Logitech apparently doesn't care about this issue. Is this something that is feasible to include in a TT release?
    Thanks for thr great job so far> Looking forward to TT 4.0 :-)

    Erwin

    ReplyDelete
  5. Hi and thanks for all your work. I am wondering if this up-sampling strategy could be applied only to internet radio streams to avoid the chipmunk effect of the lower sampling rates. I miss some of my local stations.

    ReplyDelete
  6. Hello Klaus,

    you have done a great job!

    I hope you noticed some screenshots are missing?

    Best regards,

    JBdV at diyaudio

    ReplyDelete
  7. Dear Klaus,
    I have installed the toolbox for a couple of days ; it works very well.
    Many thanks and congratulations for this good job.
    I have just had a look on your advices about HW modifications and your comments about cabling (Meicord).
    We have referred to the cable between your cisco and your touch.
    What about the balance of your ethernet cabling, I would mean between your cisco and your PC (NAS or Macbook in my case) ?
    Would it be relevant to get an "audio" ethernet cable there as well ?
    Thx
    Cyrille (from Paris)
    PS: Donate in progress...

    ReplyDelete
  8. all those settings make clip the output audio... I took it your examples to an extreme with my custom-convert.conf for my boom:

    #

    flc flc * *
    # FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
    [flac] -dcs $START$ $END$ -- $FILE$ | [sox] -v0.9 -D -V4 -t wav - -t flac -e signed -C 0 -b 24 - rate -v -s -L -a 48000 highpass -2 10 highpass -2 20 lowpass -2 19671 dither -a -s -p24

    flc flc transcode *
    # FT:{START=--skip=%t}U:{END=--until=%v}D:{RESAMPLE=-r %d}
    [flac] -dcs $START$ $END$ -- $FILE$ | [sox] -v0.9 -D -V4 -t wav - -t flac -e signed -C 0 -b 24 - rate -v -s -L -a 48000 highpass -2 10 highpass -2 20 lowpass -2 19671 dither -a -s -p24


    and depending on the flac stream you usually get clipped audio like this:

    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox INFO sox: effects chain: input 44100Hz 2 channels (multi) 32 bits 00:04:48.99
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox INFO sox: effects chain: rate 48000Hz 2 channels 32 bits 00:04:48.99
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox INFO sox: effects chain: highpass 48000Hz 2 channels 32 bits 00:04:48.99
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox INFO sox: effects chain: highpass 48000Hz 2 channels 32 bits 00:04:48.99
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox INFO sox: effects chain: lowpass 48000Hz 2 channels 32 bits 00:04:48.99
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox INFO sox: effects chain: dither 48000Hz 2 channels 24 bits 00:04:48.99
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox INFO sox: effects chain: output 48000Hz 2 channels (multi) 24 bits 00:04:48.99
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox FAIL sox: `-' error writing output file: Broken pipe
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox WARN rate: rate clipped 4 samples; decrease volume?
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox WARN highpass: highpass clipped 32 samples; decrease volume?
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox WARN highpass: highpass clipped 999 samples; decrease volume?
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox WARN lowpass: lowpass clipped 744 samples; decrease volume?
    /opt/logitechmediaserver-7.7.1-33735/Bin/i386-linux/sox WARN dither: dither clipped 363 samples; decrease volume?

    ReplyDelete
  9. Hi soundcheck,

    thanks for all the useful info you have provided on the Squeeze world over these years.

    You can oversample a flac file with sox without passing through wav. This decreases CPU load. Your example 1 above works also as

    flc flc * *
    # FT:{START=--skip=%t}U:{END=--until=%v}
    [sox] -D -q -t flac $FILE$ - -t flac -e signed -C 0 -b 24 - rate -v -b 98 -L -a 96000

    also if you want the client to do no decoding without having the problems with raw you can stream as uncompressed flac (namely flac tagged wav) with the following command

    flc flc * *
    # FT:{START=--skip=%t}U:{END=--until=%v}
    [sox] -D -q -t flac $FILE$ - -t flac -e signed -C 0 -b 24 - rate -v -b 98 -L -a 96000 | [flac] --disable-constant-subframes --disable-fixed-subframes --max-lpc-order=0 -

    I figured this out after spending one day between your page here and the rest of the internet!

    Hope this helps.

    Giulio from audioasylum and diyaudio

    ReplyDelete
  10. Dear Klaus,

    This beats SoX:

    - ReSampler (https://github.com/jniemann66/ReSampler)

    Cheers!

    ReplyDelete
    Replies
    1. Dear Klaus,

      Here's the latest and greatest SoX with full DSD support:

      - https://audiofaidate.org/sw/sox-dsd/

      or

      - https://audiodigitale.eu/repo/sox/

      Cheers!

      Delete
  11. Thank you for this blog. And also the update.
    I use both SoX for online upsampling and ReSampler for offline upsampling.
    Yes I agree that higher passbands in SoX has "tigher" sound, but seems a little bit oversharpened and very dynamic.
    I also experimented with SoX paraaeters.
    I stopped use of aliasing about 2 years ago.
    Nice sounding passbands for SoX are 95.4, 94.5 (sounds smooth on uneven conversions), 92.4, 92, 90.5, 90.
    Currently I for SoX use less steep passbands, like 90.5.

    For ReSampler I currently use 92.8 passband. Sounds great but does offline upsampling only. It is worth noting that the parameters for passband are not fully comparable since ReSampler starts to roll off a little bit before the specified passband.

    ReplyDelete
  12. As for the clipping, ReSampler guards for clipping automatically (if not switched off) and command line SoX can guard for clipping with -G switch.

    For online upsampling a slight preamp lowering volume of 1-3 dB can be applied of desired, especially when we playback at 100 percent digital volume.

    ReplyDelete
  13. Hello,

    Thank you for sharing.
    I have a problem, though...

    I'm using Dietpi and Squeezelite-R2
    When I try upsampling I get sound but It is not Upsampled.

    I have done SOX V14.4.2 upgrade and copy to
    cp $(which sox) /usr/share/squeezeboxserver/Bin/armhf-linux

    I have edited File type in LMS to have flac flac sox and wav flac flac/sox, everything else is desactivated

    Note that I mainly have Wav files 16/44.1

    Here is my CustomConvert
    flc flc * *
    # F
    [sox] -q -t flac $FILE$ -t flac -e signed -C 0 -b 16 -gain -1 - rate -v -a -M -b 87.5 176400

    flc pcm * *
    # F
    [sox] -D -q -t flac $FILE$ -t wavpcm -e signed -b 16 -gain -1 - rate -v -a -M -b 88.0 176400

    my Squeezelite is: squeezelite -a 24:4:16:1 -c pcm,flac,mp3 -z

    I have 3 clock output
    PLL A frequency: 677.376mhz
    Clock 0: 5.6448mhz
    Clock 1: 2.8224mhz
    Clock 2: 1411.2khz

    according to custom convert it should work with Clock 0, but, it work with Clock 2 meaning no oversampling although htop shows sox running

    Thank you for your help.
    PS I also tried C-3PO plugin with Squeezelite-R2, I never had any sound...

    ReplyDelete
    Replies
    1. You've got your commands wrong. It should read:

      [sox] -q -t flac $FILE$ -t flac -e signed -C 0 -b 16 - gain -1 rate -v -a -M -b 87.5 176400

      I'd also change "-b 16" to "-b 24", because squeezelite will change the stream to 32bit anyhow. This way you avoid clipping and you could even leave that "gain -1" alone altogether. And on top no additional dither would be applied.

      Delete
  14. Thanks for news. Yes 95.4 is great passband for SoX. It is good that you are still tuning the resampling!

    ReplyDelete
  15. Hi Soundcheck,
    Now that by your settings my music sounds impressingly better I of course also wanted to trie the upsampling. I made the config-file via SSH on my Synology. After restarting LMS on the filetypes page flc fc was sox. Only other option there was "disable". LMS refused tot play flacfiles...I checked the config-file and everything was neatly in it, restarted again, didn't help.
    Any idea what went wrong?

    ReplyDelete
    Replies
    1. Please copy your custom-convert.conf
      What sox version is your Synology running?

      Delete
  16. Hi Klaus,
    Fed up with fighting with my NAS, I installed the server on a nice new rpi4 with all your settings. Sounds very beautifull... But: how can I see the usampling has been done? Although there are new streaming-settings for Flac which I choose, the streamed files show in LMS still the same bitrate etc.

    ReplyDelete
    Replies
    1. ssh Login to your client.

      Let's assume you just have one soundcard enabled.

      Type while playing:

      cat /proc/asound/card0/stream0

      It'll look similar to below

      *****************************



      iFi (by AMR) iFi (by AMR) HD USB Audio (DOP2 at usb-0000:01:00.0-1.3, high spee : USB Audio

      Playback:
      Status: Running
      Interface = 1
      Altset = 1
      Packet Size = 72
      Momentary freq = 44104 Hz (0x5.8358)
      Feedback Format = 16.16

      ***********************

      That's the last point in the chain to look for the samplerate that gets to the DAC.

      You could also enable the logging function of squeezelite to look it up in the logs.






      Delete
  17. Hi Klaus,
    I couldn't find /proc/asound/card0/stream0 but looked around in the folder-structure and found /proc/asound/card0/pcm0p/sub0/. In it was hw_params with the line: rate: 352800 (352800/1). After going back to no upsampling it said: rate: 44100 (44100/1)
    So I suppose it's working allright! Together with all your other settings (and especially your own squeezelite-version) the sound is now very beautiful. As if I have a new audioset. Many thanks for your efforts and time, I owe you a beer - a big one.

    ReplyDelete
  18. Hi Klaus,
    What could be your command:
    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

    for ape and mp3?

    Another thing: since I resample my Flac-files, quite often -but not always-, a song ends a couple of seconds before it is finished. Since the amount of data after resampling is huge, I suppose it can be fixed with increasing a buffer size. But what buffer and what should it be? If thats the case anyhow...
    As always thank you for your care.

    ReplyDelete
    Replies
    1. Interesting. I ran into a similar issue recently when trying room correction. I changed the output format to "-t flac -C 0" as workaround.
      That solved it for now.

      mp3 and ape I didn't consider.

      Delete