Not copying the termination character here is wanted. Just use
`std::memcpy` to avoid it as the special behavior of `std::strncpy` is not
needed here anyways.
* 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).
Due to the fallthrough the warning would be printed in any case when using
UTF-8 and not only if the BOM is actually written (as there are non-ASCII
characters). This problem became apparent when using the tageditor's CLI
with `--id3-init-on-create` to create an ID3v1 tag from ID3v2. Of course it
doesn't help if there are actually non-ASCII characters present.
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.
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.)
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