Thursday, April 21, 2011

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

(Last update: JUL-22-2016)

Intro 


I've been looking at the subject of resampling now and than during the last decade.
Somehow you can't avoid looking into it.
Looking into resampling can hardly be avoided if you strive for the best.


Inspired by some ongoing and never ending discussions out there
I wanted to figure out myself, how to approach the subject.

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

* What is resampling or upsampling/downsampling or oversampling?
* Why resampling ?
* Application/Devices
* Quality factors
* Implementation on LogitechMediaServer
* Offline resampling
* Resampling advise
* Sox installation/update and compilation (script)
* Conclusion


Let's get started.


Annex 1: Script to compile latest Sox for Debian/Ubuntu systems
Annex 2: Sox LMS upgrade on Debian/Ubuntu systems (a must!!)

What is resampling, oversampling, upsampling, downsampling?


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

Up- and downsampling are giving directions. There are different kind of
methods. 
1. Asynchronous upsampling
2. Synchronous upsampling 

Oversampling is the most simple upsampling method by factor 2^n. Basically all new 
samples are filled up with 0s.




Why resampling?

Resampling - Didn't somebody say never touch the base data!?!?

Hmmmh. I'm not a fan a big fan of digital filtering or signal processing.

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 done to accomplish the task.
E.g. if you resample your data, you won't just multiply your samples by a certain factor,
no you also have to attenuate the signal to avoid clipping. The attenuation you do before you apply your filters. You'd basically run a lower quality signal over your lossy DSP resampling algorithm.
When doing realtime processing you have to increase the attenuation even further to avoid clipping (=distortions).
Processing power limitations can limit the result too.
And additional load on a system because of more extensive data processing usually causes another type of distortion.

Bottom line. A lot of "Yan" that need to be balanced out by more than sufficant "Yin":



There are several 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 can be the filtering
2. You try to fight the jitter.
    By resampling (ASRC) you'll get the chance to reclock your data stream
    with that ASRC chip.
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. (Implementation) Cost

 ( Here you'll find  a nice document from Analog Devices)



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


Our challenge:

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

The interesting thing is that you won't find many useful in-depth recommendations how
to configure the resampler. There are infinite ways of tweaking your samplerate conversions.


A good starting point is the infinitewave site, which compares pretty much all state-of-the-art resamplers on a technical level.

Sounddifferences are not discussed btw!

Hmmh. 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 MPD. Even J River 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.

If the DACs USB interface won't make more than 96kHz. Then you better leave the exercise alone.
Doing SRC twice (PC and DAC) for sure will make things worse.

NOS Dacs

People who run so called Non Oversampling (NOS) DACs are trying
to avoid these HW filters and related losses.

At frequencies of 44100Hz NOS DACs do cause audible aliasing effects.
This is the reason why those aliasing filters were introduced.
Many people were and still are running famous TDA 1543 or 1541 devices @ 16/44.1.
Or there are very successful companies like Metrum providing modern style NOS DACs.
Audio-GD is also known for excellent NOS DACs.

The NOS folks consider the aliasing effects the lesser of two evils. (I belonged to that group until 2008 too running DDDACs)

I still agree under one condition.

...@ > 88.2khz !!! they start sounding great. You won't find more natural sounding DACs.

The lower the samplerate though the more nasty you'll be hit by aliasing effects.

Then. What to do with all my 44.1/16 material!?!?
Usually 99% of our collections is 44.1khz sampled.

What you need to do now is to find a highest quality resampler to get your 16/44.1 CD material upsampled to avoid these aliasing effects.

This will again end up into a compromise between resampling associated filter losses + higher processing datajitter and noise vs. aliasing effects. 

Bottom line. Running a NOS DAC with 24/96 master data might probably be a feasible solution.
But the majority of material out there is 16/44.1khz material and might need to be resampled first.

Conclusion:

It's a very good idea to give resampling a try on NOS DACs.  Though still calling your setup
NOS after doing that wouldn't be the full truth.


DSPs


My  full digital amplifier (PCM/PWM), a HifiMeDiy DDX320, internally resamples everything to 24/96. It's done because 24/96 was chosen by the chip manufacturer as the common samplerate for data processing (DSP).
My goal would be to beat that internal resampler with Sox.
Similar resampling you'll find e.g. on DSP products from MiniDSP, Behringer,  Hypex,... you name it.

You need to find out what your Digital Signal Processor is doing.
Your DSPs interal sampling rate, should be your target sampling rate within the later on discussed testcases. 

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 have a look at 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 causes a lot of bad ringing due to very sharp filters or
no pre-ringing, causes serious phaseshifts. You can't have it all.

You'll see that the  different 14.4 Sox resampling modes listed over at infintewave perform quite well. (Latest Sox is 14.4.2 -- Feb-2015 btw.)

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.

Perhaps there's none. It might be a matter of taste, since all settings add their own sound signature!!! It's like rolling tubes. Obviously each and every system can also make a difference.

But again. For me the task is to beat a HW resampler. 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 artefacts will be added to the original music signal that's being played at those other times!!




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.
If there are certain flaws at -170db, I'm not really sure, if that
matters anymore. Though we always talk of a summary of signals/artifacts at a certain time. A complex audio sound, not a simple test signal,  causes a lot or artifacts. At one point these sum up.

We need to understand that there won't be a free lunch.

There's nothing like the perfect setup.



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 our SB Touch, Transporter or e.g. Squeezelite.

Make sure that you run an up2date sox binary an any application 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 on the SB Touch (see TT3.0)  and the potential losses introduced by the filtering itself. That's quite a lot of stuff.
We need much more resources.

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 a 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 Touch 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, to avoid dithering (artificial noise) !!!
We would have to add dither, if we would go for 16bit on the output. E.g. if you downsample to something like 16/44.1.

Keep in mind that the original 16bit data is dithered already.
Dithering twice (studio and resampling), with potentially two different dithering noisetypes might lead to lower quality.



##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.
      Try also  e.g. -b 95 or -b 90

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

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


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



OR



##Case 2
   Is supposed to be the best compromise between M = minimum phase and
   L = Linear. It stands for rather small pre-ringing, reasonable post ringing,
   but still comes with the phase shift.

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


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



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



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

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


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



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



I stepped over an interesting discussion over here,or here,  which led to Case 4a/b.
Basically somebody tried to emulate the very popular resampling done by Meridian and the resampling as done by Ayre with Sox.
As you'll see Cases 4a/b differ substantially from above solutions. These folks use minimum phase filters first of all and also lower the bandwidth substantially.
Case 4 consists of a minimum phase filter ( no pre-ringing)  and the bandwidth is limited to 20khz (-db point) (90.7) which allows for less steep filters - aliasing is allowed which is causing less post-ringing, but folds back artefacts 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 * *
              # FT:{START=--skip=%t}U:{END=--until=%v}
             [flac] -dcs $START$ $END$ -- $FILE$  |  [sox] -q  -t wav - -t flac -e signed -C 0 -b 24 - rate -v -M -a -b 90.7 96000 dither -S



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


##Case 4b
##copy below########################


flc flc * *
              # FT:{START=--skip=%t}U:{END=--until=%v}
             [flac] -dcs $START$ $END$ -- $FILE$  |  [sox] -q  -t wav - -t flac -e signed -C 0 -b 24 - rate -v -M -b 87.5 96000 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 and I seemed to cause slight distorted sound to me. Maybe the phase shift in the upper frequency range?? (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.
If using Case 1 I kind of experience a slight aggressive or sharp playback.
It sound very clean but a little like an oversharpened image.

Running the resampling setup on my DDX320 - in fact - improved the sound quality. However. 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 all this is the chance that some downstream electronics might respond better to 24/96 or whatever samplerate you choose to avoid resampling done by your audio interface. That's been accomplished in my case.

Even though we're facing higher loads (due to higher samplerates and the resampling process)  -  thus potentially a little more jitter and upsampling conversion losses, we might end up with a slightly better overall performance.
I'd say I achieved that.


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 intensively 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 potentially a matter of taste 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