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.
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.
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.
StreamDataBlock needs a virtual d'tor since it is supposed to
be subclassed but the d'tor will be called on the base type.
The leaking file handles were observed by invoking the tests
with strace, eg.:
strace -e trace=file,close ./tagparser_tests
FLAC stores tags on track level. Hence we must parse the
tracks here in order to parse the tags. This hasn't been taken
into account when refactoring the tag editor CLI leading to
https://github.com/Martchus/tageditor/issues/36.
So let's handle these format specific details in the tagparser
library which will now internally parse tracks when calling
parseTags() on FLAC files.
This also fixes the weird behavior to consider tags supported
although the container format is unknown.
Those elements are still assumed to fill the max available
space. However, if it turns out one "child" is more likely
a sibling, the wrong assumption is fixed.
Martchus