Make R128 fields floats

[ybnd]

Description

Fixes #4169

• r128_*_gain fields are used to store LU values internally and are converted to Q7.8 (i.e. int(LU * 256)) in mediafile
• Storing these as integers internally caused loss of precision compared to non-R128 gain

To Do

• Documentation. (If you've add a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
• Changelog. (Add an entry to docs/changelog.rst near the top of the document.)
• Tests. (Encouraged but not strictly required.)

[sampsyo]

Overall seems like it will (a) do the job and (b) be harmless!! Could you please tack on a quick changelog entry describing the fix? Then I think we should be good to go.

[sampsyo]

Looks great; thanks!! I'll merge this now.

The one thing that worries me slightly is that using floats here is somewhat likely to create a kind of "infinite write/update cycle" where it's impossible to get the database to perfectly match metadata tags. That is, running beet write or beet update to sync the database information with the on-disk tags will show a change in precision, even when run twice. That's not a huge deal, obviously, but maybe we'll want to fix it down the line by introducing a fixed-point database type.

[wisp3rwind]

Do we need to upgrade the database here and issue a warning to user's that they should consider re-running the replaygain calculation?

[sampsyo]

That's a good question… I believe everything will continue to work as it did before for people with existing databases (with integers in the SQLite column) because the NullFloat type doesn't do any normalization of the underlying value. So I believe we will at least do no harm by not upgrading the database.

Of course, users may still want to re-run RG to calculate more precise values. But I can't immediately think of a good way to elegantly detect this situation and issue a warning…

[wisp3rwind]

That's a good question… I believe everything will continue to work as it did before for people with existing databases (with integers in the SQLite column) because the NullFloat type doesn't do any normalization of the underlying value. So I believe we will at least do no harm by not upgrading the database.

You seem to be right, since SQLite has no strict types, only type affinities. From a quick glance, our database upgrade code will only check if there's a mismatch in existing and expected column names, but not type affinities.

Of course, users may still want to re-run RG to calculate more precise values. But I can't immediately think of a good way to elegantly detect this situation and issue a warning…

We could detect that the r128_ columns have INTEGER type affinities, issue a warning, and convert them to REAL columns. I imagine it might take some experimentation to implement this in a way that isn't a big hack.