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.)
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.
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.
* So everywhere else can be safely assumed that
text values never have a BOM
* Only exceptions are move constructor and move
assignment where the caller must ensure no BOM
is present
Martchus