TCON
The 'Content type', which previously was stored as a one byte numeric value
only, is now a numeric string. You may use one or several of the types as
ID3v1.1 did or, since the category list would be impossible to maintain with
accurate and up to date categories, define your own.
References to the ID3v1 genres can be made by, as first byte, enter "("
followed by a number from the genres list (appendix A) and ended with a ")"
character. This is optionally followed by a refinement, e.g. "(21)" or
"(4)Eurodisco". Several references can be made in the same frame, e.g.
"(51)(39)". If the refinement should begin with a "(" character it should be
replaced with "((", e.g. "((I can figure out any genre)" or "(55)((I
think...)". The following new content types is defined in ID3v2 and is
implemented in the same way as the numerig content types, e.g. "(RX)".
To test it, use the id3v2 tool
% id3v2 -g 79 test.mp3
% id3v2 -l test.mp3| grep TCON
TCON (Content type): Hard Rock (79)
% ./tag test.mp3| grep Genre
Genre: (79)
With the patch :
% go build && ./tag test.mp3| grep Genre
Genre: Hard Rock
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 3b7a3d548500bd10afa63819a9904ac12e15cdc5 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]
Xavier Henner