scaper
scaper copied to clipboard
Unexpected warnings with dumping sources alongside mix
output_file: /tmp/tmprpqkwioa.wav already exists and will be overwritten on build
output_file: /tmp/tmpeup76dd4.wav already exists and will be overwritten on build
Also, I forgot to mention this one, which seems to happen in conjunction with one above:
Input formats were only specified for 0 out of 2 files.The last 2 files will remain unformatted.
Have to track these down - I believe they're coming from making the temporary files for the sources and then copying them somewhere. Maybe a collision?
Yes, at first I thought it was from the seed being the same each run, but it remained after changing the seed.
The temp file warnings are mentioned here: https://github.com/rabitt/pysox/issues/6 The input formats warning is mentioned here: https://github.com/rabitt/pysox/issues/85
Yes, these are all sox warnings rather than scaper warnings. I forget whether it's possible to disable these, looks like it might not be supported yet based on the issues @epicycles has mentioned still being open.
We have 3 possible solutions:
- (short term): ignore the warnings and carry on
- (short term): make a PR to pysox to add the missing functionality
- (long term): replace pysox altogether with in-memory audio processing
In the long run I want to move toward 3. I'll see if I can manage 2 in the near future, but can't guarantee it. In the meanwhile, we're stuck with 1 :)
Using disable_sox_warnings=True in scaper.generate() makes things look better.
Should we change the default of disable_sox_warnings from False to True?
Should we change the default of disable_sox_warnings from False to True?
OK, I think we can change it.
In this case we might want to add a line at the end of the docstring for disable_sox_warnings
along the lines of "If you're experiencing issues related to audio I/O setting this parameter to True may help with debugging".
Huh, so it actually is already True. My bad. The warnings only occur when their level is critical, apparently. So is it not working? Did John get a lucky run when the warnings went away? Confused.
Just revisited the code :) Per the docstring:
disable_sox_warnings : bool When True (default), warnings from the pysox module are suppressed unless their level is
'CRITICAL'
.
So, in principle, when disable_sox_warnings=True
(default) you shouldn't see any sox warnings unless they're of the critical category. If it's set to False, you should see all sox warnings. Maybe @epicycles initially set it to False to be on the safe side and later changed it back to True? I don't know.
In any case, since sox will be completely replaced in the long run, I don't know that it makes sense to worry about this too much?
Yeah, I don't think it's critical. I did add "If you're experiencing issues related to audio I/O setting this parameter to True may help with debugging" to the docstring in #55 since I was in the neighborhood, though!