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

Use directly in memory, instead of via files, possible? #6

Closed
carlthome opened this issue Jun 27, 2016 · 14 comments
Closed

Use directly in memory, instead of via files, possible? #6

carlthome opened this issue Jun 27, 2016 · 14 comments
Assignees
Milestone

Comments

@carlthome
Copy link

carlthome commented Jun 27, 2016

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!

@rabitt
Copy link
Collaborator

rabitt commented Aug 6, 2016

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.

@rabitt rabitt closed this as completed Aug 6, 2016
@rabitt rabitt reopened this Aug 17, 2016
@rabitt rabitt added this to the 1.3 milestone Aug 19, 2016
@rabitt rabitt self-assigned this Aug 19, 2016
@justinsalamon
Copy link
Contributor

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

@carlthome
Copy link
Author

@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
Copy link
Collaborator

rabitt commented Oct 7, 2016

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

@rabitt
Copy link
Collaborator

rabitt commented Oct 7, 2016

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

@justinsalamon
Copy link
Contributor

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

#25

@rabitt rabitt modified the milestones: 1.4, 1.3 May 29, 2017
@smolendawid
Copy link

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.

@hadware
Copy link
Contributor

hadware commented Jan 27, 2018

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.

@carlthome
Copy link
Author

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

Consolidate:
image

@lostanlen
Copy link
Member

lostanlen commented Aug 2, 2018

@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
Copy link
Collaborator

rabitt commented Aug 10, 2018

@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
Copy link
Contributor

pseeth commented May 15, 2020

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.

@rabitt
Copy link
Collaborator

rabitt commented May 21, 2020

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.

@rabitt rabitt closed this as completed May 21, 2020
@danihodovic
Copy link

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

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

No branches or pull requests

8 participants