Audioread should not be a strict dependency

[johnlawsharrison]

Or there should be an option to use fpcalc even when audioread is found.

I came across this issue in my project:

audioread would not work on my system because we use kissfft, which audioread doesn't seem to support.

To get around this, I decided to use pyacoustid with fpcalc.

However, pyacoustid requires audioread (https://github.com/beetbox/pyacoustid/blob/master/setup.py#L44) and having audioread prevents running fingerprinting with fpcalc (https://github.com/beetbox/pyacoustid/blob/master/acoustid.py#L323)

The simplest workaround in this case is to uninstall audioread so that it won't be found, which feels kludgy and would require maintenance to uninstall audioread any time a requirement install including pyacoustid is performed.

[sampsyo]

Yeah, I agree that this is not an ideal situation. But I'm actually not sure what the best option is here—the easy answer is just to remove audioread as a dependency from setup.py, but that makes things considerably less convenient for situations where audioread is a natural dependency. On macOS, for example, audioread lets pyacoustid use built-in audio decoding libraries.

Other options include:

• You could explicitly invoke the fpcalc-based backend in your code.
• We could "fall back" from audioread when it fails to decode audio, or when we detect that it doesn't have any useful backends available.
• We could prioritize fpcalc over the library backend.
• You could uninstall the acoustid shared library while leaving fpcalc installed.

[johnlawsharrison]

@sampsyo I've added another possible option as PR #49

Gives the caller the option to prioritize fpcalc if they really want to. That feels better to me than changing the overall priority (which I bet would have consequences for plenty of users who are relying on how that priority works now)

[sampsyo]

Fixed in #49.