Closed ssssam closed 5 years ago
Thanks for the review. Yes, it's a good idea to avoid global state. We might need to rationalize the situation in pyacoustid and the beets/chroma plugin though:
Currently, beets/chroma doesn't depend on audioread. Can I change it so that it does depend on a future release of audioread that contains this branch?
pyacoustid currently only soft-depends on audioread. The fingerprint_file() function has a conditional which uses audioread and the 'chromaprint' library if both are available, and otherwise the fpcalc
program. Are the benefits to supporting all these options? We can easily add a parameter to the fingerprint_file()
function that accepts a list of audioread backends, but the behaviour of the function will then depend on 4 different factors: whether audioread is installed, the contents of the backends parameter, whether the chromaprint library is installed, and whether the fpcalc program is installed. It's difficult for API users to test that their code works in each of these different situations, so maybe we could take this opportunity to simplify pyacoustid, and remove either the audioread or the fpcalc option?
Currently, beets/chroma doesn't depend on audioread. Can I change it so that it does depend on a future release of audioread that contains this branch?
Yes, sounds good!
- pyacoustid currently only soft-depends on audioread. The fingerprint_file() function has a conditional which uses audioread and the 'chromaprint' library if both are available, and otherwise the
fpcalc
program.
Oh right; I completely forgot about that feature. This makes the situation a little more complicated, for both pyacoustid and for beets. It is actually really quite convenient for pyacoustid to support the command-line tool, which sometimes easier to install (e.g., on Windows) than the library. On the other hand, talking directly to the library is the "right way" to do things on systems with a proper package manager.
Here's a strategy that might be nice to have, even if we weren't doing this whole "persistent backend detection" thing: empower pyacoustid with flags that control which backend is used. The appropriate function could behave as it does now when nothing specific is supplied (preserving backwards compatibility), or it could:
Having that additional level of control would be nice, and it wouldn't impact the configuration-free use case either.
Since #84 I've weirdly not seen any performance issues related to backend autodetection. I'm not sure why. However, I think it's still a good idea to add a separate available_backends()
method, so I've updated this branch and slightly cleaned it up.
Looks great; thank you! This will be useful to have in case we find performance problems due to backend detection in the future.
On that note, thanks for all your attention to this project over the last few weeks! I've sent you an org invitation in case you'd like to commit more work in the future. PRs are of course always still an option if you want a code review, but you should now have permission to merge your own if that ever seems appropriate.
OK, thanks! I promise not to sneak in any bitcoin mining code ;)
This is a performance improvement. See https://github.com/beetbox/audioread/issues/81 for details.