-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
acousticbrainz: Really small float values are stored as strings #2790
Comments
Wow, that’s pretty bad! Is it possible to cause the same problem using |
Good catch. It works fine with |
Thanks! It looks like we need to be more careful about how we convert values from the analysis tool’s output to numeric Python values. |
Good digging, @rain0r. This reveals a slightly deeper problem, however: your change converts the value to be stored as a string, but we probably just want to store the underlying floating-point number! I believe the current code (without your change) is also converting to a string for storage, but in a less careful way that results in scientific notation. A better thing would be to take all the relevant fields and mark them as having a Lines 315 to 320 in 1edd21f
|
Thanks for the tip, @sampsyo, unfortunately, I didn't get it to work. |
Aha—any chance the correct value is being stored, but it's just being rounded when it's printed to the console? The stringification for floats uses a fixed precision: Perhaps we could make the precision a parameter to the type, so this field could use more than one decimal place when printing to the console. |
You are right, with a bigger precision, the displayed value is correct. |
Nice! Given that there are other float-valued fields in the system that probably want only 1 digit of precision (e.g., the ReplayGain fields), I think adding a precision parameter would be best. We can use a similar approach to the Lines 135 to 143 in 4d55e6d
|
Fix for #2790 - acousticbrainz: Really small float values are stored as strings
Problem
Using the acousticbrainz plugin (I don't know if it's specific to it, it might be a wider issue), when storing really small values, they end up formatted in an exponential style, e.g.
1.82764233614e-05
. As a result, the whole (flexible, in this case) attribute ends up being treated as a string - which forbids using ranges in query, for example.Here's an example with the recording
9dcdb20b-3bdf-4d1f-842f-d3cb545bea28
on MusicBrainz. Themood_happy
probability is really low on AcousticBrainz: http://acousticbrainz.org/api/v1/9dcdb20b-3bdf-4d1f-842f-d3cb545bea28/high-level?n=0 (field value is0.0000182764233614
). In beets, it ends up being stored as1.82764233614e-05
:Setup
My configuration (output of
beet config
) is: probably irrelevant too, I just have the plugin enabled without any configuration.The text was updated successfully, but these errors were encountered: