* This makes it harder to use the library wrongly and does not lead to
worse performance as character set conversions are only done as needed.
* That's actually already done by serializers for most tag formats. This
change ensures serializers for Matroska and Vorbis tag fields do this as
well.
* Update documentation accordingly.
* 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
On non-Windows platforms the internal representation used for paths is the
configured native (narrow) character set. Most of the time that's UTF-8 but
only on Windows UTF-8 is *always* used for the internal representation.
* Cache result of `verifyPresentTrackHeader()` instead of running the code
unnecassarily multiple times
* Do not tamper with existing/raw values by default to avoid
inconsistencies through rounding errors and possibly fix
https://github.com/Martchus/tageditor/issues/80
* Avoid conversions to double (depending on the time scale rounding errors
might still occur)
Martchus