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" :).
The test show that we can replace the hard-coded `ITEM_KEYS_WRITABLE` constant
with the computed value derived from `MediaField.fields()` and ITEM_KEYS. This
will be done in the next commit.
For MP3s mutagen stores image tags in a hash with the `APIC:...` key. The order
of the images is therefore not well defined. A similar issue occurs with WMAs.
Added a `coverart.ogg` fixture file that contains raw image data encoded as
base64 in the COVERART tag. We test that the `art` property on mediafiles
correctly reads these tags and transforms them into METADATA_BLOCK_PICTURE tags
on write.
Before, each year, month, and day field used packing to store its values in the
same tag but at different positions. We then instantiated a
`CompositeDateField` to combine the different values. This lead to code
duplication in the storage styles for these fields. It also inverted the data
dependency. It's more natural to think of year, month, and day as part of a
date then as of a date as composed of these.
Now, only `DateField` class stores data in the files tag. This makes sense: One
tag, one field that accesses it. To obtain access to the year, month, and day
parts, the DateField is equipped with factories that create `DateItemField`
instances associated to a `DateField`. These descriptor allow us to get and set
parts of a date field.
This is fixed by allowing MediaFiles to convert strings to integers on
assignment. An eventual complete fix will perform these type conversions in the
Item interface.
In the case that Mutagen throws an exception while trying to read a file, we
throw an UnreadableFileError, which is a new superclass for FileTypeError.
This entailed:
- changing the "flac" storage style option to "etc" to encompass both
flac and vorbis as the tags are very similar
- permitting multiple StorageStyles per field/format, to allow a
read-any/store-all approach to multiple field options
current metadata to be correct if it's complete
Previously, we were using the Munkres algorithm (minimum bipartite matching) to
order tracks intelligently only as a fallback if the current metadata was
paradoxical or incomplete. This was because of a concern about the performance
of the potentially-O(n^3) Munkres solver. However, it was found that (a) the
performance is actually not bad, taking on the order of 0.02 to perform a
matching, and (b) there was no recourse for the tagger to reorder tracks that
were legitimately in the wrong order. Now, we get intelligent reordering of
badly tagged music even when the metadata seems to be complete.
To retain some of the functionality of the old orderer, the track distance
metric was expanded to include a component reflecting the track index.
In doing this, another bug was discovered in the UI that showed the track name
differences based on an arbitrary ordering. Now, the tag_album function returns
a reordered items list with every candidate.
Also, new organization for tests and automatic loader. Fixed bugs uncovered by new tests.
--HG--
extra : convert_revision : svn%3A41726ec3-264d-0410-9c23-a9f1637257cc/trunk%4069
