librosa: Supress "PySoundFile failed. Trying audioread instead." warning
I’m trying to load an mp3 file with librosa.load(path) and it returns the following warning:
>>> import librosa
>>> librosa.load('mysong.mp3')
/data/anaconda3/envs/aidio/lib/python3.7/site-packages/librosa/core/audio.py:146: UserWarning: PySoundFile failed. Trying audioread instead.
warnings.warn('PySoundFile failed. Trying audioread instead.')
(array([-0.00183699, -0.00195219, 0.00391953, ..., -0.00337326,
0.00295902, 0.00624093], dtype=float32), 22050)
As I’m doing this multiple times it floods the stdout. So I have some questions:
- Why is this a warning? Does it imply something bad?
- Can I hide this warning text? As it floods my stdout in my batch operations.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 21
- Comments: 19 (9 by maintainers)
It’s a warning, not an error. This warning will always occur when loading mp3 because libsndfile does not (yet/currently) support the mp3 format. Librosa tries to use libsndfile first, and if that fails, it will fall back on the audioread package, which is a bit slower and more brittle, but supports more formats.
Yes, you can always filter warnings. https://docs.python.org/3/library/warnings.html
Any idea how to avoid getting this warnings printed on STDOUT?
I tried launching script with
python -W ignore <script>and adding:At the beginning of the scripts and this User Warnings keep poping out.
Edit: Nevermind it was my issue.
There is nothing to fix: this is operating as intended.
Again, this is not an error, it is a warning. Your code will work just fine, it just will fall back on the (slower) audioread decoder. This is unavoidable for now, since libsndfile still does not support mp3.
If you’re really concerned about speed, you could transcode your mp3s into a more permissive format (eg ogg vorbis).
Sure. The “brittle” comment mainly refers to software health. The audioread package has very minimal test coverage, and its dependency chain varies substantially across platforms and environments. Much of this is hidden from the end user, but it does make it difficult to debug and diagnose errors.
In terms of quality degradation, it should be fine. In principle, these formats should all decode to the same bit stream, but there will always be subtle differences arising from frame alignment, floating point rounding error, etc. MP3 decoders are notorious for this kind of thing.
Ok, i got it now. Thank you for the help 👍
I appreciate the motivation here, but I expect the entire point to be moot in the very near future. libsndfile supports mp3 now, and we’re basically waiting on a release of python-soundfile (currently on b6 for the 0.11 release) for this to be supported out of the box with no additional effort from our side.
Once soundfile releases with mp3 support, this warning should almost never appear - and when it does, it’s a sign that something actually is very wrong!
At any rate, our eventual plan is to deprecate and remove audioread support #1456 , but it is a bit of a question-mark about how long that will take in practice based on release cycles.
@bmcfee Great to hear, then I’ll hold my horses 😉