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.
This also involves finally implementing
Mp4Track::makeTrack(). Mp4Track::makeSampleTable()
which would enable modifying stbl atom is still not
fully implemented yet, though.