• [x] fix set_input_format in Combiner
• [x] implement stretch
• [x] implement speed
• [x] implement sinc
• [x] implement phaser
• [x] implement mcompand
• [x] implement echos
• [x] implement echo
• [x] implement bend

This PR tries to address #6. I basically followed the code by @carlthome in pysndfx here: https://github.com/carlthome/python-audio-effects/blob/master/pysndfx/dsp.py#L472. I followed the discussion in the issue and implemented a new function that belongs to Transformer called build_array, which takes in a numpy array. The main issue is keeping track of all of the information that would normally be in the header of the audio file. Instead, these have to be passed as arguments to build_array, both for the input and output.

I modified all of the tests. Each piece of the Transformer is tested by taking an input file and passing it through sox to write to an output file. So in the tests, what I do is load both the input file and the output file as numpy arrays, pass the input array into tfm.build_array and collect the output array (which is the second argument in the tuple, matching the API of tfm.build). Then, I do an np.allclose between the loaded output array from the output file and the output array. Every test was modified in this way, except for one, which I can't get working in the time I tried to put this together today. That test is test_bitdepth_valid, here: https://github.com/pseeth/pysox/blob/master/tests/test_transform.py#L1347.

This change to the tests is encapsulated in a single function tfm_assert_array_to_file_output which you'll see calls to sprinkled throughout the test.

To do all this, I modified the sox function in a backwards compatible way. I probably need to up coverage a bit still but this is hopefully okay to PR now for feedback.

Let me know if this is a good start and how to get this merged, if possible! It would go a long way to making pysox super efficient for Scaper, thus why I'm here. :)

Thanks!

Would it be possible to input audio as ndarray:s into pysox directly as well as files from disk? Why I'm asking is because I'm using librosa for onset detection, and thus already have the audio loaded, but would still like to apply some audio effects and stuff afterwards.

Like maybe the constructors could do a type check, and build() could return the destination audio or something?

y = librosa.load(path)[0]
tfm = sox.Transformer(y)
# Do stuff...
y = tfm.build()

I realize this adds extra complexity to pysox (like having librosa as a dependency or similar) which is intended to be a clean wrapper around SoX, so I get if it's deemed out of scope. Just asking!

file_info.bitrate used to call soxi with flag -b rather than -B Yes, -b is not the bit rate but the bit depth This PR changes -b into -B in file_info.bitrate It also defines a new function, file_info.bitdepth, which does what bitrate did earlier I updated the tests accordingly Closes #68, Closes #78, closes #84

Since python 3.4 there has been a new object-oriented interface to handling paths. This PR adds support for pathlib.Path for functions which take a path as input. I make heavy use of pathlib.Path in my code these days, and while I can do the cast to string myself, I find that more and more libraries are supporting pathlib, and so I offer this PR.

In practice, since pathlib.Path is implicitly cast to string, there are only a couple of minor places where this is important - any function which performs a string-based operation on a variable which could be a path.

In order to make sure the tests pass, because this a python3-only feature, I also removed 2.7 from your .travis.yml file. Since python2 is EOL, and your readme doesn't include a python2 badge in the top, it seemed like this should be okay. If not, let me know and I'll see if I can come up with some test flags for python2 which would skip these tests or something.

Sox doesn't support using the same file as both input and output - doing this will result in an empty, invalid audio file. While this is sox behavior and not pysox, it would be nice if pysox took care of this behind the scenes. Right now the user needs to worry about this logic themselves, e.g. like this:

import tempfile
import shutil
from scaper.util import _close_temp_files

audio_infile = '/Users/justin/Downloads/trimtest.wav'
audio_outfile = '/Users/justin/Downloads/trimtest.wav'
start_time = 2
end_time = 3

tfm = sox.Transformer()
tfm.trim(start_time, end_time)
if audio_outfile != audio_infile:
    tfm.build(audio_infile, audio_outfile)
else:
    # must use temp file in order to save to same file
    tmpfiles = []
    with _close_temp_files(tmpfiles):
        # Create tmp file
        tmpfiles.append(
            tempfile.NamedTemporaryFile(
                suffix='.wav', delete=True))
        # Save trimmed result to temp file
        tfm.build(audio_infile, tmpfiles[-1].name)
        # Copy result back to original file
        shutil.copyfile(tmpfiles[-1].name, audio_outfile)

Pysox does issue a warning when a file is about to be overwritten, which is even more confusing under this scenario since the user (who might be unfamiliar with the quirks of sox) has no reason to think that the overwritten file will be invalid.

Calling grep breaks pysox (and subsequently) scaper on windows. This PR addresses this be removing the use of grep altogether and parsing the sox help string directly in python.

Addresses issue #66 in pysox, issue justinsalamon/scaper#25 in scaper

Implement #37. Also, I found we need a method to clear effects in Transformer so we do not need to instancing a new tfs.

Also noiseprof effect is very special as the output prof file name is not after input filename but after noiseprof. In shell the whole command should be something like sox noise.mp3 -n noiseprof noise.prof where -n is a null file. I really do not understand sox works that way and the -n seems to be useless. As -n is in the position of output filename so the real output file is sentenced in noiseprof() function.

Example:

>>> import sox
>>> tfs = sox.Transformer()
>>> tfs.noiseprof()
<sox.transform.Transformer object at 0x7f140c221250>
>>> tfs.build('/home/lancaster/pb-4.wav', '-n')
WARNING:root:This install of SoX cannot process . files.
True
>>> tfs.effects
['noiseprof', 'noise.prof']
>>> tfs.clear_effects()
>>> tfs.effects
[]
>>> tfs.noisered(amount=0.3)
WARNING:root:This install of SoX cannot process .prof files.
<sox.transform.Transformer object at 0x7f140c221250>
>>> tfs.build('/home/lancaster/pb-4.wav', '/home/lancaster/clear.wav')
WARNING:root:output_file: /home/lancaster/clear.wav already exists and will be overwritten on build
True

It works well during my test, I am new to PR and not familiar with coveralls so I just test it in console... I didn't find why these WARNING exists. They may need to be fixed later...

Implements option B from issue #106

• build_file takes array or file inputs and generates file outputs, returning a boolean
• build_array takes array or file inputs and returns np.ndarray outputs

build_file is an alias for build, and I moved the documentation to point people towards using build_file, while keeping build fully functional.

I also did a little cleanup of how set_input_format and set_output_format work - rather than storing the list of format arguments to be passed to sox, it stores a dictionary which is parsed when running build/build_array, which cleans up the build functions substantially.

So far, in 1.4.0a0, we've overloaded the build API to support 4 cases:

1. file in, file out status = tfm.build(input_filepath=..., output_filepath=...)
2. file in, array out status, out, err = tfm.build(input_filepath=...)
3. array in, file out status = tfm.build(input_array=..., sample_rate_in=..., output_filepath=...)
4. array in, array out status, out, err = tfm.build(input_array=..., sample_rate_in=...)

The pros:

• it's backwards compatible
• it's all in one function

The cons:

• the returns change in a confusing way as a function of the combination of inputs
• only certain combinations of inputs are valid

Do we want to keep it this way? Some other alternatives: A. write 4 separate functions. We keep build as file in-file out for backwards compatiblity and define 3 new functions for the other cases B. write 2 separate functions, one for file output and one for array output, keeping the input argument logic (e.g. build and build_array, similar to @pseeth 's original PR) in order to support either file or array input for both functions C. keep build as it is currently, and write 4 additional wrapper functions for each of the 4 cases that internally call build ... other ideas?

Would love to hear people's thoughts. cc @pseeth @nicolamontecchio @psobot @carlthome @hadware @lostanlen

Closes #51. This is kind of hacky, but should work and should allow callers to configure pysox logging via logging.getLogger('sox') on the global logging object.