Some tag encoders like to use non-standard padding (see http://id3.org/Compliance%20Issues) which was causing "unexpected EOF" errors. Checking that each tag has a valid name (as per the spec) seems to be the only good way around this.
Previously we would seek to the beginning of the io.ReadSeeker. It is much more
flexible to assume that the caller passes the ReadSeeker in an appropriate state.
1) correct a bug with the mdat atom.
Sometimes, the metadata can be at the end, after the audio
Demo :
get any music file and strip the metadata
convert it to m4a with ffmpeg
analyse it with MusicBrainz Picard
et voila, you have the metadata at the end.
Example of structure of a m4a created that way;
https://www.dropbox.com/s/602yivdstan7506/atom.txt?dl=0
2) add support for the "----" tag
See http://atomicparsley.sourceforge.net/mpeg-4files.html
It gives access to the tags created by MusicBrainz Picard
The Seek in SumID3v2() didn't take into account the size of the ID3v2 Header
(10 bytes). Thus when tagging the same file with or without it's tag, there was
a discrepancy. (
And I've added a default case when parsing the id3v2 tags, by storing the
binary content to Raw()
I hacked readTextWithDescrFrame() and readTFrame() to generalize them
to other case (presence or not of a language and whether or not the
data part is encoded (URL are not)
This patch depend of 3b7a3d5485 since I found the
bug while developping this patch
Sometimes, we can have this configuration :
description 00 00 00 data (with delim = [00 00])
with splitN, we make the separation at the first 00 00 :
[description, 00 data]
But in fact, we must make the separation one byte later
[description 00, data]
