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
_______________________________________________
Sox-users mailing list
Sox-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/sox-users
