bug in header size fld?

[Ray]

> > i've run into a few strange oddities in that 2.4
tags
> > seem to get truncated on my mobile mp3 player.
> > tracking this down i got 2 empty files and tagged
them
> > 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
handle ID3v2.4
> tags.  In 
> fact, many can't handle ID3v2.3 tags either.  They
usually
> handle ID3v1, 
> which is also written by taglib, but which has a
fixed maximum
> field length 
> (I believe 31 characters in most situations).  So
this may be
> what you're seeing.
>
> --Jeff

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?

thanks
ray


      ___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/