Thursday, April 21, 2011

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

(Last update: Mar-28-2018)

Intro 


I've been looking at the subject of audio data resampling now and than.
Somehow you can't avoid looking into it - for several reasons.
In my case some of my HW setups suggest to use resampled data 
to achieve a potentially better performance. 

While scanning the net I stepped over a lot of very fragmented and also incomplete 
information. 
Quite some stuff out there has a marketing flavor attached to it. 
And obviously you'll find numerous different opinions about the best way doing things.

With this post I'm trying to cover certain aspects, such as

* What is resampling or upsampling/downsampling or oversampling?
* Why resampling?

* Quality factors and quality targets
* What tools and applications 
* Conclusion

* Implementation on LogitechMediaServer
* Offline resampling
* Sox installation/update and compilation (script)


Let's get started.


Annex 1: Script to compile latest Sox for Debian/Ubuntu systems
Annex 2: Sox LMS upgrade on Debian/Ubuntu systems


What is resampling, oversampling, upsampling, downsampling?


Basically "resampling" is the overall expression for changing a given samplerate.

Up- and downsampling are giving resampling directions.

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

1. Asynchronous resampling (44.1kHz  to 48xN)
2. Synchronous resampling   (44.1kHz  to 44.1xN)

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

Basically "N-1" samples will be added after each sample. At a factor of N=2 we'll add one extra sample after each sample. 
E.g. 4 samples at values 1-3-5-2 will become 1-0-3-0-5-0-2-0

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 content. 
As you can see in above example there are issues with this method.  
Starting  with 1-0-3-0-5-0-2-0  we'd end up with 1-2-3-4-5-4 or 3?-2-1  
This approach would be called linear interpolation. 
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 cause losses.
How much of impact we'll see or better hear is a different question.



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 of 22.05 kHz.

    The required aliasing filter has to be very steep. It requires 100db attenuation from
    20 to 22,1kHz - in theory.
    The higher the samplerates, the less intrusive the filtering can be

2. You try to fight the jitter.

    By resampling (ASRC) you'll get the chance to reclock your data stream
    with that ASRC chip. Then you'll end up with a single samplerate, a samplerate
    that fits best to your HW implementation.

3. One samplerate for all DSP and PC (Windows / Linux Pulseaudio )

    To be able to handle different samplerates from different
    streams/sources/processes/inputs you need to resample all streams.

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

5. (Implementation) Cost


There's no such thing as a free lunch.



Any digital filter respectively related algorithms and calculations (e.g. volume control, convolution, crossover filtering, digital filters, resampling, equalization) in the digital domain introduce losses to the base signal.
Usually multiple stages of data processing have to be passed to accomplish the 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 usuall ycome with nasty side effects calling for more filters. 
And then you also have to attenuate the signal before upsampling it to avoid clipping
Low level detail will suffer most at this point. 

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.


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


My challenge:

Try to beat the on-dac resamplers/oversamplers or filters, by using a top quality resampler on the PC side.

The challenge is you won't find many IMO useful advise of how to configure the resampler. There are infinite ways of configuring your converters. Pretty much all of them end up with
a 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 or not.

A good starting point for a rather objectve approach is the infinitewave site
Over there you'l find pretty much all state-of-the-art resamplers compared side-by-side 
on a technical level by looking at the results.

Sounddifferences 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 sox.

sox IMO can compete with the best commercial tools out there.
That you'll figure once you've been on the infinitewave site.

I compared sox with e.g. Izotope, Adobe Audition and Voxengo r8brain -- highly regarded commerical tools soundwise.
For me there was no reason to switch to either of them.

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. the Logitechmediaserver or can be used with squeezelite or MPD. 
Even JRiver Media Center under Windows is using sox.



DACs


The vast majority of DACs and soundcards run samplerate converters in front of the actual
DAC chip.
Nowadays they lift samplerates up to 352.8/384khz. Some even higher than that.

You'd actually need to find out what your DAC is doing before proceeding. You need to find out if and how it resamples your data.

Your DACs internal samplerate, should be your target samplerate within the discussed testcases later on.

There are traps of course.

Some devices do internal DSP processing prior to the DA process.
It might happen that the data gets upsampled to just 96 kHz first. Than this will be your target.

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

Bottom line. 
352.8/384kHz are gonna be my target samplerates.
My goal would be to experience a better soundquality through bypassing the internal filters by feeding upsampled material.

Obviously you need to find out what your DAC or Digital Signal Processor is doing to be able to set your own goals.



OS Mixer


All OSes apply resampling due to mixing reasons.
Basically an OS can't handle different samplerates from different apps. It must streamline
all kind of audio streams.
You'll find it on OSX, Windows.,Android and Linux/Ubuntu/Fedora/... (Pulseaudio).

You can reconfigure all OSes stop doing it though.
But that leaves you with the single audio source at a time.



Mobile devices


Tablets and phones of any brand usually also resample internally. Beside that they also limit the volume. You'll have a hard time to get highest quality audio from any mobile device.

Advise: Under Android have a look at "USB Audio Player Pro". This app passes the Android mixer by.



Quality


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

First I already mentioned  the  infintewave  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.

Short summary: Beside aox, Adobe Audition 5.5 and iZotope64 can be considered top of the range resamplers.

You need to realize though that not just one parameter makes a good resampler.
A perfect graph in one area might cause artefacts 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 phaseshifts, which usually translates into loss of details. 

Yep. That's an issue. You can't have it all.

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

You'll see that the  different 14.4 Sox resampling modes listed over at infintewave perform quite well.

Our task is now is to find the "best" resampling options with todays Sox version.


I scanned the net and couldn't find any kind of common conclusion about what would be the best 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, since all settings add their own sound signature!!!
It's 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 "highly regarded" ssrc resampler results at the bottom in above comparison. ssrc is used by dbPoweramp btw.

I won't comment about it: 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 resampled impulse (source: inifintiwave) with a linear filter. The result should be a straight single upright line in a perfect world.
The waveform (ringing) to the left (pre) and right (post) 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.
There are certain flaws popping up at extremely low levels of -170db !?!?
Levels, much lower then any DAC out there would be able to reproduce.

However. We always talk 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. Obviously there are
audible differences between different algorithms.

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.

Make sure that you run an up2date sox binary on your server! See Annex 1&2.

The key challenge is IMO 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.

On the negative side, we also add jitter and noise to the realtime data stream caused by additional load due to the realtime src and the processing of higher sample rates, the local flac decoding  and the potential losses introduced by the filtering itself. That's quite a lot of stuff.
We need much more resources to accomplish all this.

How does the equation have to look like? 

Basically all resampling related flaws combined, need to have less impact than just loading your DAC with your original data.

That's the challenge. Let see how far we'll get.

The filtering itself gives you numerous options to improve or to mess with the base material.



Below you'll find some Windows and Linux instructions and some pre-selected Sox parametrizations you could try.

What you can also try is to do offline resampling to avoid the realtime decoding/load issues.

Let's prepare your server first.


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


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



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 24/96 and sent down to the DAC as flac!!

If you like you can change the target sample rate from "96000" to "88200" or any other sample rate up 2 192khz, by swapping the corresponding numbers within below examples. You might experience a slight difference.

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 shifted to 24bit. This helps to avoid dithering (artificial noise) !!!

Keep in mind though that the original 16bit CD data is dithered already. 
Dithering is the last 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 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 float.Getting this 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.


Case 1

      Linear & Very high quality & 98% bandwidth
      It comes with high pre and postringing and without any phaseshift.
      I allowed aliasing (-a) to lower the ringing.
      Lowering the bandwidth might improve the ringing situation even further.
      You can try also  e.g. -b 95 or -b 90

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

flc flc * *
             # F
             [sox] -q -t flac $FILE$  -t flac -e signed -C 0 -b 24 - rate -v -b 98 -L -a 352800  

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



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 -e signed  -C 0 -b 24 - rate -v -I -b 98 -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 -e signed -C 0 -b 24 - gain -1 rate -v -L -b 98 -a  352800  



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



I stepped over an interesting discussion over here or here,  which led to cases 4a/b.
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 4 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, but  potentially folds back artifacts in the upper audible range.
Benchmark does have a slightly different opinion around the subject of Apodizing filters.

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


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


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



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


Case 4b

##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########################


Offline resampling:

Below example shows how you can accomplish offline resampling of a file.
I highly recommend this method for comparing tracks properly.
Realtime processing respectively realtime highest quality samplerate conversion  is causing much higher load on a computer (That's why Windows/Linux/Osx are using low quality resamplers).
This higher load usually leads to higher data jitter and noise.
In my experience this can have an imapct on the perceived soundquality.  

##Case 5 ( based on Case 4a)
##command line########################

sox  -t flac test1.flac  -t flac -e signed  -C 0 -b 24 test1-vMab90.7-2496.flac rate -v -M -a -b 90.7 96000 dither -S

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


You might play around with "-a" to allow aliasing to see what it does.
Turning -a on reduces the post-ringing effects. But it also generates
other artefacts in the frequency domain. You need to find out yourself
what sounds best to you. You can also play around with bandwidth (-b )
in case 1-3. You might try to lower it to 90 or 95.


Results



Using M - minimum phase  and I - Intermediate phase 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. In my case I experience in the far
back row of an orchestra disappearing (smearing) of instruments.
The separation suffers. It's like a softened picture.
If using case 1 settings  I kind of experience a slight aggressive or sharp playback.
It sounds very clean but a little like an oversharpened image.

I'm still in the process of figuring out the best compromise.
I can't really say Case 1 is it or Case 4a is it. It's work in progress. 
Currently I got 4a running.


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 DAC (Allo Piano2.1)


Above filter examples are IMO a good starting point. I'm 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 differences with pretty much every parameter change.
It's usually a matter of system, taste, expectations, experience what filter signature sounds best to you.

With a bit of feedback from you guys, I'm sure things can be optimized even further.


Between above examples you should experience slight differences.One sounds a bit more mellow the other a bit more edgy or sharper.

I btw. also tried and compared r8brain Pro, Adobe and iZotope64 doing offline conversions. I  didn't see any reason for not using  Sox.


I highly recommend to give all that a try. You can't do anything wrong. Though you'll experience quite some differences. It's a nice playground.

Again. Let me know about your prefered solution.

Enjoy.

Cheers



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


Annex 1:

It's always a good idea to have the latest Sox version available.
To have the latest Sox available I recommend  to compile it yourself.



###Version 1 - Quick and dirty

Open a terminal and copy-paste below lines (between hashed lines), all at once, into that terminal.

###################################################
sudo su
apt-get -y install git build-essential xmlto automake autoconf libtool \
gettext checkinstall libmp3lame-dev libid3tag0-dev libsndfile1-dev libflac-dev \
libflac++-dev libmad0-dev libsysfs-dev libpng12-dev libasound2-dev \
libpulse-dev libspeex-dev libsamplerate0-dev libwavpack-dev libogg-dev libao-dev
apt-get -y remove sox
cd /tmp
git clone git://sox.git.sourceforge.net/gitroot/sox/sox
cd sox
autoreconf -i
make clean
./configure --prefix=/usr --without-oss --without-sunaudio
make -s
make install
clear
sox --version
##################################################

Done.




####



I prepared a script that does it for you. It'll work on Ubuntu/Debian
systems. It'll also update your Logitechmediaserver binary.


#copy below########################################
#!/bin/bash
#
# This script fetches,compiles and installs Sox from git on Ubuntu/Debian systems
# The Sox Git version is the most up2date version of Sox.
#
# Tested up to Ubuntu 13.10.
# The new binary will be installed on LMS, if LMS env is available.
#
# Copyright Klaus Schulz
#
# Rev: 1.0  -- NOV-8-2013
#
#
#################################################

SOXSRCDIR=/usr/src
LMSDIR=/usr/share/squeezeboxserver/Bin/i386-linux

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

header () {
echo
echo "-------------------------------------------------------------"
echo "${1}"
echo "-------------------------------------------------------------"
echo
}


die() {
echo "Step $1 failed. Please resolve issues"
exit 1
}


checkroot() {
[[ $EUID -ne 0 ]] && {
   echo "You must be run to run this script" 1>&2
   exit 1
}
}


packs() {
header "Installing supporting packages and libraries"
apt-get -y install git build-essential xmlto automake autoconf libtool gettext checkinstall
apt-get -y install libmp3lame-dev libid3tag0-dev libsndfile1-dev libflac-dev libflac++-dev\
            libmad0-dev libsysfs-dev libpng12-dev libasound2-dev libpulse-dev libspeex-dev libsamplerate0-dev\
            libwavpack-dev libogg-dev libao-dev || die PackageInstall
apt-get -y remove sox || die SoxRemoval
}


clone(){
header "Cloning sox sources from git"
cd $SOXSRCDIR
test -d sox && rm -rf sox
git clone git://sox.git.sourceforge.net/gitroot/sox/sox || die GitClone
}


configure() {
header "Configuring sources"
cd $SOXSRCDIR
test -d sox || die "Configuration failed: Sox sourcedir not found"
cd sox
autoreconf -i
make clean
./configure --prefix=/usr --without-oss --without-sunaudio
}


compile() {
header "Compiling sources"
cd $SOXSRCDIR
cd sox
make  ||  die "Make failed"
}


install() {
header "Installing sources"
cd $SOXSRCDIR
cd sox
make install ||  die "Make Install failed"
}


lmsinstall() {
header "Installing new sox binary in LMS environment, if LMS is installed"
test -d $LMSDIR && {
 mv $LMSDIR/sox $LMSDIR/sox.old
 cp $(which sox) $LMSDIR
 chmod 777 $LMSDIR/sox
 echo "Restart LMS server to activate changes."
} ||  echo "LMS not installed!"
}


checkbin() {
header "Binary version:"
sox --version && {
header "Installation successfully finished!!! Enjoy."
} || {
header "Problem with binary. Please check!!!"
}

}
#####main#########################################

checkroot
packs
clone
configure
compile
install
lmsinstall
checkbin

exit 0

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



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

Annex 2

This exercise is a MUST, if you run Ubuntu or a Debian system and LMS.

I'd like to show you how to update your LMS installation with latest Sox as supplied by Ubuntu/Debian.



Open a terminal.

Type:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install sox
sudo cp $(which sox)  /usr/share/squeezeboxserver/Bin/i386-linux



That's it.

If you want to have an even more up2date Sox version you need to run the Annex 1 exercise.





##END OF POST#######################################









10 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