Use directly in memory, instead of via files, possible? about pysox

[smolendawid]

I must admit that it would be very useful. I need this transformations on the fly, holding everything in RAM, so saving to a disk and then again loading to python is inefficient.

[carlthome]

Sound great! I'd love to get rid of my package entirely and have pysox be the only SoX Python wrapper if possible.

Consolidate:

[justinsalamon]

Not that this solves the issue of taking an i/o hit, but in the meanwhile a safe way to concatenate operations is to use tempfile:

with tempfile.NamedTemporaryFile(suffix='.wav') as tmp:

    tfm = sox.Transformer()
    tfm.trim(0, 5)
    tfm.build(infile, tmp.name)

    cbn = sox.Combiner()
    cbn.build([tmp.name, tmp.name], outfile, 'concatenate')

The downside is that since sox requires a filename, you need to use a NamedTemporaryFile and that means the system will think the file already exists when you call build(), which means you'll always get an overwrite warning (which perhaps could be disabled by the addition of an optional flag @rabitt ?)

Right now the workaround is by changing the logger level:

logger = logging.getLogger()
logger.setLevel('CRITICAL')

with tempfile.NamedTemporaryFile(suffix='.wav') as tmp:

    tfm = sox.Transformer()
    tfm.trim(0, 5)
    tfm.build(infile, tmp.name)

    cbn = sox.Combiner()
    cbn.build([tmp.name, tmp.name], outfile, 'concatenate')

logger.setLevel('WARNING')

Or if you just want to suppress all logging you can do logger.disabled = True

[rabitt]

This is done in #102 , thanks @pseeth !
I've opened #106 to discuss how the API should look moving forward before pushing to a full release.

[hadware]

I'll try porting @carlthome 's work to pysox, It'd be nice if you guys could give me some pointers on how you'd wish it to be implemented. I'd personally see it as another method on the transformer and combine class to output a numpy ndarray, such as build_ndarray.

To input ndarray soundfiles, i guess this could be just some slight modifications on the args of the build method.

[rabitt]

I thought about this, and I decided it's out of scope for this library. I'd suggest simply writing the audio back to disk and then using pysox on the file. I realize this isn't ideal, but I think to do this in pysox without saving the audio first requires a lot of command line magic.

That said, if you find a clean way to do it, I'm happy to look at the PR.

[carlthome]

@justinsalamon, @rabitt, I've published a lightweight SoX effects wrapper (reverb, phaser, delay, etc.) that pipes NumPy ndarrays over stdin/stdout instead of creating extra I/O load with tempfiles. Maybe you can use bits of it in pysox: https://github.com/carlthome/python-audio-effects

[rabitt]

@justinsalamon can you open a separate issue about optionally disabling the overwrite warning?

[rabitt]

@carlthome Looks awesome! I plan to include this feature when I bump to v1.3

[justinsalamon]

@justinsalamon can you open a separate issue about optionally disabling the overwrite warning?

#25

[lostanlen]

@carlthome I do not think that solving this issue would require having all of librosa as a dependency. Since it's purely a matter of I/O, pysoundfile is sufficient for the most common lossless formats: WAV / FLAC / OGG

https://github.com/bastibe/SoundFile

[rabitt]

@hadware -

I'll try porting @carlthome 's work to pysox, It'd be nice if you guys could give me some pointers on how you'd wish it to be implemented. I'd personally see it as another method on the transformer and combine class to output a numpy ndarray, such as build_ndarray.

I agree that what makes the most sense is to have a separate function build_array that mirrors build but inputs and outputs an ndarray. I prefer this to overloading the current build function.

To input ndarray soundfiles, i guess this could be just some slight modifications on the args of the build method.

Yes, as far as I can tell it's doable by changing the input and output filename to the - character and piping the audio data to stdin. Some relevant info in the SoX documentation in the section on "Special Filenames".

In terms of capturing the audio data from stdout, I think everything is already in place, but if you run into issues, this is where the problem is likely to be.

Let me know if you need any help!

[pseeth]

I'm going to give addressing this issue a shot, mostly by trying to port @carlthome's pysndfx fix into this library. Do people have the bandwidth for a PR for this soon (hopefully)? Looking over the comments here, I believe such a change would require adding numpy as a dependency.

[danihodovic]

Is it possible to use the file_info API with in memory files?