Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Apply combiner to an input_filepath_list of length 1 #24

Open
justinsalamon opened this issue Oct 5, 2016 · 2 comments
Open

Apply combiner to an input_filepath_list of length 1 #24

justinsalamon opened this issue Oct 5, 2016 · 2 comments
Labels

Comments

@justinsalamon
Copy link
Contributor

Trying to combine a single file (which basically doesn't alter it unless the combiner applies transformations too):

cbn.build([filename], outfile, 'concatenate')

Raises an error: ValueError: input_filepath_list must have at least 2 files.

But there are scenarios where this is useful, for example in my case I need to concatenate a file to itself if the file is shorter than a certain value, but otherwise leave it unchanged. The number of concatenattions N is determined at runtime, so ideally I'd like to call build() like this:

cbn.build([filename] * N, outfile, 'concatenate')

So that if N=1 it basically leaves the file unchanged. This can of course be achieved using an if statement to determine whether I need to use the combiner or not, but it's much clunkier.

@rabitt Is there a particular reason why the combiner can't be called with an input_filepath_list list of length 1?

@rabitt
Copy link
Collaborator

rabitt commented Oct 7, 2016

@justinsalamon The fundamental problem with having an input_filepath_list of length less than 2, is that SoX's "combine" mode expects at least 2 files. For example:
sox --combine mix input.wav output.wav
fails, while
sox --combine mix input.wav input.wav output.wav
works fine.

I agree it would be useful to allow having a file list of length one but unfortunately it would require significantly more than an if statement -- to do this, the Combiner object would have to "revert" itself to a Transformer.

The cleanest way I can think of to solve this is to create a third class that wraps the Transformer and Combiner object - if there is 1 input file it behaves like a Transformer and if there are more it behaves like a Combiner. If you want to go this route, I accept pull requests ;)

@justinsalamon
Copy link
Contributor Author

The cleanest way I can think of to solve this is to create a third class that wraps the Transformer and Combiner object - if there is 1 input file it behaves like a Transformer and if there are more it behaves like a Combiner.

Yes, I mean the combiner already does everything the transformer does, just with the added ability to mix/concatenate several source files before applying a transformation. A single class that can do everything (and hides the logic of choosing a transformer/combiner internally) would be nice to have. No cycles just now for PR, but will add it to the stack.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants