The `Image.type_index` property is only used for tags that require an integer
to store the cover type like ID3v2. If the type of an image is not set we let
`type_index` return the integer for an "other" image. Other than a default
"front" value, this makes sure we do not inadvertidly add an image that will
be displayed in a player.
This puts the OrderedEnum generic class next to where it is actually used. It
also refers to the recipe it is taken from on docs.python.org. I also took the
opportunity to give this a capitalized name (since it's a proper type).
This is not really critical since list(Type)[i] works just as well. This fixes
a couple other problems from the enum transition:
- The name of TYPES was not really consistent with its new role as an enum
type. Renamed this ImageType.
- Fix a rather egregious bug in embedart (undefined reference to Image).
You now call update() followed by save(). This is mainly because the
implementation no longer performs lazy updates, so the need to pair tag
setting and writing together was diminished. Benefits in cleanliness:
- No need to duplicate the id3v2 option.
- Exception handling can be more precise.
- More closely resembles dict.update().
Following the convention of the other field sets and such. This helps avoid
any confusion with user-specified fields (although it's unlikely people will
want to name a flexible field "media_fields" :).
* `encode()` raises an error when the command returns with non-zero exit
status. We catch that in the higher-level conversion functions and skip to
the next item without writing tags.
* Simplified the handling of the `keep_new` flag.
In preparation for #660, where we will allow MediaFile to expose None values
when tags are missing (and consume None to remove tags). This makes it
possible to hide nullness in the rest of beets by translating None to a
suitable zero-ish value on field assignment.
Types can of course opt out of this to preserve a distinct null value. We do
this now for the album_id field, which needs to be null to indicate
singletons.
Type.normalize() also enables more sophisticated translations (e.g., an
integer field could round off float values assigned into it) in the future.
