* Define `CHRONO_UTILITIES_TIMESPAN_INTEGER_SCALE_OVERLOADS` consistently
with all necassary changes
* Avoid ambiguity between enum members and certain class/struct names
* The warning about `bsEnvCount` is actually correct.
* The warning about `lastAtomToBeWritten` might be correct.
* The warning about `relPos` is definitely unjustified because `relPos` is
only used when `cueRelativePositionElement` is not `nullptr` and `relPos`
is initialized in that case.
* The warnings about `pos`, `nextPageOffset` and `startOfLastMetaDataBlock`
are also wrong for similar reasons.
* 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
* 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()`
* Do this by default with an opt-out; changing only known fields should not
be very intrusive
* Fix recognizing known fields when only the case differs, see
https://github.com/Martchus/tageditor/issues/72
Especially when dealing with big files the performance is quite bad. This
change speeds it up a little by using an unordered map to find the elements
for certain offsets instead of using linear lookup.
According to callgrind the modified functions where one with the biggest
own cost. The function updateRelativeOffsets() was actually the 2nd costly
function just below __memcpy_avx_unaligned_erms.
Now TagParser::EbmlElement::internalParse(TagParser::Diagnostics&) is quite
high as well as standard IO stream functions.
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.
For now let's just ignore these elements explicitely until they are
actually supported. This way the warnings are at least more specific and
there will be no inconsistency when updating the track language.
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.)