* Move those fields into their corresponding
TRACKNUMBER/DISCNUMBER/PARTNUMBER fields after parsing so they are
accessible via just one field as PositionInSet which is in line with
other tag formats and also how other software like VLC expect the total
to be specified
* NOT implemented yet: Move those fields optionally back into separate
fields when serializing
* Define `CHRONO_UTILITIES_TIMESPAN_INTEGER_SCALE_OVERLOADS` consistently
with all necassary changes
* Avoid ambiguity between enum members and certain class/struct names
* Allow one to get a `Popularity` where `.rating` is always between 1 and 5
via `TagValue::toScaledPopularity()` (or a "raw" scale by specifying the
corresponding tag format)
* Allow one to assign a `Popularity` with `.scale = TagType::Unspecified`
and `.rating` between 1 and 5 (or a "raw" scale by specifying the
corresponding tag format). It will then be converted internally to
the required scale (whatever the tag format internally uses)
* Ensure all tag formats with popularity/rating field use
`TagValue::toScaledPopularity()` internally when a `Popularity`
object is assigned
* Ensure all tag formats with popularity/rating field store the rating as
popularity object to preserve the scaling information
* Keep passing raw strings around working
* `TagValue::toString()` still does *no* scaling
* `TagValue::toScaledPopularity()` does *no* scaling for text values
and instead just assigns the specified scale
* See https://github.com/Martchus/tagparser/issues/23
This would allow implementing a way to convert between different scales and
which in turn would allow the UI to provide an editor with a generic scale
(e.g. stars) instead of only allowing to edit raw values as string.
This also make it assume that a single number is meant to be the rating
(instead of the user). That should make editing the rating a bit more
straight forward (if one doesn't care about the user and play counter).
* Propose the usage of the popularity type in general for the rating field
so GUIs can show an appropriate UI element
* Do not just propose the popularity type for ID3v2 tags so a uniform UI
element can be shown accross tag formats; and API to convert from a
uniform scale is still TODO
* Fix applying changes to symlinks so that the target is modified in any
case (and not just if a rewrite isn't necessary)
* Avoid using `std::rename` and `std::remove` because they might not work
under Windows when the path contains non-ASCII characters
* Simplify code, remove `isRelative()`
Different media/tag formats specify languages and countries
differently. This change introduces a Locale class to keep track
of the format being used. So far there are no automatic conversions
implemented so it is entirely up to the user to pass valid values using
a format which matches the one required by the media/tag format.
This change also adds support for Matroska's IETF elements so at least the
raw value can be read, written and is preserved.
That an automatic conversion happens for different types but not
for different encodings was always a bit odd.
This makes writing tests easier and comparing values within the
tag editor does not rely on choosing a particular encoding.
since it is apparently used by some software.
But
* Write at least a BOM so it can be interpreted later
correctly as UTF-8
* Print a warning
* Keep proposing Latin-1
The tag editor should allow to configure which encoding
is used and whether the BOM is used and which encoding is
assumed when parsing a file.
Martchus
Jonas Kvinge