From: "Dr. Thomas Tensi" <t.tensi@gmx.de>
To: sox-users <sox-users@lists.sourceforge.net>
Subject: Re: Reason for sox mix restriction to two or more input files?
Date: Sat, 10 Aug 2019 14:06:33 +0200 [thread overview]
Message-ID: <878d1509-1207-2ad4-e084-7a6f9a91b5fd@gmx.de> (raw)
In-Reply-To: <f8fcdf1156c2691934c68a3b8287d3b5@wingsandbeaks.org.uk>
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users
next prev parent reply other threads:[~2019-08-10 12:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-09 19:42 Reason for sox mix restriction to two or more input files? Dr. Thomas Tensi
2019-08-10 9:52 ` Jeremy Nicoll - ml sox users
2019-08-10 12:06 ` Dr. Thomas Tensi [this message]
2019-08-10 17:28 ` Måns Rullgård
-- strict thread matches above, loose matches on Subject: below --
2019-08-11 19:22 Dr. Thomas Tensi
2019-08-12 9:29 ` Måns Rullgård
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.sourceforge.net/lists/listinfo/sox-users
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878d1509-1207-2ad4-e084-7a6f9a91b5fd@gmx.de \
--to=sox-users@lists.sourceforge.net \
--cc=thomas@tensi.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/sox.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).