bug in header size fld?
whatdoineed2do at yahoo.co.uk
Thu Oct 18 20:22:25 CEST 2007
> > i've run into a few strange oddities in that 2.4
> > seem to get truncated on my mobile mp3 player.
> > tracking this down i got 2 empty files and tagged
> > with the same details using 1 misc tagger and then
> > something using taglib1.4
> I haven't gotten into the details of it yet (I'd
have to get
> into the spec)
> but off the cuff, most mobile mp3 players can't
> tags. In
> fact, many can't handle ID3v2.3 tags either. They
> handle ID3v1,
> which is also written by taglib, but which has a
> field length
> (I believe 31 characters in most situations). So
this may be
> what you're seeing.
thanks for the reply. after a little more digging i
found that the music device (SE w880 phone) does
actually support id3v2.4 but it didn't like UTF8
encoded txt frames; Latin1 or UTF16 id3v2.4 txt frames
seem fine -- the problem i had originally was that all
txt frames were encoded as UTF8.
however, i've got another Q; according to the id3v2.4
spec, section 3, "The bitorder .. is most significant
bit first", ie BE byte order. i'm running off x86 so
i've got LE byte order and if we look at the header of
a sample mp3 tag from a file which has a tag size of
1083 bytes (was empty file, with a tag resulting in
1093 file size):
4449 0433 0000 0000 3b08 5054 3145 0000
I D 3 004 \0 \0 \0 \0 \b ; T P E 1 \0 \0
looking at bytes 7-10 (the tag size) '0000 3b08', we
see this size stored as a LE synchsafe int,
representing 1083 bytes.
therefore, is this a bug in the byte ordering code or
is it something i misunderstanding from the spec?
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
More information about the taglib-devel