Search This Blog

Loading...

Thursday, April 21, 2011

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

(Last update: Nov-08-2013)

Intro 


I've been playing around with resampling/upsampling again. I tried it in the past
and never really liked it.

Inspired by some ongoing and never ending discussions out there on the net
I wanted to figure out myself once more, if things can get better by running resampled material.

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

* Why resampling ?
* Application/Devices
* Quality factors
* Implementation on LogitechMediaServer
* Offline resampling
* Resampling proposals
* 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!!)


Why resampling?

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

Yep. I did too. I'm not a fan of digital filtering or signal processing.

Any filter respectively calculation (e.g. volume control, convolution, crossover filtering)  in the digital domain introduces losses.
And usually you need to run multiple stages of data processing once you start with it.
E.g. if you resample you also need to attenuate the signal to avoid clipping.
And that you do before you apply your filters. You'd basically run a lower quality signal over your DSP. When doing realtime processing you even need to increase the attenuation to allow for quite a safety margin.


If you do an A/B comparison on your resampling results later on on, you'll see what I'm talking about.


For me the driving factor of this exercise is to find the best solution or better compromise, if I can't avoid resampling.

Many DACs out there resample. We can't avoid it.

Our challenge: We can try to beat the HW resampler, by using a top resampler on the PC side.

The interesting thing is that you won't find many useful in-depth recommendations how to configure the resampler.

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!

What resampler should we use then??  To make a long story short.
We gonna use Sox. Sox can compete with the best commercial tools out there. That you'll see on the infinitewave site.
Sox is very flexible, fast, runs headless, it's free and it's available on all platforms.
The issue with most of todays DACs is they resample respectively oversample the data in realtime.
You can usually neither control nor avoid it. There are several reasons why manufacturers do resampling/oversampling.


1. You fight aliasing effects and noise.
   The higher the samplerates, the less intrusive can be the filtering.
2. You try to fight the jitter.
    By resampling you got the chance to do a proper reclocking
    with one precise highest quality clock and e.g. an ASRC (Asynchronous Sample Rate Converter).
3. One samplerate for all DSP and PC (Windows / Linux Pulseaudio )  processing
    The idea is to always process a common samplerate for different
    streams/sources/processes/inputs.

4. (Implementation) Cost

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



Devices 

Q: Where do we find resamplers?

A: All over the place.  And many of them are not of highest quality.

 

DACs

The vast majority of DACs and soundcards run asynchronous sample rate converters (ASRC) in front of the actual DAC chip.  Nowadays they lift
samplerates up to 192khz or 384khz. Some even higher than that.
There's a fair chance that a SW resampler like Sox can beat your HW implementation.

You need to find out what your DAC is doing. If and how it resamples your data.
Your DACs internal samplerate, should be your target samplerate within the later on discussed testcases.

NOS Dacs

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

At frequencies of 44100 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.
Those people still consider those aliasing effects the lesser of two evils. ( I belonged to that group until 2008 too)
When it comes to resolution those DACs are IMO limited.

However. Nowadays there are DACs out there, which support  hirez material > 48khz NOS implementation (e.g. Metrum DAC , Phasure NOS1, DDDAC 1794).

Those NOS DACs sound very natural...

...@ > 88.2khz !!!

Below that you'll catch of course those 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 those aliasing effects.

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

Bottom line. Running a NOS DAC with 24/96 master data is probably a great solution. But the majority of material out there is 44.1khz material.

Conclusion: It's a good idea to give resampling a try at least on NOS DACs.


DSPs


My current 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


You'll find several OSes which do resampling due to mixing reasons.
It's much easier for an OS to streamline all kind of audio streams.
You'll find it on OSX, Windows and Linux/Ubuntu/Fedora/... (Pulseaudio).

I managed to reconfigure my Ubuntu setup with pulseaudio. I currently let sox resample to 192 khz on my Ubuntu/Pulseaudio desktop system
feeding my Teac DAC.
The default rate would be 48khz at a very low resampling quality. ( I might add another Annex soon describing the procedure)


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.


Quality



Let`s go on with resampling quality.
You can do a lot wrong with resampling. You might don't even notice, because your suppliers offers you a low quality resampling. You just think this OS or devices sounds bad.


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.

I've done it.

Short summary: Beside Sox, 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 -- Nov-2013 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.
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.

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, passband restrictions ( not the entire frequency band is transfered ) , noise , intermodulations, 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/artefacs at a certain time. A complex audio sound, not a simple test signal,  causes a lot or artefacts. 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.

The current Logitechmediaserver  comes with  Sox (<=14.4.0.) - also known as swiss army knife for audio file processing. Make sure that you run an up2date Sox binary. See Annex 1&2.

Sox comes with one of the best, if not the best resampling performances (see InfinfitiWave SRC comparisons  ) for non-commercial software.
There are only a few samplers, to be found in the commercial area e.g. r8brain pro ( I also own that one) , or Izotope which are supposed to perform slightly better than Sox. If there'd be an audible difference -- It's not much.
Different filter types and configurations IMO have much more impact then different top resamplers with pretty similar parametrization.



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 could perhaps 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 substanbtially.
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:

This way you can do offline resamling of a file.

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

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










8 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