Not for all recordings AcousticBrainz.org has data, hence the errors in the log. This is normal.
You should also be aware that the AcousticBrainz project has been deprecated and eventually will be removed. So at some point the plugin will stop working. See also
ok, after installing aubio I can remove “AcousticBrainz Tonal-Rhythm” because now BPM Analyzer can be installed. The log is clean after that. However, I don’t see any value for the BPM in the tags.
But there I research first here in the forum and should I find nothing I make a corresponding post on.
According to the blog entry, AcousticBrainz should still work - they have just stopped accepting new data.
I have tested this and I am getting the same issue.
According to the AcousticBrainz documentation the URL should be of the form http://acousticbrainz.org/api/v1/low-level?recording_ids=efe3ee26-69a9-4bec-a345-e028d529f05b rather than https://acousticbrainz.org/efe3ee26-69a9-4bec-a345-e028d529f05b/low-level however this does seem to work when I try it manually.
There is a rate limited in acousticbrainz of 10 requests in 10 secs, and it appears that is being triggered. I loaded an album in Picard and got the following rate control messages:
12:08:30,389 webservice/ratecontrol.get_delay_to_next_request:130: ('acousticbrainz.org', 80): Last request was 39 ms ago, waiting 61 ms before starting another one
12:08:30,398 webservice/ratecontrol.get_delay_to_next_request:130: ('acousticbrainz.org', 80): Last request was 48 ms ago, waiting 52 ms before starting another one
This suggests that the rate limit delay being used by Picard by default is 0.1s rather than 1s.
I cannot look at the Picard / Plugins code right now to see what rate limit is set for acousticbrainz, but I will take a look later and submit a plugin(s) PR if needed.
It turns out that acousticbrainz plugins do not use a 1s rate limiter - one uses 250ms and one 100ms. I will create a PR later tonight to change both to 1000ms.
P.S, AcousticBrainz (and other such services) provide headers defining time until next allowed request - perhaps Picard should watch for these and use them to override a clock-based timer.
P.P.S. Perhaps Picard should also dynamically adjust the rate limit timeout upwards when it gets a rate-limited HTTP status code and requeue the request (but not requeue infinitely I guess).
I have understood what the AcusticID does and what it is good for. What is not really clear to me is the question of what advantages it brings if I in Picard: Right click → AcusticID generate fingerprints.
execute. Does this improve the data in MusicBrainz? Or where is the benefit for the community and/or me?
The “generate fingerprint” on its own does not much useful really. All it does is running the fpcalc utility on the selected files to generate the fingerprint and make this available to Picard. But there are two use cases for this:
Some people want to submit fingerprints for already matched files. So let’s say you have files that you matched to the proper releases manually or by the lookup function. As you did not use “Scan” Picard does not have AcoustID fingerprints yet. Now you can generate the fingerprints for those files separately and then submit those fingerprints with the submit button.
The submit fingerprints button is what really helps improve the database, because it makes those acoustic fingerprints available in the AcoustID database and links them to the recordings on MB.
Similar as above some users want to save the acoustic fingerprint (note that this is different from the AcoustID) itself in the tags. As the fingerprint can be calculated from the audio at any time and tends to be rather large, by default Picard does not store it. But you can enable storing the fingerprint in tags in the options.
For most this is likely not very useful. But some users for example process the files later with different tools (sometimes custom ones) that make use of the stored fingerprints.
Likely I implemented the functionality on user request, but personally I also don’t need it. At least not for my normal use of Picard as a regular user. For development and testing it sometimes is useful.
If your files are already matched against MusicBrainz releases / recordings you can indeed improve the data. If you load the files with existing MBIDs in the tags into Picard it directly loads them into the right with the proper release data. If you then use “Calculate fingerprints” on those files and after this finished use the “Submit fingerprints” button then this helps the project.
But please only do this if you know the files have been matched to the proper releases / recordings.
If your files are not yet mapped to MusicBrainz then this is more work and you will need to identify all the files with Picard first and map them correctly.
