Re: Reason for sox mix restriction to two or more input files?

Hello Jeremy,


thanks for the explanation!

You wrote:
 > > [sox requires at least two input files for mixing]
 > > I understand that at least one input file is necessary
 > > (for finding the target length, sample rate etc.), but
 > > why does sox fail when mixing a single input file?
 > Probably because it's simpler to write programmes that
 > assume the user means what they say.  So if you ask sox to
 > mix several files, it is written assuming that you will
 > provide more than one.

Hmm, I am not convinced yet.  When I use my analog mixing
desk, I can easily "mix" even one input to the master.  So
mixing should even be possible for one file.

When using sox manually I am fine with changing my command
line accordingly; for an automatic use of a command line
tool boundary cases should just work if there is a
reasonable interpretation.

So
     sox -m -v 0.3 inputfile outputfile
is just equivalent to
     sox -v 0.3 inputfile outputfile

 > You say you're using a script to drive this.  That means
 > you are in control.  Your script can - surely - determine
 > that there's only one input file and adjust the sox
 > command(s) you're using accordingly.

It is a bit more complicated than that, because the script
does not know at all about sox, but is configurable for
arbitrary command-line audio processors.  Unfortunately
the configuration now has to take care of a special case for
single file mixing in sox, where other audio processors
(like e.g. ecasound) have no problem at all.

Nevertheless I found a workaround: I always add a null file
as an input partner for all mixing steps.  This is ugly, but
it works.


         Best regards,

                 Thomas