Some tag fields allow to store additional values or other data related to
the value. It likely doesn't make much sense to keep the this data when
setting a new value.
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.
Most players/tools can cope with MP3 files which have some bytes of junk
after the ID3v2 tag just fine, e.g. ffmpeg shows just
```
[mp3 @ 0x559e1f4cbd80] Skipping 1670 bytes of junk at 1165.
```
and most players can play the file just fine.
This change makes the tag editor also more resilient, allowing it to skip
a certain amount of junk bytes before a known container is detected. It
will also skip a certain amount of junk MPEG audio frames.
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.
"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.
It just looks nicer to have e.g. "2017" instead of "2017-01-01T00:00:00".
The ID3v2.4.0 standard and the Matroska standard explicitely allow this
format as well.
Martchus