* 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
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.
* Close or flush streams explicitely so writing is not
deferred
* to catch errors in the right place
* to avoid suppressing errors completely when writing
would be deferred to the destructor invocation
* Improve comments
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.
Players seem to be able to at least skip ID3v2 or
are even able to display it. ID3v1 should not cause
any trouble at all because its use is even proposed
in the WavPack documentation.
Commit 'Fix duplicate notifications' (0f6ac6a) caused missing
notifications by omitting `addNotifications(*m_container);`
before clearing parsing results. This commit restores the old
behavior and will actually preserve all notifications. However,
it will cause duplicated notifications again. The notification
system must be reworked in v7 for a decent solution.