* 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
* 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).
"DATE" is an official field and "YEAR" only an inofficial one but present
in some files. In consistency with MediaInfo and VLC player it is treated
like "DATE" here.
1. Convert TYER and related fields of old ID3v2 versions to the new TDRC
field and only expose that via the generic accessors.
2. When writing an old ID3v2 tag, convert TDRC back to the old fields.
3. One can still manually unset the via 1. auto-populated TDRC to disable 2.
and write the old fields directly. So the automatic handling does not
reduce the flexibility of the library.
4. Deprecate 'Year'; it is replaced by the already existing 'RecordDate'
which is now supposed to be used everywhere where 'Year' was used before
5. Introduce 'ReleaseDate' to support this field which is supported in
ID3v2.4.0 and Matroska via the generic accessors.
6. Use ISO format when converting tag values of the type DateTime to/from
string. This is closer to what's used in ID3v2 tags internally. (The
library still allows the old format as fallback when parsing for
compatibility.)
This should fix all non-erros, leaving only warnings which
are indeed potential problems.
The following warnings should be safe to ignore:
* Conversions of various offsets from uint64 to
std::streamoff/int64 are safe because such offsets have
been obtained via tellg() and other functions
returning std::streamoff in the first place.
* It also works vice-versa since tellg() should not
return negative offsets with exceptions enabled.
* Conversions from char to unsigned char are also ok.
* Unused diag arguments can be ignored (those might be
useful later).
* Annotate all intended fallthoughs.
Martchus
Jonas Kvinge