Both AAC and ALAC are normally embedded in an .m4a container. For
this reason I have split the m4a type into aac and alac types.
To distinguish between the two encodings I have taken advantage
of the fact that, in my collection, ALAC don't have a sample_rate
set. I could not find verification if this is always the case
or not. Would bitrate be a more reliable determining factor?
e.g. if bitrate > 320000: type = 'alac'
Signed-off-by: Simon Luijk <simon@simonluijk.com>
An earlier change (due to @pedros) added the ability for plugins to define
template fields that work with Albums as well as Items. This enables some
cool new use cases but required that every template field definition check the
type of its arguments. Instead, this iteration on the idea distinguishes
between fields meant for Items and those meant for Albums.
In addition to simplifying the implementation of these functions, this also
enables the creation of album fields with identical names to item fields.
(For example, a user contacted me recently about adding a $bitrate field for
albums, which would be the average bitrate of the items. They can do this now
using a plugin.)
I also changed the docs to stop using the decorator approach to registering
template fields. We're moving toward removing those.
That's 371cc72f2d09 in hg. This makes the patch slightly more general by
reusing our type conversion infrastructure. It also uses "bytes" as a synonym
for "str" that I find a little bit clearer.
Otherwise, this was penalizing all album matches.
This also applies the same treatment as the previous commit: only load the
config at run time (at the expense of code clutter).
By running .get() (or, rather, .as_number()) in the module scope, this was
forcing the configuration to be materialized when the module was imported.
This is a little bit messier but requires a less duplication and avoids that
early loading problem.
I know the as_number calls scattered throughout are rather ugly; I'm pondering
a solution to mitigate that.
Basically, it uses the helpers that handle conversion bytestring <-> unicode with the item's path, but weren't being used with artpath. For now, it just fixes the behavior for `modify`
Discogs (and other individual plugins) should return a penalty between
0.0 and 0.1, which will be multiplied by the general source weight. This
allows individual plugins to be weighted against relative to each other,
and amplified together against other penalty categories (track, title,
etc.)
