Avoid needless field writes via dirty tracking in Item

[sampsyo]

As mentioned in #157, #628, #637, etc., it is unfortunate that beets will write metadata tags that seem unnecessary. Just because beets supports the "composer" field, for example, all MP3 files get an empty frame added.

This stems from a useful motivation: to alleviate most of the code from needing to worry about the distinction between a missing field and a null-valued field. But it also means that some other software behaves badly when confronted with all these null-valued fields. ReplayGain fields are a particularly pernicious example.

We can (possibly) get the best of both world just by adding some reluctance to Item: it should only set fields on MediaFile in the write() method when those fields have actually changed. This would use exactly the same dirty-bit approach that the Model base class in dbcore uses to avoid needless database updates.

[ktkonrad]

I haven't actually tested this but from looking at the code, I'm not sure this is the case. Item populates a MediaFile using a MediaFile's update method, which looks like

def update(self, dict):
    for field in self.fields():
        if field in dict:
            if dict[field] is None:
                delattr(self, field)
            else:
                setattr(self, field, dict[field])

It seems that if the field's value is None, it is not stored in the MediaFile object. Am I missing something?

[sampsyo]

Yes, but most fields cannot be None. For example, if a file is missing the "artist" field and is imported into beets, the database reads that field as the empty string. (This is a useful property so that all fields have useful defaults.) Then, when the file is written, update gets an empty string instead of None, so the tag is added.

[ktkonrad]

Thanks! Makes sense.

[tlc]

#930 highlights that some floating point values are being changed in the audio files by unneeded writes of the fields.
That specific issue could be fixed by

1. Fixing this larger issue.
2. Detecting and maintaining the precision.
3. Storing read floating point values as strings. (I assume they're stored as floats since 'beet ls' rounds them differently.)

I assume number 1 is the most desirable as it's solving the larger issue.

Also, not knowing the code base and reading the discussion above about empty strings vs None, I wonder why the code that writes to files couldn't check for empty string at write?