From paul_t100 at fastmail.fm  Wed Feb 14 02:36:22 2007
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Wed, 14 Feb 2007 10:36:22 +0000
Subject: [ID3 Dev] Minimum length of an ID3v23 tag
Message-ID: <45D2E626.7000009@fastmail.fm>

Hi, what is the minimum allowable length of an ID3v23 (and ID3v22 and 
ID3v24) tag, is it just 10 bytes (the tag header) or does it have to be 
greater than that.

thanks paul

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jaslane64 at yahoo.com  Sun Feb 18 10:15:29 2007
From: jaslane64 at yahoo.com (John Slane)
Date: Sun, 18 Feb 2007 10:15:29 -0800 (PST)
Subject: [ID3 Dev] Need Help Understanding My Own Tags
Message-ID: <491749.19627.qm@web53503.mail.yahoo.com>

I am not a developer.  I am a user who is very confused about how my id3v2 tags are being created and read by various software packages.  I have used programs like iTunes, MediaMonkey, id3Tag, AllFrames Tagger, and more.  Each of these seems to have its own way of writing metadata to an id3v2 tag.  And each can read SOME of the frames written by the others.  Some of the frames written are STANDARD frames (like YEAR), and others are NONSTANDARD (like COMMENT MUSICMATCH_MOOD).  I am near despair in trying to figure out how one program is going to interpret the frames written by another.

It seems to me that I would benefit greatly if I could simply see what actual frames these programs are writing to.  The id3v2 standard defines 74(?) frames: AENC, APIC, COMM, COMR, ..... etc.  None of the tagger software I mentioned above identifies which of these frames is actually being used.  Therefore, I have no way of directly comparing the way these programs read and write.

Can you suggest any available Windows software that will let me:
- read the tag of an mp3 file, 
- see the metadata in ALL the frames, and - most importantly -
- see the 4-letter code name (AENC, APIC, ...) for each frame?  

With such a tool, I could see what my music software is actually doing to the tags, and figure out how to make the tags from one program work with another.

Freeware would be best, of course.... but I'm getting desperate enough to buy if necessary. ;-)

Any help you can provide would be greatly appreciated.  I have been working on this for weeks, with virtually no progress whatsoever.

If my questions are not within the scope of this mailing list, please forgive my ignorance.

If there is another authority I might more appropriately contact, I would appreciate contact info.

Gratefully,
John Slane
Dublin OH
jaslane64 at yahoo.com

 
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070218/adce9b28/attachment.html>

From jwhite at cdtag.com  Fri Feb  9 19:45:06 2007
From: jwhite at cdtag.com (Jud White)
Date: Fri, 09 Feb 2007 21:45:06 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <BAY111-DAV13338E93CAC52BDB5A1D46DD930@phx.gbl>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <45CD2A93.8000906@coe.neu.edu> <45CD31B8.2010403@cdtag.com> <BAY111-DAV13338E93CAC52BDB5A1D46DD930@phx.gbl>
Message-ID: <45CD3FC2.6040802@cdtag.com>

4.2.   Text information frames

   The text information frames are the most important frames, containing
   information like artist, album and more. There may only be one text
   information frame of its kind in an tag. If the textstring is
   followed by a termination ($00 (00)) all the following information
   should be ignored and not be displayed. All text frame identifiers
   begin with "T". Only text frame identifiers begin with "T", with the
   exception of the "TXXX" frame. All the text information frames have
   the following format:

     <Header for 'Text information frame', ID: "T000" - "TZZZ",
     excluding "TXXX" described in 4.2.2.>
     Text encoding                $xx
     Information                  <text string according to encoding>

Hope this helps.

Dale Preston wrote:
> If I understand the published specification, the TYER frame is not a
> terminated string which would start with an encoding byte but is, instead, a
> numeric string.  The spec states specifically "always four characters long".
> Is this not correct?
>
>
> Dale
>
>
>
> -----Original Message-----
> From: Jud White [mailto:jwhite at cdtag.com] 
> Sent: Friday, February 09, 2007 8:45 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.
>
> Dale,
>
> It's the text encoding byte, and the terminator is optional, at least to 
> the point where the spec says ignore anything that comes after a 
> terminator in a text field.
>
> Brian Mearns wrote:
>   
>> They must be preparing for the Y10K bug.
>>
>> -Brian
>>
>> Dale Preston wrote:
>>     
>>> I have a couple additions for the compliance issues list.
>>>  
>>>
>>> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They 
>>> are 5 bytes long though the standard specifically states they are 
>>> always 4 bytes long.  The leading byte is a zero value.
>>>
>>>  
>>>
>>> Windows Media Player 11 leads with a zero value byte but also appends 
>>> a zero value byte, giving a length of 6 bytes for the ID3V2.3 TYER 
>>> frame.
>>>
>>>  
>>>
>>> I can provide samples if necessary.
>>>
>>>  
>>>
>>>  
>>>
>>> Dale
>>>
>>>  
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
>   



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Sat Feb 10 15:53:30 2007
From: dalepres at msn.com (Dale Preston)
Date: Sat, 10 Feb 2007 17:53:30 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <9AF2FC64-2075-4535-9A47-CBFB1C7CC3C2@maseurope.net>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <A5027469-5A38-4356-A51A-A3D8BCD7755F@maseurope.net> <BAY111-DAV13720B4F14E066536CDF3CDD930@phx.gbl> <9AF2FC64-2075-4535-9A47-CBFB1C7CC3C2@maseurope.net>
Message-ID: <BAY111-DAV64110C3CA3D3C01417AF0DD930@phx.gbl>

Well, I'm glad you got some benefit out of it. :)  It turns out my own
implementation was correct.  I just had a serious case of H.U.A. last night.

Dale

-----Original Message-----
From: Mark Smith [mailto:masmit at gmail.com] On Behalf Of Mark Smith
Sent: Saturday, February 10, 2007 4:30 AM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.

Well,  thanks for bringing it up. I'm just in the process of writing  
a tagging library for a high-level scripting language called  
Revolution (formerly metaCard), and it's good to test my  
understanding of the specs when questions arise and discussion  
happens....


Best,

Mark

On 10 Feb 2007, at 04:12, Dale Preston wrote:

> Yeah, as Jud said, as well.  That was hard to accept; I've been  
> doing it
> wrong for 2 years.
>
> Dale
>
>
> -----Original Message-----
> From: Mark Smith [mailto:masmit at gmail.com] On Behalf Of Mark Smith
> Sent: Friday, February 09, 2007 8:54 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.
>
> The spec also says, with regard to all the text frames excluding TXXX:
>
> 4.2 <Header for 'Text information frame', ID: "T000" - "TZZZ",
>       excluding "TXXX" described in 4.2.2.>
>       Text encoding                $xx
>       Information                  <text string according to encoding>
>
> And it doesn't specifically exclude the TYER frame. Nor does it
> exclude the TYER frame from being a null-terminated string. The data
> itself is still just 4 chars, so it seems kind of open to
> interpretation. iTunes 7 does the same (nulls front and back), for
> what it's worth.
>
> On the other hand, maybe MS and Apple are thinking really, really
> long-term, and are leaving space in there for the year 10000 and  
> beyond.
>
> Mark
>
>
> On 10 Feb 2007, at 02:05, Dale Preston wrote:
>
>> I have a couple additions for the compliance issues list.
>>
>>
>>
>> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They
>> are 5 bytes long though the standard specifically states they are
>> always 4 bytes long.  The leading byte is a zero value.
>>
>>
>>
>> Windows Media Player 11 leads with a zero value byte but also
>> appends a zero value byte, giving a length of 6 bytes for the
>> ID3V2.3 TYER frame.
>>
>>
>>
>> I can provide samples if necessary.
>>
>>
>>
>>
>>
>> Dale
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Sun Feb 11 17:58:16 2007
From: jwhite at cdtag.com (Jud White)
Date: Sun, 11 Feb 2007 19:58:16 -0600
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com>
Message-ID: <45CFC9B8.3010606@cdtag.com>

Please correct me if I'm wrong... do you have to purchase a membership 
to report a bug?

I have a few things to report:

1. In ID3v2.4, non-syncsafe sizes are written to frames (ie, bit 7 is 
used).  The spec has changed in regards to how frame sizes are written 
from ID3v2.3 to ID3v2.4.  Also, iTunes does not read frames written with 
syncsafe sizes correctly.  See http://id3.org/id3v2.4.0-structure, 
section 4, paragraph 3.  Frame sizes should be written the same way as 
the total tag size is written in the header in ID3v2.4.  Also, it's easy 
enough to determine which size-encoding method was used by attempting to 
seek to the next position and testing for a valid frame signature/end of 
tag; in other words, it's not too late to correct this behavior.
 
2. Reading APIC frames with a text encoding of anything other than 
ISO-8859-1 results in "No artwork" (all ID3v2 version).

3. APIC frames need the "MIME Type" field set (in ID3v2.3 and ID3v2.4) 
and the "File Extension" field set (in ID3v2.2) in order to display an 
image.  However, it only seems to be checking that the MIME Type/File 
Extension are recognized - for example, a JPEG can be saved with a File 
Extension of "jpg", "png", or "bmp" and still be displayed.  I think the 
point here is some implementations may not write the MIME Type/File 
Extension at all to APIC frames, in which case iTunes will not display them.

Also, Dale owned up to have HUA syndrome - what he found was not a bug. :)

-Jud

Ernest Prabhakar wrote:
> Have you filed a bug? 
>
> http://developer.apple.com/bugreporter/bugbestpractices.html
>
> If you can file a specific bug explaining the concrete, real-world 
> interoperability consequences, I can help escalate it to the iTunes team.
>
> -- Ernie P.
>
> On Feb 9, 2007, at 6:46 PM, Dale Preston wrote:
>
>> Apple iTunes suffers from the same problem as Windows Media Player 11 
>> when it comes to ID3V2.2 TYE and ID3V2.3 TYER frames.  In both tag 
>> versions iTunes adds a leading and trailing zero byte to the frame.
>>
>>  
>>
>> And, of course, there?s the issue of iTunes defaulting to the 
>> obsolete ID3V2.2 tag in the first place.
>>
>>  
>>
>> Dale
>>
>>  
>>
>>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jaslane64 at yahoo.com  Mon Feb 19 04:55:33 2007
From: jaslane64 at yahoo.com (John Slane)
Date: Mon, 19 Feb 2007 04:55:33 -0800 (PST)
Subject: [ID3 Dev] Need Help Understanding My Own Tags
In-Reply-To: <BAY111-DAV7FBA15945ECBAD29B6842DD8A0@phx.gbl>
Message-ID: <590473.70820.qm@web53514.mail.yahoo.com>

Dale,

Thanks very much.  The command-line routine that Mike M. sent me allowed me to begin understanding how various different taggers utilize the frames in an ID3v2.  The approaches are so improvisational, it's amazing they can read each others' tags at all.  Without the help from Mike, you, and others, I'd still be completely in the dark on how to begin tagging my giant collection.

Your Raw Tag Viewer looks like it might enlighten me still further, and perhaps provide some added convenience.  I will most certainly give it a good look when I get home tonight.  By a remarkable coincidence, I just yesterday downloaded and installed the requisite Microsoft .Net Framework 2.0!  (I did so in order to run the AllFrames Tagger - which I had hoped would answer the questions I asked here.  Unfortunately, that program was of very little help to me.  That's why I appealed to this mailing list -- with excellent results, thanks to kind folks like you.)

I'm very grateful for your help.  I love learning new things, and this whole digital audio thing has become a PhD project.  I might have dropped out already, had it not been for all the help from more-accomplished enthusiasts.

Best wishes,
John Slane
Dublin OH

Dale Preston <dalepres at msn.com> wrote:        v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} shape {behavior:url(#default#VML);}                     You can try my ID3 Raw Tag Viewer at http://www.dalepreston.com/Blog/2007/02/id3-raw-tag-viewer.html.  It may be just what you?re looking for.  It doesn?t yet support ID3V2.4 but it does support ID3V1, V1.1, V2.2, V2.3.
   
  Dale
   
    From: John Slane [mailto:jaslane64 at yahoo.com] 
 Sent: Sunday, February 18, 2007 12:15 PM
 To: id3v2 at id3.org
 Subject: [ID3 Dev] Need Help Understanding My Own Tags
  
   
  I am not a developer.  I am a user who is very confused about how my id3v2 tags are being created and read by various software packages.  I have used programs like iTunes, MediaMonkey, id3Tag, AllFrames Tagger, and more.  Each of these seems to have its own way of writing metadata to an id3v2 tag.  And each can read SOME of the frames written by the others.  Some of the frames written are STANDARD frames (like YEAR), and others are NONSTANDARD (like COMMENT MUSICMATCH_MOOD).  I am near despair in trying to figure out how one program is going to interpret the frames written by another.
 
 It seems to me that I would benefit greatly if I could simply see what actual frames these programs are writing to.  The id3v2 standard defines 74(?) frames: AENC, APIC, COMM, COMR, ..... etc.  None of the tagger software I mentioned above identifies which of these frames is actually being used.  Therefore, I have no way of directly comparing the way these programs read and write.
 
 Can you suggest any available Windows software that will let me:
 - read the tag of an mp3 file, 
 - see the metadata in ALL the frames, and - most importantly -
 - see the 4-letter code name (AENC, APIC, ...) for each frame?  
 
 With such a tool, I could see what my music software is actually doing to the tags, and figure out how to make the tags from one program work with another.
 
 Freeware would be best, of course.... but I'm getting desperate enough to buy if necessary. ;-)
 
 Any help you can provide would be greatly appreciated.  I have been working on this for weeks, with virtually no progress whatsoever.
 
 If my questions are not within the scope of this mailing list, please forgive my ignorance.
 
 If there is another authority I might more appropriately contact, I would appreciate contact info.
 
 Gratefully,
 John Slane
 Dublin OH
 jaslane64 at yahoo.com
    
    
---------------------------------
  
  Everyone is raving about the all-new Yahoo! Mail beta.
  
  

 
---------------------------------
Don't be flakey. Get Yahoo! Mail for Mobile and 
always stay connected to friends.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070219/14a9cdd1/attachment.html>

From mark at maseurope.net  Mon Feb  5 03:52:43 2007
From: mark at maseurope.net (Mark Smith)
Date: Mon, 5 Feb 2007 11:52:43 +0000
Subject: [ID3 Dev] Tag for MP3 Video Clips
In-Reply-To: <OF82A8D8E7.02E01E66-ON80257279.003A640A-80257279.003B5EC6@northdown.gov.uk>
References: <OF82A8D8E7.02E01E66-ON80257279.003A640A-80257279.003B5EC6@northdown.gov.uk>
Message-ID: <281B454D-6D5F-4318-AFB0-F5B4D8E3376D@maseurope.net>

Others here may well know a lot more than I do, but isn't this the  
kind of thing the GEOB (general encapsulated object) frame is for?

It's described in section 4.1.6 of the 2.3 spec.

Best,

Mark

On 5 Feb 2007, at 10:48, Nick.Rogers at NorthDown.gov.uk wrote:

>
> Good Morning from Open Communities in Ireland.. also at  
> www.audiotours.net where our 101 guide is freely available for  
> download
>
> We are developing an open source approach to building Audio Tours  
> for free use by local communities wishing to build tours of their  
> local community and publish them on the web to encourage people to  
> understand them and visit their area...
>
> We  have suggested using the ID3 picture tagging with great effect  
> for recognition pictures  - 'where am I .. Oh I recognise that  
> building ... etc.. etc'.. or overlaid with an arrow to say 'turn  
> right at the market square'
>
> The success of the project is the ability to distribute the tours  
> and guides without resort to proprietary software.. iPod can play  
> video clips but you are locked into an iPod to play them..
>
> Can anyone in the ID3 community suggest a way or extending the MP3  
> picture tag to play a short open source standard video clip.. we  
> really want to promote open access to people and places around the  
> world - not add to the revenue line for an already successful  
> company..
> www.opencommunities.eu
> Email has been scanned for viruses and unwanted content by the  
> Email Protection Agency


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Sat Feb  3 13:01:41 2007
From: dalepres at msn.com (Dale Preston)
Date: Sat, 3 Feb 2007 15:01:41 -0600
Subject: [ID3 Dev] Opinions
In-Reply-To: <B59E02A9-A334-4897-B414-201C2D14921D@maseurope.net>
References: <B59E02A9-A334-4897-B414-201C2D14921D@maseurope.net>
Message-ID: <BAY111-DAV92A5BF8F7CC1CB721FEF9DD9A0@phx.gbl>

I display the first one and ignore any duplicates.  The only time I check
for un-allowed duplicates in my library is if the client attempts to create
a new frame.  Then, if the frame exists and only one is allowed, an
exception is thrown.  That way, as much as is possible, I don't mess with
bad tags that I didn't create while still trying not to create bad tags of
my own.

HTH,

Dale



-----Original Message-----
From: Mark Smith [mailto:masmit at gmail.com] On Behalf Of Mark Smith
Sent: Saturday, February 03, 2007 11:59 AM
To: id3v2 at id3.org
Subject: [ID3 Dev] Opinions

What does everyone think is the best way to deal with situations  
where you find more than one version of a one-only frame eg. TPE1 in  
a tag?

Just use the first one encountered?

Any advice gratefully recieved.

Best,

Mark Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From hjelmn at mac.com  Wed Feb 21 14:34:27 2007
From: hjelmn at mac.com (Nathan Hjelm)
Date: Wed, 21 Feb 2007 22:34:27 +0000 (UTC)
Subject: [ID3 Dev]  Re: Apple iTunes complicance issues
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <45CFC9B8.3010606@cdtag.com>
Message-ID: <loom.20070221T232724-607@post.gmane.org>

Jud White <jwhite <at> cdtag.com> writes:

> 
> Please correct me if I'm wrong... do you have to purchase a membership 
> to report a bug?
> 
> I have a few things to report:
> 
> 1. In ID3v2.4, non-syncsafe sizes are written to frames (ie, bit 7 is 
> used).  The spec has changed in regards to how frame sizes are written 
> from ID3v2.3 to ID3v2.4.  Also, iTunes does not read frames written with 
> syncsafe sizes correctly.  See http://id3.org/id3v2.4.0-structure, 
> section 4, paragraph 3.  Frame sizes should be written the same way as 
> the total tag size is written in the header in ID3v2.4.  Also, it's easy 
> enough to determine which size-encoding method was used by attempting to 
> seek to the next position and testing for a valid frame signature/end of 
> tag; in other words, it's not too late to correct this behavior.


I have noticed a non-compliance in other frames as well. More specifically,
iTunes does not use synchsafe integers in any of these frames (and probably
others): "APIC", "COMM", "COM ", and "GEOB". It doesn't surprise me Apple has
not fixed the issue as they are very slow at fixing bugs that don't affect a
large number of users.

-Nathan


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Sun Feb 11 18:18:41 2007
From: mark at maseurope.net (Mark Smith)
Date: Mon, 12 Feb 2007 02:18:41 +0000
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <45CFC9B8.3010606@cdtag.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <45CFC9B8.3010606@cdtag.com>
Message-ID: <0575A9AB-6DE9-489B-B21B-ABBE5F502DA7@maseurope.net>

And whilst we're about it, in iTunes 7.0.2, when iTunes writes it's  
users comment to an ID3v2.3 tag, it fails to provide a 'short content  
description' as required in section 4.11 of the spec. Since it  
doesn't offer the user a field in which to provide a description, it  
could perhaps just use "iTunCOMM" or somesuch.

It also writes it's own settings out to COMM frames (with the  
required description, eg. iTunNORM), rather than to PRIV frames,  
which surely would be more appropriate.

Best,

Mark


On 12 Feb 2007, at 01:58, Jud White wrote:

>
> I have a few things to report:
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Mon Feb 12 18:59:15 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Tue, 13 Feb 2007 03:59:15 +0100
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <20070213020543.GA30315@ayup.limey.net>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl>
 <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com>
 <00c101c74ee1$9c86da40$79030105@kendle.com>
 <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com>
 <20070213005834.GA28083@ayup.limey.net>
 <C7A135DE-A7FE-495B-B96C-D295144FBA83@apple.com>
 <20070213020543.GA30315@ayup.limey.net>
Message-ID: <20070213035915313969.c09f80ad@kde.org>

On Mon, 12 Feb 2007 21:05:43 -0500, Ben Bennett wrote:
> 
> Any 2.4 app will do it... unfortunately I don't have a good survey of
> what writes 2.4 vs. 2.3 

Using the examples from TagLib should be fine. 
(http://developer.kde.org/~wheeler/taglib.html)

Compile using the standard UNIX "./configure && make" then go into the 
examples dir and also type "make".  Then there will be something called 
"tagwriter".  This produces a tag that iTunes can't read:

./tagwriter -t 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" 
-a 
"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ" 
test.mp3

iTunes reports no title and the artist as:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZTALB

Note the "TALB" at the end there.  It then hits a null byte and decides 
that the string is done.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Sat Feb 17 19:38:40 2007
From: jwhite at cdtag.com (Jud White)
Date: Sat, 17 Feb 2007 21:38:40 -0600
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <137403647953.20070218053346@tagtuner.com>
References: <45D79568.6040407@cdtag.com> <137403647953.20070218053346@tagtuner.com>
Message-ID: <45D7CA40.1080205@cdtag.com>

Hi Kirill,

Since the tag is 2.3, UTF8 is not an option.

What problem did you encounter?  Was it a spec violation?

Kirill wrote:
> Hello Jud,
>
> I tried to open this file with my software and found a problem with
> UTF-16 encoded description. Maybe other applications have a similar
> problem.
>
> The multiple covers works fine. Try UTF-8 instead.
>
>   



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Sun Feb 18 19:50:13 2007
From: dalepres at msn.com (Dale Preston)
Date: Sun, 18 Feb 2007 21:50:13 -0600
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <45D79568.6040407@cdtag.com>
References: <45D79568.6040407@cdtag.com>
Message-ID: <BAY111-DAV8A4373A3BC7E9F2CB5BA2DD8A0@phx.gbl>

The album art shows in WMP 10 and looks good and decodes properly in my raw
tag viewer.



-----Original Message-----
From: Jud White [mailto:jwhite at cdtag.com] 
Sent: Saturday, February 17, 2007 5:53 PM
To: id3v2 at id3.org
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding

Does anyone see a problem with the tag in this file?  
http://idsharp.com/id3v2/itunes-nopics.mp3  specifically the two APIC 
frames.

IdSharp and UltraID3Lib are both able to read the two pics. Tag&Rename 
shows no pics, The Godfather shows something weird (probably doesn't 
support Unicode), WMP shows the first picture, and iTunes shows no pics.

Thanks



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mitch at honnert.com  Mon Feb 12 12:08:23 2007
From: mitch at honnert.com (Mitchell S. Honnert)
Date: Mon, 12 Feb 2007 15:08:23 -0500
Subject: [ID3 Dev] Apple iTunes complicance issues
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com>
Message-ID: <00c101c74ee1$9c86da40$79030105@kendle.com>

Hello Ernie.  I'm sure most of the members of this list would greatly appreciate any help you could give with resolving the iTunes ID3 compliance issues.  As you can see from the other responses, there are some fairly big problems with the way iTunes implements the ID3 standards.

I have a quick follow-up question.  What is your criteria for "real-world interoperability consequences"?  I think that by definition ID3 developers are a nitpicky lot, so I'm not asking about highly esoteric issues in rarely used frames.  But it seems to me that problems like the ID3v2.4 non-syncsafe size issue and iTunes inexplicable preference for a deprecated ID3 version (ID3 v2.2) would cause interoperability consequences that would warrant attention from Apple.

Again, thanks for your reply.  I hope that the list has found resource that can help address these problems from within.

 - Mitchell S. Honnert

----- Original Message ----- 
  From: Ernest Prabhakar 
  To: id3v2 at id3.org 
  Sent: Sunday, February 11, 2007 8:05 PM
  Subject: Re: [ID3 Dev] Apple iTunes complicance issues


  Have you filed a bug? 


  http://developer.apple.com/bugreporter/bugbestpractices.html


  If you can file a specific bug explaining the concrete, real-world interoperability consequences, I can help escalate it to the iTunes team.


  -- Ernie P.


  On Feb 9, 2007, at 6:46 PM, Dale Preston wrote:


    Apple iTunes suffers from the same problem as Windows Media Player 11 when it comes to ID3V2.2 TYE and ID3V2.3 TYER frames.  In both tag versions iTunes adds a leading and trailing zero byte to the frame.



    And, of course, there?s the issue of iTunes defaulting to the obsolete ID3V2.2 tag in the first place.



    Dale






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070212/f6be4cdc/attachment.html>

From jwhite at cdtag.com  Thu Feb  1 05:50:00 2007
From: jwhite at cdtag.com (Jud White)
Date: Thu, 01 Feb 2007 07:50:00 -0600
Subject: [ID3 Dev] 2.3 - I'm confused
In-Reply-To: <43F1431C-95B3-4758-8243-A08B8B9D9086@maseurope.net>
References: <43F1431C-95B3-4758-8243-A08B8B9D9086@maseurope.net>
Message-ID: <45C1F008.4080905@cdtag.com>

It will come after the flags.  The frame sections do a better job of 
describing the correct layout.

Jud

Mark Smith wrote:
> From the 2.3 spec :
>
> A) "The frame ID is followed by a size descriptor, making a total 
> header size of ten bytes in every frame."
>
> B) "Frames that allow different types of text
>    encoding have a text encoding description byte directly after the
>    frame size. If ISO-8859-1 is used this byte should be $00, if Unicode
>    is used it should be $01."
>
> If B is true, and we put $00 or $01 directly after the framesize, we 
> have an 11 byte header, which seems to contradict A.
>
>
> What do we do?
>
> Best,
>
> Mark Smith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From prabhaka at apple.com  Tue Feb 13 10:55:07 2007
From: prabhaka at apple.com (Ernest Prabhakar)
Date: Tue, 13 Feb 2007 10:55:07 -0800
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <45D204EC.8040101@kde.org>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <20070213025831464946.c391ac65@kde.org> <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com> <45D204EC.8040101@kde.org>
Message-ID: <106099C4-D9BA-4B64-899D-E5CEC3754ACF@apple.com>

Hi Scott,

On Feb 13, 2007, at 10:35 AM, Scott Wheeler wrote:
> From earlier in the thread:
>> I reported both the synch-safe int issue (#4435121, reported 6  
>> Feb, 2006) and [...]

Thanks. The official bug (for future reference) is:

<rdar://problem/3929557> ID3: v2.4 tag lengths not being written as  
syncsafe integers

I've added your comments about tag usage to the bug.  The good news  
is that ID3v4.2 is being used elsewhere at Apple, so that might  
improve its visibility with the iTunes team.

Out of curiosity, do you know if ID3v4.2 is being used in any  
lossless formats?

Thanks,
-- Ernie P.

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Tue Feb 13 11:40:24 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Tue, 13 Feb 2007 20:40:24 +0100
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <45D20BB9.3060108@cdtag.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <20070213025831464946.c391ac65@kde.org> <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com> <45D204EC.8040101@kde.org> <106099C4-D9BA-4B64-899D-E5CEC3754ACF@apple.com> <45D20BB9.3060108@cdtag.com>
Message-ID: <45D21428.4050007@kde.org>

Jud White wrote:
> TTA allows it.
>
> FLAC [...]

FLAC did in its earlier (and still much more widely adopted) version.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jaslane64 at yahoo.com  Mon Feb 19 05:00:48 2007
From: jaslane64 at yahoo.com (John Slane)
Date: Mon, 19 Feb 2007 05:00:48 -0800 (PST)
Subject: [ID3 Dev] Need Help Understanding My Own Tags
In-Reply-To: <45D979DE.1080605@fastmail.fm>
Message-ID: <471354.93252.qm@web53511.mail.yahoo.com>

Thanks, Paul.

I will look at Jaikoz this evening.  Yesterday morning, I was about ready to give up on every learning where tag data was actually going.  After pinging this mailing list, I've now learned a few different tools that each have something new to offer.  I very much appreciate your taking the time to respond.  I hope I'll be able to help out other newbies someday with the tips I'm learning from you folks on this mailing list.

Kind regards,
John Slane
Dublin OH

Paul Taylor <paul_t100 at fastmail.fm> wrote: hi

Jaikoz (www.jaikoz.net) maps all standard  text frames directly to 
fields so you can clearly see what is in each frame. other frames are 
listed in the Unknown Frames column, it doesnt show all the metadata but 
does show the 4 letter code, all ID3 tag versions are supported.

paul

John Slane wrote:
> I am not a developer.  I am a user who is very confused about how my 
> id3v2 tags are being created and read by various software packages.  I 
> have used programs like iTunes, MediaMonkey, id3Tag, AllFrames Tagger, 
> and more.  Each of these seems to have its own way of writing metadata 
> to an id3v2 tag.  And each can read SOME of the frames written by the 
> others.  Some of the frames written are STANDARD frames (like YEAR), 
> and others are NONSTANDARD (like COMMENT MUSICMATCH_MOOD).  I am near 
> despair in trying to figure out how one program is going to interpret 
> the frames written by another.
>
> It seems to me that I would benefit greatly if I could simply see what 
> actual frames these programs are writing to.  The id3v2 standard 
> defines 74(?) frames: AENC, APIC, COMM, COMR, ..... etc.  None of the 
> tagger software I mentioned above identifies which of these frames is 
> actually being used.  Therefore, I have no way of directly comparing 
> the way these programs read and write.
>
> Can you suggest any available Windows software that will let me:
> - read the tag of an mp3 file,
> - see the metadata in ALL the frames, and - most importantly -
> - see the 4-letter code name (AENC, APIC, ...) for each frame? 
>
> With such a tool, I could see what my music software is actually doing 
> to the tags, and figure out how to make the tags from one program work 
> with another.
>
> Freeware would be best, of course.... but I'm getting desperate enough 
> to buy if necessary. ;-)
>
> Any help you can provide would be greatly appreciated.  I have been 
> working on this for weeks, with virtually no progress whatsoever.
>
> If my questions are not within the scope of this mailing list, please 
> forgive my ignorance.
>
> If there is another authority I might more appropriately contact, I 
> would appreciate contact info.
>
> Gratefully,
> John Slane
> Dublin OH
> jaslane64 at yahoo.com
>
> ------------------------------------------------------------------------
> Everyone is raving about the all-new Yahoo! Mail beta. 
>  
>
> ------------------------------------------------------------------------
>
> Internal Virus Database is out-of-date.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.16.5/616 - Release Date: 04/01/2007
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



 
---------------------------------
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070219/29fee2dd/attachment.html>

From dalepres at msn.com  Fri Feb  9 19:51:09 2007
From: dalepres at msn.com (Dale Preston)
Date: Fri, 9 Feb 2007 21:51:09 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <45CD3FC2.6040802@cdtag.com>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <45CD2A93.8000906@coe.neu.edu> <45CD31B8.2010403@cdtag.com> <BAY111-DAV13338E93CAC52BDB5A1D46DD930@phx.gbl> <45CD3FC2.6040802@cdtag.com>
Message-ID: <BAY111-DAV46EC42D41ECB975EBA5D9DD930@phx.gbl>

TYER
The 'Year' frame is a numeric string with a year of the recording. This
frames is always four characters long (until the year 10000).


I guess that's the reason there's a list like this.  Reasonable men disagree
on the interpretation of the specification as written. :)

Dale


-----Original Message-----
From: Jud White [mailto:jwhite at cdtag.com] 
Sent: Friday, February 09, 2007 9:45 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.

4.2.   Text information frames

   The text information frames are the most important frames, containing
   information like artist, album and more. There may only be one text
   information frame of its kind in an tag. If the textstring is
   followed by a termination ($00 (00)) all the following information
   should be ignored and not be displayed. All text frame identifiers
   begin with "T". Only text frame identifiers begin with "T", with the
   exception of the "TXXX" frame. All the text information frames have
   the following format:

     <Header for 'Text information frame', ID: "T000" - "TZZZ",
     excluding "TXXX" described in 4.2.2.>
     Text encoding                $xx
     Information                  <text string according to encoding>

Hope this helps.

Dale Preston wrote:
> If I understand the published specification, the TYER frame is not a
> terminated string which would start with an encoding byte but is, instead,
a
> numeric string.  The spec states specifically "always four characters
long".
> Is this not correct?
>
>
> Dale
>
>
>
> -----Original Message-----
> From: Jud White [mailto:jwhite at cdtag.com] 
> Sent: Friday, February 09, 2007 8:45 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.
>
> Dale,
>
> It's the text encoding byte, and the terminator is optional, at least to 
> the point where the spec says ignore anything that comes after a 
> terminator in a text field.
>
> Brian Mearns wrote:
>   
>> They must be preparing for the Y10K bug.
>>
>> -Brian
>>
>> Dale Preston wrote:
>>     
>>> I have a couple additions for the compliance issues list.
>>>  
>>>
>>> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They 
>>> are 5 bytes long though the standard specifically states they are 
>>> always 4 bytes long.  The leading byte is a zero value.
>>>
>>>  
>>>
>>> Windows Media Player 11 leads with a zero value byte but also appends 
>>> a zero value byte, giving a length of 6 bytes for the ID3V2.3 TYER 
>>> frame.
>>>
>>>  
>>>
>>> I can provide samples if necessary.
>>>
>>>  
>>>
>>>  
>>>
>>> Dale
>>>
>>>  
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
>   



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Sat Feb 17 15:53:12 2007
From: jwhite at cdtag.com (Jud White)
Date: Sat, 17 Feb 2007 17:53:12 -0600
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
Message-ID: <45D79568.6040407@cdtag.com>

Does anyone see a problem with the tag in this file?  
http://idsharp.com/id3v2/itunes-nopics.mp3  specifically the two APIC 
frames.

IdSharp and UltraID3Lib are both able to read the two pics. Tag&Rename 
shows no pics, The Godfather shows something weird (probably doesn't 
support Unicode), WMP shows the first picture, and iTunes shows no pics.

Thanks



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mitch at honnert.com  Mon Feb 12 11:19:44 2007
From: mitch at honnert.com (Mitchell S. Honnert)
Date: Mon, 12 Feb 2007 14:19:44 -0500
Subject: [ID3 Dev] Can text frames be empty
References: <BAY111-DAV134CB1B9DD44B430FF92A7DD920@phx.gbl>
Message-ID: <007701c74eda$c69a5a70$79030105@kendle.com>

>If it is valid, is it still better to remove the empty frame?
Based on my reading of the spec, an "empty" frame should be removed.  If a frame must have data and it doesn't have data, it's invalid, so don't save it.

 - Mitchell S. Honnert
  ----- Original Message ----- 
  From: Dale Preston 
  To: id3v2 at id3.org 
  Sent: Sunday, February 11, 2007 2:28 PM
  Subject: [ID3 Dev] Can text frames be empty


  The description for ID3V2.3 frames says that frames must include at least one byte of data.  How does this rule applied to text frames?  For instance, if track number is not set, is a TRCK frame with the frame data as { 0, 0 }, representing an encoding byte, no string data, and then a null termination byte, considered a valid frame?  

   

  If it is valid, is it still better to remove the empty frame?  For instance, if track number is not set, is it better to leave an existing TRCK frame with 0,0 for the data or is it better to remove the TRCK frame altogether?

   

  Thanks,

   

   

  Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070212/044e2872/attachment.html>

From dalepres at msn.com  Mon Feb 12 19:12:00 2007
From: dalepres at msn.com (Dale Preston)
Date: Mon, 12 Feb 2007 21:12:00 -0600
Subject: [ID3 Dev] Can text frames be empty
In-Reply-To: <20070212043904391622.997e9ae8@kde.org>
References: <BAY111-DAV134CB1B9DD44B430FF92A7DD920@phx.gbl> <20070212043904391622.997e9ae8@kde.org>
Message-ID: <BAY111-DAV116757D788386E894DF1C5DD900@phx.gbl>

I thought that the null termination was explicitly excluded except in list
items such as in V2.4 or where specifically identified such as in frames
like APIC and COMM.

I was surprised to find out from Jud last week that the null termination
could optionally be used.

Dale


-----Original Message-----
From: Scott Wheeler [mailto:wheeler at kde.org] 
Sent: Sunday, February 11, 2007 9:39 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] Can text frames be empty

On Sun, 11 Feb 2007 13:28:45 -0600, Dale Preston wrote:
> The description for ID3V2.3 frames says that frames must include at least
> one byte of data.  How does this rule applied to text frames?  For
instance,
> if track number is not set, is a TRCK frame with the frame data as { 0, 0
},
> representing an encoding byte, no string data, and then a null termination
> byte, considered a valid frame?  

It's valid from the perspective of the general frame definition -- 
specifically, for its purposes, everything after the frame header is 
"data" including the encoding byte.

Also note (as this seems to be something that most people haven't 
caught) that null termination of strings is neither required nor 
recommended in the ID3v2 standards.  In ID3v2.3 it simply implies that 
everything following that should be ignored; in 2.4 it is used as the 
separator for a list of values.  Thus a null terminated string in 2.4 
with a strict parser would imply a list of ( "value", "" ).

> If it is valid, is it still better to remove the empty frame?  For
instance,
> if track number is not set, is it better to leave an existing TRCK frame
> with 0,0 for the data or is it better to remove the TRCK frame altogether?

I think that's up to you.  I'd tend to say culling them while parsing 
the tag is the way to go.

Cheers,

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Sun Feb 11 21:22:41 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Mon, 12 Feb 2007 06:22:41 +0100
Subject: [ID3 Dev] Unicode
In-Reply-To: <20070212062052164478.7e02e88c@kde.org>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>
 <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>
 <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>
 <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
 <45CFF2A1.4050706@cdtag.com>
 <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com>
 <20070212062052164478.7e02e88c@kde.org>
Message-ID: <20070212062241213191.2fb558f0@kde.org>

On Mon, 12 Feb 2007 06:20:52 +0100, Scott Wheeler wrote:
> Mac and Windows

Err, Mac and Linux.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From paul_t100 at fastmail.fm  Mon Feb 19 04:52:32 2007
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 19 Feb 2007 12:52:32 +0000
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <45D79568.6040407@cdtag.com>
References: <45D79568.6040407@cdtag.com>
Message-ID: <45D99D90.7010207@fastmail.fm>

Hi Jud

I tried this with my own jaudiotagger library, although it identified 
there were two APIC frames it failed to decode the description or the 
image properly. But Ive found a problem with library which maybe causing 
problems in other libraries, I think your tag is created correctly. Your 
description is encoded in UTF16 with a byte order mark of FF FE, so that 
each subsequent character is most significant byte first so '?' is FF 01 
'e' is 65 00 and so on. The problem with my library is that I try to 
find the null terminate character because I only want to display upto 
the null terminate character, UTF16 expects two zero bytes 00 00 but 
because your last character is an 'e' its second byte is 00 which I 
incorrectly identify as the first null terminater byte, I then read the 
real null terminate byte as the second byte,and read the second null 
terminate bytes as the first byte of the image data so my image gets 
screwed up. I have now fixed it so that it goes through the buffer in 
increments of 2 when searching for the nul terminator bytes.

You could check my synopsis by changing your text description so that 
the last character requires two bytes and see if it is shown ok.

You could write UTF16 the other way round (FE FF) then the last byte of 
the data will never be zero which is what the jaudiotagger library does 
by default. But sombody did indicate to me this causes prob;ems with 
Windows XP Explorer, although I haven't verified this.

paul

Jud White wrote:

Nina Simone?
> Does anyone see a problem with the tag in this file? 
> http://idsharp.com/id3v2/itunes-nopics.mp3 specifically the two APIC 
> frames.
>
> IdSharp and UltraID3Lib are both able to read the two pics. Tag&Rename 
> shows no pics, The Godfather shows something weird (probably doesn't 
> support Unicode), WMP shows the first picture, and iTunes shows no pics.
>
> Thanks
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From benski at winamp.com  Sun Feb 11 21:39:42 2007
From: benski at winamp.com (Ben Allison)
Date: Mon, 12 Feb 2007 00:39:42 -0500 (EST)
Subject: [ID3 Dev] Unicode
In-Reply-To: <20070212062241213191.2fb558f0@kde.org>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>
    <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>
    <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>
    <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
    <45CFF2A1.4050706@cdtag.com>
    <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com>
    <20070212062052164478.7e02e88c@kde.org>
    <20070212062241213191.2fb558f0@kde.org>
Message-ID: <2553.75.75.86.10.1171258782.squirrel@mail.winamp.com>

Not if you use -fshort-wchar on the Mac.  But your point is well noted. 
sizeof(wchar_t) is not necessarily the same on all platforms.

-ben

> On Mon, 12 Feb 2007 06:20:52 +0100, Scott Wheeler wrote:
>> Mac and Windows
>
> Err, Mac and Linux.
>
> -Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Fri Feb  9 19:23:01 2007
From: dalepres at msn.com (Dale Preston)
Date: Fri, 9 Feb 2007 21:23:01 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <45CD31B8.2010403@cdtag.com>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <45CD2A93.8000906@coe.neu.edu> <45CD31B8.2010403@cdtag.com>
Message-ID: <BAY111-DAV13338E93CAC52BDB5A1D46DD930@phx.gbl>

If I understand the published specification, the TYER frame is not a
terminated string which would start with an encoding byte but is, instead, a
numeric string.  The spec states specifically "always four characters long".
Is this not correct?


Dale



-----Original Message-----
From: Jud White [mailto:jwhite at cdtag.com] 
Sent: Friday, February 09, 2007 8:45 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.

Dale,

It's the text encoding byte, and the terminator is optional, at least to 
the point where the spec says ignore anything that comes after a 
terminator in a text field.

Brian Mearns wrote:
> They must be preparing for the Y10K bug.
>
> -Brian
>
> Dale Preston wrote:
>> I have a couple additions for the compliance issues list.
>>  
>>
>> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They 
>> are 5 bytes long though the standard specifically states they are 
>> always 4 bytes long.  The leading byte is a zero value.
>>
>>  
>>
>> Windows Media Player 11 leads with a zero value byte but also appends 
>> a zero value byte, giving a length of 6 bytes for the ID3V2.3 TYER 
>> frame.
>>
>>  
>>
>> I can provide samples if necessary.
>>
>>  
>>
>>  
>>
>> Dale
>>
>>  
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From fiji at ayup.limey.net  Sun Feb 11 19:59:55 2007
From: fiji at ayup.limey.net (Ben Bennett)
Date: Sun, 11 Feb 2007 22:59:55 -0500
Subject: [ID3 Dev] Unicode
In-Reply-To: <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com> <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl> <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
Message-ID: <20070212035955.GA30167@ayup.limey.net>

On Mon, Feb 12, 2007 at 03:36:58AM +0000, Mark Smith wrote:
> The ID3v2.3 spec only allows for iso-8859-1 (the encoding byte set to  
> 0x00) and UCS-2 which is essentially UTF-16 (encoding byte set to  
> 0x01), so for completeness, we need to add the BOM when writing  
> Unicode strings.

Not just for completeness... for conformance with the spec!  "All
Unicode strings use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993,
UCS-2). Unicode strings must begin with the Unicode BOM ($FF FE or $FE
FF) to identify the byte order." [Section 3.3]

2.4 adds another text encoding description 0x02 which is explicitly
big endian, and the BOM is ommitted.


> There is also UTF-8, which (I may be wrong about this) always has  
> it's multi-byte characters in big-endian order.

UTF-8 does not have endian issues... it is always treated byte by
byte, i.e. it never accessed more than one byte at a time.  But that
is only supported in 2.4.



			-ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Sun Feb 11 19:13:00 2007
From: dalepres at msn.com (Dale Preston)
Date: Sun, 11 Feb 2007 21:13:00 -0600
Subject: [ID3 Dev] Unicode
In-Reply-To: <45CFD1A2.9060502@cdtag.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>
Message-ID: <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>

Can't Unicode use either little-endian or big-endian?

This is an area where I have no experience to draw on and has definitely
been a struggle in my library.

Dale


-----Original Message-----
From: Jud White [mailto:jwhite at cdtag.com] 
Sent: Sunday, February 11, 2007 8:32 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] Unicode

Just tested this.. if you're writing the BOM reversed (should be 0xFF 
0xFE) you'll get oriental characters in iTunes.

Jud White wrote:
> Mark,
>
> This isn't a UCS-2 vs UTF-16 issue.  The differences in these two only 
> occur over 0xffff.  Also it's not an issue with BOM since iTunes can 
> cope without BOM.
>
> I was able to reproduce this behavior by writing a text encoding byte 
> of "Unicode" (0x01) but writing the actual string in UTF-8.  Maybe 
> your implementation is doing something similar?
>
> -Jud
>
>
>
> Mark Smith wrote:
>> I'm getting a bit exasperated with trying to handle Unicode 
>> correctly. In my library, I'm handling all strings as UTF8 
>> internally, but since the 2.3 spec (as I've understood it) only 
>> allows for iso 8559-1 and UCS-2 (for the moment I'm treating UCS-2 as 
>> if it were UTF-16), I'm writing out as UTF-16, where necessary.
>>
>> What I'm finding is that if I write out a TALB frame as "Er?t" (thats 
>> E - r - e with acute accent - t, if your mail client displays 
>> something else) as UTF-16, iTunes and the other two tagging apps I've 
>> checked out display it in an oriental font.
>>
>> So the question is, am I wrong, or are other people just not 
>> bothering to deal with anything but english?
>>
>> Any insights gratefully recieved....
>>
>> Thanks,
>>
>> Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Sun Feb 11 19:36:58 2007
From: mark at maseurope.net (Mark Smith)
Date: Mon, 12 Feb 2007 03:36:58 +0000
Subject: [ID3 Dev] Unicode
In-Reply-To: <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com> <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>
Message-ID: <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>

Dale, I will draw on my tiny and recent study of Unicode:

You're right, it can be either big- or little-endian, so to be sure  
that it is decoded correctly, a byte order marker (BOM) can be  
prepended. This will be two bytes : 0xFF 0xFE for big-endian, or 0xFE  
0xFF for little-endian.

That said, there is UTF-16BE, which is always big-endian, and  
UTF-16LE which is always , you guessed it, little-endian. They don't  
need a BOM, and in fact forbid it.

The ID3v2.3 spec only allows for iso-8859-1 (the encoding byte set to  
0x00) and UCS-2 which is essentially UTF-16 (encoding byte set to  
0x01), so for completeness, we need to add the BOM when writing  
Unicode strings.

There is also UTF-8, which (I may be wrong about this) always has  
it's multi-byte characters in big-endian order.

Wikipedia explains in a great deal more detail.

Best,

Mark

On 12 Feb 2007, at 03:13, Dale Preston wrote:

> Can't Unicode use either little-endian or big-endian?
>
> This is an area where I have no experience to draw on and has  
> definitely
> been a struggle in my library.
>
> Dale
>
>
> -----Original Message-----
> From: Jud White [mailto:jwhite at cdtag.com]
> Sent: Sunday, February 11, 2007 8:32 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] Unicode
>
> Just tested this.. if you're writing the BOM reversed (should be 0xFF
> 0xFE) you'll get oriental characters in iTunes.
>
> Jud White wrote:
>> Mark,
>>
>> This isn't a UCS-2 vs UTF-16 issue.  The differences in these two  
>> only
>> occur over 0xffff.  Also it's not an issue with BOM since iTunes can
>> cope without BOM.
>>
>> I was able to reproduce this behavior by writing a text encoding byte
>> of "Unicode" (0x01) but writing the actual string in UTF-8.  Maybe
>> your implementation is doing something similar?
>>
>> -Jud
>>
>>
>>
>> Mark Smith wrote:
>>> I'm getting a bit exasperated with trying to handle Unicode
>>> correctly. In my library, I'm handling all strings as UTF8
>>> internally, but since the 2.3 spec (as I've understood it) only
>>> allows for iso 8559-1 and UCS-2 (for the moment I'm treating  
>>> UCS-2 as
>>> if it were UTF-16), I'm writing out as UTF-16, where necessary.
>>>
>>> What I'm finding is that if I write out a TALB frame as  
>>> "Er?t" (thats
>>> E - r - e with acute accent - t, if your mail client displays
>>> something else) as UTF-16, iTunes and the other two tagging apps  
>>> I've
>>> checked out display it in an oriental font.
>>>
>>> So the question is, am I wrong, or are other people just not
>>> bothering to deal with anything but english?
>>>
>>> Any insights gratefully recieved....
>>>
>>> Thanks,
>>>
>>> Mark
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>>> For additional commands, e-mail: id3v2-help at id3.org
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Sat Feb 17 18:19:37 2007
From: mark at maseurope.net (Mark Smith)
Date: Sun, 18 Feb 2007 02:19:37 +0000
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <45D7B19F.8080908@cdtag.com>
References: <45D79568.6040407@cdtag.com> <D52989EF-51D1-4E23-A21D-DDD936C86C5E@maseurope.net> <45D7B19F.8080908@cdtag.com>
Message-ID: <83BEC52B-246C-4B87-961F-638A9CF5AE38@maseurope.net>

Just the cover pic, which I think is the second one. I'm not at home  
to check with other software, I'll check more on Monday when I get back.

Best,

Mark

On 18 Feb 2007, at 01:53, Jud White wrote:

> That's interesting, no pics are visible on 7.0.2.16 Windows version.
>
> Does it show both pics or just one?
>
> Mark Smith wrote:
>> iTunes 7.0.2 on this G4 mac shows the cover picture....
>>
>> Best,
>>
>> Mark
>>
>> On 17 Feb 2007, at 23:53, Jud White wrote:
>>
>>> Does anyone see a problem with the tag in this file?  http:// 
>>> idsharp.com/id3v2/itunes-nopics.mp3  specifically the two APIC  
>>> frames.
>>>
>>> IdSharp and UltraID3Lib are both able to read the two pics.  
>>> Tag&Rename shows no pics, The Godfather shows something weird  
>>> (probably doesn't support Unicode), WMP shows the first picture,  
>>> and iTunes shows no pics.
>>>
>>> Thanks
>>>
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>>> For additional commands, e-mail: id3v2-help at id3.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Fri Feb  9 19:55:05 2007
From: dalepres at msn.com (Dale Preston)
Date: Fri, 9 Feb 2007 21:55:05 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <BAY111-DAV46EC42D41ECB975EBA5D9DD930@phx.gbl>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <45CD2A93.8000906@coe.neu.edu> <45CD31B8.2010403@cdtag.com> <BAY111-DAV13338E93CAC52BDB5A1D46DD930@phx.gbl> <45CD3FC2.6040802@cdtag.com> <BAY111-DAV46EC42D41ECB975EBA5D9DD930@phx.gbl>
Message-ID: <BAY111-DAV48CCE99C0DADB22682F06DD930@phx.gbl>

Whoops.  My mistake here.  I apologize.

Four characters is not the same as four bytes.

Back to the drawing board.  Thanks for clearing it up.

Dale

-----Original Message-----
From: Dale Preston [mailto:dalepres at msn.com] 
Sent: Friday, February 09, 2007 9:51 PM
To: id3v2 at id3.org
Subject: RE: [ID3 Dev] An addition for the Compliance Issues list.

TYER
The 'Year' frame is a numeric string with a year of the recording. This
frames is always four characters long (until the year 10000).


I guess that's the reason there's a list like this.  Reasonable men disagree
on the interpretation of the specification as written. :)

Dale


-----Original Message-----
From: Jud White [mailto:jwhite at cdtag.com] 
Sent: Friday, February 09, 2007 9:45 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.

4.2.   Text information frames

   The text information frames are the most important frames, containing
   information like artist, album and more. There may only be one text
   information frame of its kind in an tag. If the textstring is
   followed by a termination ($00 (00)) all the following information
   should be ignored and not be displayed. All text frame identifiers
   begin with "T". Only text frame identifiers begin with "T", with the
   exception of the "TXXX" frame. All the text information frames have
   the following format:

     <Header for 'Text information frame', ID: "T000" - "TZZZ",
     excluding "TXXX" described in 4.2.2.>
     Text encoding                $xx
     Information                  <text string according to encoding>

Hope this helps.

Dale Preston wrote:
> If I understand the published specification, the TYER frame is not a
> terminated string which would start with an encoding byte but is, instead,
a
> numeric string.  The spec states specifically "always four characters
long".
> Is this not correct?
>
>
> Dale
>
>
>
> -----Original Message-----
> From: Jud White [mailto:jwhite at cdtag.com] 
> Sent: Friday, February 09, 2007 8:45 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.
>
> Dale,
>
> It's the text encoding byte, and the terminator is optional, at least to 
> the point where the spec says ignore anything that comes after a 
> terminator in a text field.
>
> Brian Mearns wrote:
>   
>> They must be preparing for the Y10K bug.
>>
>> -Brian
>>
>> Dale Preston wrote:
>>     
>>> I have a couple additions for the compliance issues list.
>>>  
>>>
>>> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They 
>>> are 5 bytes long though the standard specifically states they are 
>>> always 4 bytes long.  The leading byte is a zero value.
>>>
>>>  
>>>
>>> Windows Media Player 11 leads with a zero value byte but also appends 
>>> a zero value byte, giving a length of 6 bytes for the ID3V2.3 TYER 
>>> frame.
>>>
>>>  
>>>
>>> I can provide samples if necessary.
>>>
>>>  
>>>
>>>  
>>>
>>> Dale
>>>
>>>  
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
>   



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Thu Feb  1 06:52:33 2007
From: mark at maseurope.net (Mark Smith)
Date: Thu, 1 Feb 2007 14:52:33 +0000
Subject: [ID3 Dev] 2.3 - I'm confused
In-Reply-To: <45C1F0AE.3030002@yahoo.de>
References: <43F1431C-95B3-4758-8243-A08B8B9D9086@maseurope.net> <45C1F0AE.3030002@yahoo.de>
Message-ID: <A63153A1-1E6F-4BF7-8925-9A6C3F82BBE9@maseurope.net>

Manuel and Jud - thanks. I thought it must be so, but wanted to check.

Best,

Mark

On 1 Feb 2007, at 13:52, Manuel Teuber wrote:

> The Text-Encoding description byte is part of the frame content. it  
> does NOT belong to the header.
>
> Greets
> Manuel Teuber
>
> Mark Smith schrieb:
>> From the 2.3 spec :
>>
>> A) "The frame ID is followed by a size descriptor, making a total  
>> header size of ten bytes in every frame."
>>
>> B) "Frames that allow different types of text
>>    encoding have a text encoding description byte directly after the
>>    frame size. If ISO-8859-1 is used this byte should be $00, if  
>> Unicode
>>    is used it should be $01."
>>
>> If B is true, and we put $00 or $01 directly after the framesize,  
>> we have an 11 byte header, which seems to contradict A.
>>
>>
>> What do we do?
>>
>> Best,
>>
>> Mark Smith
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>
>
>
> 	
> 		
> ___________________________________________________________ Der  
> fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo!  
> Mail: http://mail.yahoo.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From sales at tagtuner.com  Sat Feb 17 21:15:07 2007
From: sales at tagtuner.com (Kirill)
Date: Sun, 18 Feb 2007 07:15:07 +0200
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <45D7CA40.1080205@cdtag.com>
References: <45D79568.6040407@cdtag.com>
 <137403647953.20070218053346@tagtuner.com> <45D7CA40.1080205@cdtag.com>
Message-ID: <85409729125.20070218071507@tagtuner.com>

Hello Jud,

Sunday, February 18, 2007, 5:38:40 AM, you wrote:

JW> What problem did you encounter?  Was it a spec violation?

No content length for Description field + no customers intended to
fill it = improperly handled case for UTF-16 encoding :)

This code was written more than year ago. I just forget that here is
no UTF-8. Anyway, now you have other point to use ISO8859-1 where it
possible or even stay out from filling the Description field until the
real people requests.

-- 
Best regards,
 Kirill                            mailto:sales at tagtuner.com


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From fiji at ayup.limey.net  Mon Feb 12 17:05:41 2007
From: fiji at ayup.limey.net (Ben Bennett)
Date: Mon, 12 Feb 2007 20:05:41 -0500
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <45D10B44.6040001@cdtag.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <45D10B44.6040001@cdtag.com>
Message-ID: <20070213010541.GB28083@ayup.limey.net>

On Mon, Feb 12, 2007 at 06:50:12PM -0600, Jud White wrote:
> I think it's in the wording

Could be... I hope so.

> 1. ID3v2.4 frame sizes written incorrectly (should be syncsafe)
...
> If I don't get a reply to #1 in a couple days I'll open a new one that 
> says iTunes can't read multiple pictures in ID3v2.4. :)

Worse than that... it can't read anything at all if you have a long
frame first.  e.g.:

Tag header
 Frame 1, length 128
 Frame 2, length 10
 Frame 3, length 10

It will overread frame 1 since it is looking for 512 bytes of data,
and include the next 2 frames (header and payload) in the returned
data from frame 1.  So just make a long title for a song in a
non-itunes player.

		    -ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Tue Feb 13 02:44:22 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Tue, 13 Feb 2007 11:44:22 +0100
Subject: [ID3 Dev] Can text frames be empty
In-Reply-To: <BAY111-DAV116757D788386E894DF1C5DD900@phx.gbl>
References: <BAY111-DAV134CB1B9DD44B430FF92A7DD920@phx.gbl> <20070212043904391622.997e9ae8@kde.org> <BAY111-DAV116757D788386E894DF1C5DD900@phx.gbl>
Message-ID: <45D19686.8030808@kde.org>

Dale Preston wrote:
> I thought that the null termination was explicitly excluded except in list
> items such as in V2.4 or where specifically identified such as in frames
> like APIC and COMM.
>
> I was surprised to find out from Jud last week that the null termination
> could optionally be used.
>   

The passage that he quoted was from the 2.3 standard, not 2.4, where 
they are optional but useless.  In 2.4 (in that oh-so-great ID3v2 
fashion) the semantics of null terminated strings changed in a subtle way.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Sat Feb 17 17:53:35 2007
From: jwhite at cdtag.com (Jud White)
Date: Sat, 17 Feb 2007 19:53:35 -0600
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <D52989EF-51D1-4E23-A21D-DDD936C86C5E@maseurope.net>
References: <45D79568.6040407@cdtag.com> <D52989EF-51D1-4E23-A21D-DDD936C86C5E@maseurope.net>
Message-ID: <45D7B19F.8080908@cdtag.com>

That's interesting, no pics are visible on 7.0.2.16 Windows version.

Does it show both pics or just one?

Mark Smith wrote:
> iTunes 7.0.2 on this G4 mac shows the cover picture....
>
> Best,
>
> Mark
>
> On 17 Feb 2007, at 23:53, Jud White wrote:
>
>> Does anyone see a problem with the tag in this file?  
>> http://idsharp.com/id3v2/itunes-nopics.mp3  specifically the two APIC 
>> frames.
>>
>> IdSharp and UltraID3Lib are both able to read the two pics. 
>> Tag&Rename shows no pics, The Godfather shows something weird 
>> (probably doesn't support Unicode), WMP shows the first picture, and 
>> iTunes shows no pics.
>>
>> Thanks
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Sun Feb 11 21:20:52 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Mon, 12 Feb 2007 06:20:52 +0100
Subject: [ID3 Dev] Unicode
In-Reply-To: <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>
 <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>
 <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>
 <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
 <45CFF2A1.4050706@cdtag.com>
 <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com>
Message-ID: <20070212062052164478.7e02e88c@kde.org>

On Mon, 12 Feb 2007 00:04:14 -0500 (EST), Ben Allison wrote:
> And just a note that C compilers treat literal numbers as big endian.
> 
> So if you do this
> wchar_t BOM = 0xFEFF;
> fwrite(&BOM, 1, sizeof(BOM), fp);
> 
> it will "do the right thing" regardless of the platform.

sizeof(wchar_t) == 4 on Mac and Windows, so you would have just written 
two bytes more than you were hoping to.  "unsigned short" is usually a 
safer 16-bit type.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Thu Feb  1 05:17:24 2007
From: mark at maseurope.net (Mark Smith)
Date: Thu, 1 Feb 2007 13:17:24 +0000
Subject: [ID3 Dev] 2.3 - I'm confused
Message-ID: <43F1431C-95B3-4758-8243-A08B8B9D9086@maseurope.net>

 From the 2.3 spec :

A) "The frame ID is followed by a size descriptor, making a total  
header size of ten bytes in every frame."

B) "Frames that allow different types of text
    encoding have a text encoding description byte directly after the
    frame size. If ISO-8859-1 is used this byte should be $00, if  
Unicode
    is used it should be $01."

If B is true, and we put $00 or $01 directly after the framesize, we  
have an 11 byte header, which seems to contradict A.


What do we do?

Best,

Mark Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



From prabhaka at apple.com  Mon Feb 12 17:42:50 2007
From: prabhaka at apple.com (Ernest Prabhakar)
Date: Mon, 12 Feb 2007 17:42:50 -0800
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <20070213005834.GA28083@ayup.limey.net>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net>
Message-ID: <C7A135DE-A7FE-495B-B96C-D295144FBA83@apple.com>

Hi Ben,

On Feb 12, 2007, at 4:58 PM, Ben Bennett wrote:
> I am not sure that any "legal download sites" are shipping mp3s with
> cover art in a 2.4 tag, so requiring that is a bit disingenuous.
> However, being unable to parse a tag correctly if there is a 128 byte
> frame is a pretty serious bug.  Try using one of the other mp3
> programs that supports id3 v2.4 (e.g. Amarok, I am not sure what
> windows or mac alternatives are) and either adding a picture to it, or
> typing in more than 128 characters into a text frame.

I'm not trying to set an unreachable bar, but the more concrete the  
usage scenario, the easier it is to justify the fix.  For example, it  
sounds like the usage:

a) Add an MP3 file to Amarok
b) Add a picture
c) Import it into iTunes

will result in broken image.  Right?

If so, then that's a nice, specific bug impacting iTunes users which  
would generate more attention than merely "iTunes doesn't follow the  
spec."   Especially if you can identify other compliant apps that  
would generate similar problems.

Best,
-- Ernie P.






---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Fri Feb  9 18:46:53 2007
From: dalepres at msn.com (Dale Preston)
Date: Fri, 9 Feb 2007 20:46:53 -0600
Subject: [ID3 Dev] Apple iTunes complicance issues
Message-ID: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl>

Apple iTunes suffers from the same problem as Windows Media Player 11 when
it comes to ID3V2.2 TYE and ID3V2.3 TYER frames.  In both tag versions
iTunes adds a leading and trailing zero byte to the frame.

 

And, of course, there's the issue of iTunes defaulting to the obsolete
ID3V2.2 tag in the first place.

 

Dale

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070209/4ad46758/attachment.html>

From dalepres at msn.com  Fri Feb  9 20:12:49 2007
From: dalepres at msn.com (Dale Preston)
Date: Fri, 9 Feb 2007 22:12:49 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <A5027469-5A38-4356-A51A-A3D8BCD7755F@maseurope.net>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <A5027469-5A38-4356-A51A-A3D8BCD7755F@maseurope.net>
Message-ID: <BAY111-DAV13720B4F14E066536CDF3CDD930@phx.gbl>

Yeah, as Jud said, as well.  That was hard to accept; I've been doing it
wrong for 2 years.  

Dale


-----Original Message-----
From: Mark Smith [mailto:masmit at gmail.com] On Behalf Of Mark Smith
Sent: Friday, February 09, 2007 8:54 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.

The spec also says, with regard to all the text frames excluding TXXX:

4.2 <Header for 'Text information frame', ID: "T000" - "TZZZ",
      excluding "TXXX" described in 4.2.2.>
      Text encoding                $xx
      Information                  <text string according to encoding>

And it doesn't specifically exclude the TYER frame. Nor does it  
exclude the TYER frame from being a null-terminated string. The data  
itself is still just 4 chars, so it seems kind of open to  
interpretation. iTunes 7 does the same (nulls front and back), for  
what it's worth.

On the other hand, maybe MS and Apple are thinking really, really  
long-term, and are leaving space in there for the year 10000 and beyond.

Mark


On 10 Feb 2007, at 02:05, Dale Preston wrote:

> I have a couple additions for the compliance issues list.
>
>
>
> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They  
> are 5 bytes long though the standard specifically states they are  
> always 4 bytes long.  The leading byte is a zero value.
>
>
>
> Windows Media Player 11 leads with a zero value byte but also  
> appends a zero value byte, giving a length of 6 bytes for the  
> ID3V2.3 TYER frame.
>
>
>
> I can provide samples if necessary.
>
>
>
>
>
> Dale
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From support at mp3tag.de  Thu Feb 22 04:57:17 2007
From: support at mp3tag.de (Florian Heidenreich)
Date: Thu, 22 Feb 2007 13:57:17 +0100
Subject: [ID3 Dev]  Re: Apple iTunes complicance issues
In-Reply-To: <loom.20070221T232724-607@post.gmane.org>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <45CFC9B8.3010606@cdtag.com> <loom.20070221T232724-607@post.gmane.org>
Message-ID: <45DD932D.1050004@mp3tag.de>

Nathan Hjelm wrote:
> Jud White <jwhite <at> cdtag.com> writes:
> 
>> Please correct me if I'm wrong... do you have to purchase a membership 
>> to report a bug?
>>
>> I have a few things to report:
>>
>> 1. In ID3v2.4, non-syncsafe sizes are written to frames (ie, bit 7 is 
>> used).  The spec has changed in regards to how frame sizes are written 
>> from ID3v2.3 to ID3v2.4.  Also, iTunes does not read frames written with 
>> syncsafe sizes correctly.  See http://id3.org/id3v2.4.0-structure, 
>> section 4, paragraph 3.  Frame sizes should be written the same way as 
>> the total tag size is written in the header in ID3v2.4.  Also, it's easy 
>> enough to determine which size-encoding method was used by attempting to 
>> seek to the next position and testing for a valid frame signature/end of 
>> tag; in other words, it's not too late to correct this behavior.
> 
> 
> I have noticed a non-compliance in other frames as well. More specifically,
> iTunes does not use synchsafe integers in any of these frames (and probably
> others): "APIC", "COMM", "COM ", and "GEOB". It doesn't surprise me Apple has
> not fixed the issue as they are very slow at fixing bugs that don't affect a
> large number of users.

I've also noticed the bugs in iTunes (as many users of my tagger did).

Another funny thing is the the way iTunes stores the flag for marking 
tracks as a part of a gapless album: there is a COMM frame with the 
description iTunPGAP and the content of the frame must be
0x31 0x00 0x00

If the last 0x00 is omitted, iTunes won't recognize the file as part of 
a gapless album.

Kind regards,
Florian

-- 
Mp3tag - the universal Tag editor
http://www.mp3tag.de/en/

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Mon Feb 12 16:50:12 2007
From: jwhite at cdtag.com (Jud White)
Date: Mon, 12 Feb 2007 18:50:12 -0600
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com>
Message-ID: <45D10B44.6040001@cdtag.com>

Apple replied to one of the bugs I opened last night.  I reported the 
syncsafe problem and the non-Latin1 APIC problem; they replied to the 
text encoding problem, just asking for a sample file but it's a start.

I think it's in the wording
1. ID3v2.4 frame sizes written incorrectly (should be syncsafe)
2. ID3v2: "APIC" frame with non-Latin1 encoding is not read by iTunes

If I don't get a reply to #1 in a couple days I'll open a new one that 
says iTunes can't read multiple pictures in ID3v2.4. :)

Ernest Prabhakar wrote:
> Hi Mitchell,
>
> On Feb 12, 2007, at 12:08 PM, Mitchell S. Honnert wrote:
>> Hello Ernie.  I'm sure most of the members of this list would greatly 
>> appreciate any help you could give with resolving the iTunes ID3 
>> compliance issues.  As you can see from the other responses, there 
>> are some fairly big problems with the way iTunes implements the ID3 
>> standards.
>>  
>> I have a quick follow-up question.  What is your criteria 
>> for "real-world interoperability consequences"?
>
> Thanks for your query, and I can appreciate your concern.  The sort of 
> data I'm looking for is "When I obtain an MP3 track from this legal 
> download site, it contains this information which is *not* usable from 
> iTunes."
>
> That is, while I realize you live in a world where spec conformance is 
> its own reward, I need to be able to provide concrete customer usage 
> problems to motivate change.
>
> Does that make sense?
>
> -- Ernie P.
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Sun Feb 11 19:39:04 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Mon, 12 Feb 2007 04:39:04 +0100
Subject: [ID3 Dev] Can text frames be empty
In-Reply-To: <BAY111-DAV134CB1B9DD44B430FF92A7DD920@phx.gbl>
References: <BAY111-DAV134CB1B9DD44B430FF92A7DD920@phx.gbl>
Message-ID: <20070212043904391622.997e9ae8@kde.org>

On Sun, 11 Feb 2007 13:28:45 -0600, Dale Preston wrote:
> The description for ID3V2.3 frames says that frames must include at least
> one byte of data.  How does this rule applied to text frames?  For instance,
> if track number is not set, is a TRCK frame with the frame data as { 0, 0 },
> representing an encoding byte, no string data, and then a null termination
> byte, considered a valid frame?  

It's valid from the perspective of the general frame definition -- 
specifically, for its purposes, everything after the frame header is 
"data" including the encoding byte.

Also note (as this seems to be something that most people haven't 
caught) that null termination of strings is neither required nor 
recommended in the ID3v2 standards.  In ID3v2.3 it simply implies that 
everything following that should be ignored; in 2.4 it is used as the 
separator for a list of values.  Thus a null terminated string in 2.4 
with a strict parser would imply a list of ( "value", "" ).

> If it is valid, is it still better to remove the empty frame?  For instance,
> if track number is not set, is it better to leave an existing TRCK frame
> with 0,0 for the data or is it better to remove the TRCK frame altogether?

I think that's up to you.  I'd tend to say culling them while parsing 
the tag is the way to go.

Cheers,

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Sun Feb 11 10:15:25 2007
From: mark at maseurope.net (Mark Smith)
Date: Sun, 11 Feb 2007 18:15:25 +0000
Subject: [ID3 Dev] Unicode
Message-ID: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>

I'm getting a bit exasperated with trying to handle Unicode  
correctly. In my library, I'm handling all strings as UTF8  
internally, but since the 2.3 spec (as I've understood it) only  
allows for iso 8559-1 and UCS-2 (for the moment I'm treating UCS-2 as  
if it were UTF-16), I'm writing out as UTF-16, where necessary.

What I'm finding is that if I write out a TALB frame as "Er?t" (thats  
E - r - e with acute accent - t, if your mail client displays  
something else) as UTF-16, iTunes and the other two tagging apps I've  
checked out display it in an oriental font.

So the question is, am I wrong, or are other people just not  
bothering to deal with anything but english?

Any insights gratefully recieved....

Thanks,

Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Mon Feb 12 04:33:48 2007
From: mark at maseurope.net (Mark Smith)
Date: Mon, 12 Feb 2007 12:33:48 +0000
Subject: [ID3 Dev] Unicode
In-Reply-To: <45CFF2A1.4050706@cdtag.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com> <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl> <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net> <45CFF2A1.4050706@cdtag.com>
Message-ID: <08572C7E-6AF7-4B86-8696-7F999D0971FF@maseurope.net>

Judd, thanks for putting me straight on this - I had this the wrong  
way round, as you noted, hence the trouble...

Thanks again,

Best,

Mark


On 12 Feb 2007, at 04:52, Jud White wrote:

> Mark,
>
> This is backwards.  Little endian BOM is FF FE and big endian BOM  
> is FE FF
>
> Mark Smith wrote:
>> 0xFF 0xFE for big-endian, or 0xFE 0xFF for little-endian.
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Tue Feb 13 10:35:24 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Tue, 13 Feb 2007 19:35:24 +0100
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <20070213025831464946.c391ac65@kde.org> <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com>
Message-ID: <45D204EC.8040101@kde.org>

Ernest Prabhakar wrote:

Hi Ernie --

> Thanks.  Can you perhaps find the Apple bug number, so I can track it?

 From earlier in the thread:

> I reported both the synch-safe int issue (#4435121, reported 6 Feb, 2006) and [...]
>   

> Also, if you can identify anything other than Amarok that has this 
> problem interoperating with iTunes, it would help raise the priority.  
> It doesn't have to run on the Mac, though it should at least run on 
> Windows (since those are the two platforms we worry most about). 

I suspect pretty much anything using ID3v2.4.  Amarok uses TagLib as do 
a handful of OS X and Windows applications.  In a quick search, these 
two came up:

http://sbooth.org/Tag/
http://www.fataltourist.com/iripdb/

Freshmeat lists 25 projects that require TagLib; I'm aware of several as 
well that aren't listed there.  There's also one of the semi-major 
portable MP3 players that I'm pretty sure uses it.

For us Linux nerds (I tend to split my time between Linux and OS X) the 
most problematic incarnation of the bugs in the Apple implementation are 
in using iPods.  Linux based players have had cover fetching features 
for a good while longer than iTunes (several years) and iPods can't 
handle properly written cover images.

Cheers,

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Sun Feb 11 20:34:00 2007
From: jwhite at cdtag.com (Jud White)
Date: Sun, 11 Feb 2007 22:34:00 -0600
Subject: [ID3 Dev] Unicode
In-Reply-To: <AF534225-043E-4C91-8ACB-8497C259A5C3@maseurope.net>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com> <AF534225-043E-4C91-8ACB-8497C259A5C3@maseurope.net>
Message-ID: <45CFEE38.6040302@cdtag.com>

Mark,

What you have is Big Endian.  The year should be 01 FF FE 31 00 39 00 37 
00 35 00 (null terminator excluded)

-Jud

Mark Smith wrote:
> Judd, thanks for taking the trouble to look at this.
>
> This is the content of the TYER frame (excluding the frame header) 
> that I'm testing with:
>
> 0x01 0xFF 0xFE 0x00 0x31 0x00 0x39 0x00 0x37 0x00 0x35 0x00 0x00
>
> which is what I think it should be...(1975 is the year), but this 
> shows up as 16665 in iTunes (I stopped testing other frames that 
> resulted in iTunes renaming files and folders).
>
> I'm working on Mac OS X, which may be a factor.
>
> Thanks, again.
>
> Best,
>
> Mark
>
> On 12 Feb 2007, at 02:32, Jud White wrote:
>
>> Just tested this.. if you're writing the BOM reversed (should be 0xFF 
>> 0xFE) you'll get oriental characters in iTunes.
>>
>> Jud White wrote:
>>> Mark,
>>>
>>> This isn't a UCS-2 vs UTF-16 issue.  The differences in these two 
>>> only occur over 0xffff.  Also it's not an issue with BOM since 
>>> iTunes can cope without BOM.
>>>
>>> I was able to reproduce this behavior by writing a text encoding 
>>> byte of "Unicode" (0x01) but writing the actual string in UTF-8.  
>>> Maybe your implementation is doing something similar?
>>>
>>> -Jud
>>>
>>>
>>>
>>> Mark Smith wrote:
>>>> I'm getting a bit exasperated with trying to handle Unicode 
>>>> correctly. In my library, I'm handling all strings as UTF8 
>>>> internally, but since the 2.3 spec (as I've understood it) only 
>>>> allows for iso 8559-1 and UCS-2 (for the moment I'm treating UCS-2 
>>>> as if it were UTF-16), I'm writing out as UTF-16, where necessary.
>>>>
>>>> What I'm finding is that if I write out a TALB frame as "Er?t" 
>>>> (thats E - r - e with acute accent - t, if your mail client 
>>>> displays something else) as UTF-16, iTunes and the other two 
>>>> tagging apps I've checked out display it in an oriental font.
>>>>
>>>> So the question is, am I wrong, or are other people just not 
>>>> bothering to deal with anything but english?
>>>>
>>>> Any insights gratefully recieved....
>>>>
>>>> Thanks,
>>>>
>>>> Mark
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>>>> For additional commands, e-mail: id3v2-help at id3.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>>> For additional commands, e-mail: id3v2-help at id3.org
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From paul_t100 at fastmail.fm  Mon Feb 19 02:20:14 2007
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Mon, 19 Feb 2007 10:20:14 +0000
Subject: [ID3 Dev] Need Help Understanding My Own Tags
In-Reply-To: <491749.19627.qm@web53503.mail.yahoo.com>
References: <491749.19627.qm@web53503.mail.yahoo.com>
Message-ID: <45D979DE.1080605@fastmail.fm>

hi

Jaikoz (www.jaikoz.net) maps all standard  text frames directly to 
fields so you can clearly see what is in each frame. other frames are 
listed in the Unknown Frames column, it doesnt show all the metadata but 
does show the 4 letter code, all ID3 tag versions are supported.

paul

John Slane wrote:
> I am not a developer.  I am a user who is very confused about how my 
> id3v2 tags are being created and read by various software packages.  I 
> have used programs like iTunes, MediaMonkey, id3Tag, AllFrames Tagger, 
> and more.  Each of these seems to have its own way of writing metadata 
> to an id3v2 tag.  And each can read SOME of the frames written by the 
> others.  Some of the frames written are STANDARD frames (like YEAR), 
> and others are NONSTANDARD (like COMMENT MUSICMATCH_MOOD).  I am near 
> despair in trying to figure out how one program is going to interpret 
> the frames written by another.
>
> It seems to me that I would benefit greatly if I could simply see what 
> actual frames these programs are writing to.  The id3v2 standard 
> defines 74(?) frames: AENC, APIC, COMM, COMR, ..... etc.  None of the 
> tagger software I mentioned above identifies which of these frames is 
> actually being used.  Therefore, I have no way of directly comparing 
> the way these programs read and write.
>
> Can you suggest any available Windows software that will let me:
> - read the tag of an mp3 file,
> - see the metadata in ALL the frames, and - most importantly -
> - see the 4-letter code name (AENC, APIC, ...) for each frame? 
>
> With such a tool, I could see what my music software is actually doing 
> to the tags, and figure out how to make the tags from one program work 
> with another.
>
> Freeware would be best, of course.... but I'm getting desperate enough 
> to buy if necessary. ;-)
>
> Any help you can provide would be greatly appreciated.  I have been 
> working on this for weeks, with virtually no progress whatsoever.
>
> If my questions are not within the scope of this mailing list, please 
> forgive my ignorance.
>
> If there is another authority I might more appropriately contact, I 
> would appreciate contact info.
>
> Gratefully,
> John Slane
> Dublin OH
> jaslane64 at yahoo.com
>
> ------------------------------------------------------------------------
> Everyone is raving about the all-new Yahoo! Mail beta. 
> <http://us.rd.yahoo.com/evt=42297/*http://advision.webevents.yahoo.com/mailbeta> 
>
> ------------------------------------------------------------------------
>
> Internal Virus Database is out-of-date.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.16.5/616 - Release Date: 04/01/2007
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Sun Feb 11 20:34:51 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Mon, 12 Feb 2007 05:34:51 +0100
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <45CFC9B8.3010606@cdtag.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl>
 <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com>
 <45CFC9B8.3010606@cdtag.com>
Message-ID: <20070212053451723791.ede52053@kde.org>

On Sun, 11 Feb 2007 19:58:16 -0600, Jud White wrote:
> Please correct me if I'm wrong... do you have to purchase a 
> membership to report a bug?

No, you don't.  You just have to go through the registration process.

> 3. APIC frames [...]

4. Numeric genre handling is incorrect for 2.4.  In 2.3 a numeric genre 
was specified as "(15)"; in 2.4 it is simply "15".  iTunes treats the 
2.4 version as a normal string, so compliant 2.4 numerical tags show up 
in iTunes just as numbers.  Similarly, it writes the 2.3 version into 
2.4 tags.

I reported both the synch-safe int issue (#4435121, reported 6 Feb, 
2006) and the genre issue (#4912611, reported 7 Jan, 2007) in Apple's 
bug tracker.  Detailed descriptions are in both reports.  I never heard 
anything back on either.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Mon Feb 12 18:54:04 2007
From: dalepres at msn.com (Dale Preston)
Date: Mon, 12 Feb 2007 20:54:04 -0600
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <20070213005834.GA28083@ayup.limey.net>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net>
Message-ID: <BAY111-DAV1134BEF8DD618B0BE0C825DD900@phx.gbl>



-----Original Message-----
From: Ben Bennett [mailto:fiji at ayup.limey.net] 
Sent: Monday, February 12, 2007 6:59 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] Apple iTunes complicance issues

<snip>
[QUOTE]
Note, I am not sure how iTunes can actually fix this.  Given that they
have been writing horribly broken frames, they have to be able to read
them or people will scream.  I think the only hope is for us to rev
2.4.0 to 2.4.1, but keep the spec essentially the same but really
LOUDLY note this mandatory change.  That way everyone can trust a
2.4.1 tag will not have sync errors in the frames, and it will give
iTunes a safe recovery path.  (And yes... I know you can apply
heuristics to catch the error most of the time, but that is gross).
[ENDQUOTE]
------------------------------------------------------------------------

Catching the error may be gross but to create a new minor version is
something that imposes the price of Apples failure to follow the standard on
to every developer of every application forever while Apple would only have
to catch the error once.  Hopefully they will either fix it for the sake of
interoperability or just settle on V2.3 and drop support for V2.4 and V2.2.

Too bad there can't be some level of accuracy in implementation built into
the right to use the standard or at least to identify an application's tags
as ID3.

Dale

			    -ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From bmearns at coe.neu.edu  Fri Feb  9 18:14:43 2007
From: bmearns at coe.neu.edu (Brian Mearns)
Date: Fri, 09 Feb 2007 21:14:43 -0500
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl>
Message-ID: <45CD2A93.8000906@coe.neu.edu>

They must be preparing for the Y10K bug.

-Brian

Dale Preston wrote:
> I have a couple additions for the compliance issues list. 
> 
>  
> 
> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They are 
> 5 bytes long though the standard specifically states they are always 4 
> bytes long.  The leading byte is a zero value.
> 
>  
> 
> Windows Media Player 11 leads with a zero value byte but also appends a 
> zero value byte, giving a length of 6 bytes for the ID3V2.3 TYER frame.
> 
>  
> 
> I can provide samples if necessary.
> 
>  
> 
>  
> 
> Dale
> 
>  
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From fiji at ayup.limey.net  Mon Feb 12 18:05:43 2007
From: fiji at ayup.limey.net (Ben Bennett)
Date: Mon, 12 Feb 2007 21:05:43 -0500
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <C7A135DE-A7FE-495B-B96C-D295144FBA83@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <C7A135DE-A7FE-495B-B96C-D295144FBA83@apple.com>
Message-ID: <20070213020543.GA30315@ayup.limey.net>

On Mon, Feb 12, 2007 at 05:42:50PM -0800, Ernest Prabhakar wrote:
> 
> I'm not trying to set an unreachable bar, but the more concrete the  
> usage scenario, the easier it is to justify the fix.  For example, it  
> sounds like the usage:
> 
> a) Add an MP3 file to Amarok
> b) Add a picture
> c) Import it into iTunes
> 
> will result in broken image.  Right?

Perhaps.  It is probably safer to add a long comment as well as an
image.  Or if possible, add two images.  But really, any frame (text
or image) that is larger than 127 will cause a problem.

The catch is that since iTunes misreads tag length as larger than it
ought to be, a trailing image will not cause problems sine it will hit
the end of the frame when looking for more tag data and stop.  Oh, and
an image in the middle of the tag will look correct, since the image
format will tell it when the data has ended (for jpg anyway).  It is
just the stuff following that frame that will be broken, so in a way
just having two long text frames makes it a little easier to see what
the problem is.

Do you want me to find a good example of a file with a broken tag?

> If so, then that's a nice, specific bug impacting iTunes users which  
> would generate more attention than merely "iTunes doesn't follow the  
> spec."

Ah, I see.  Sorry for getting a bit testy with you then.

> Especially if you can identify other compliant apps that would
> generate similar problems.

Any 2.4 app will do it... unfortunately I don't have a good survey of
what writes 2.4 vs. 2.3 :-(  I am sure that someone on this list will
be able to point to an OSX 2.4 tag app.  Although if it uses quicktime
to write tags, that may fall victim to the same syncsafe issue (I am
not sure if the Quicktime library is the issue, or if iTunes handles
it itself).

I know Amarok does... in fact it will only write 2.4, it will read 2.3
and 2.4 though.

		    -ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Fri Feb  9 18:45:12 2007
From: jwhite at cdtag.com (Jud White)
Date: Fri, 09 Feb 2007 20:45:12 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <45CD2A93.8000906@coe.neu.edu>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <45CD2A93.8000906@coe.neu.edu>
Message-ID: <45CD31B8.2010403@cdtag.com>

Dale,

It's the text encoding byte, and the terminator is optional, at least to 
the point where the spec says ignore anything that comes after a 
terminator in a text field.

Brian Mearns wrote:
> They must be preparing for the Y10K bug.
>
> -Brian
>
> Dale Preston wrote:
>> I have a couple additions for the compliance issues list.
>>  
>>
>> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They 
>> are 5 bytes long though the standard specifically states they are 
>> always 4 bytes long.  The leading byte is a zero value.
>>
>>  
>>
>> Windows Media Player 11 leads with a zero value byte but also appends 
>> a zero value byte, giving a length of 6 bytes for the ID3V2.3 TYER 
>> frame.
>>
>>  
>>
>> I can provide samples if necessary.
>>
>>  
>>
>>  
>>
>> Dale
>>
>>  
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Fri Feb  9 18:53:39 2007
From: mark at maseurope.net (Mark Smith)
Date: Sat, 10 Feb 2007 02:53:39 +0000
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl>
Message-ID: <A5027469-5A38-4356-A51A-A3D8BCD7755F@maseurope.net>

The spec also says, with regard to all the text frames excluding TXXX:

4.2 <Header for 'Text information frame', ID: "T000" - "TZZZ",
      excluding "TXXX" described in 4.2.2.>
      Text encoding                $xx
      Information                  <text string according to encoding>

And it doesn't specifically exclude the TYER frame. Nor does it  
exclude the TYER frame from being a null-terminated string. The data  
itself is still just 4 chars, so it seems kind of open to  
interpretation. iTunes 7 does the same (nulls front and back), for  
what it's worth.

On the other hand, maybe MS and Apple are thinking really, really  
long-term, and are leaving space in there for the year 10000 and beyond.

Mark


On 10 Feb 2007, at 02:05, Dale Preston wrote:

> I have a couple additions for the compliance issues list.
>
>
>
> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They  
> are 5 bytes long though the standard specifically states they are  
> always 4 bytes long.  The leading byte is a zero value.
>
>
>
> Windows Media Player 11 leads with a zero value byte but also  
> appends a zero value byte, giving a length of 6 bytes for the  
> ID3V2.3 TYER frame.
>
>
>
> I can provide samples if necessary.
>
>
>
>
>
> Dale
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Sun Feb 11 19:24:14 2007
From: mark at maseurope.net (Mark Smith)
Date: Mon, 12 Feb 2007 03:24:14 +0000
Subject: [ID3 Dev] Unicode
In-Reply-To: <45CFD1A2.9060502@cdtag.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>
Message-ID: <AF534225-043E-4C91-8ACB-8497C259A5C3@maseurope.net>

Judd, thanks for taking the trouble to look at this.

This is the content of the TYER frame (excluding the frame header)  
that I'm testing with:

0x01 0xFF 0xFE 0x00 0x31 0x00 0x39 0x00 0x37 0x00 0x35 0x00 0x00

which is what I think it should be...(1975 is the year), but this  
shows up as 16665 in iTunes (I stopped testing other frames that  
resulted in iTunes renaming files and folders).

I'm working on Mac OS X, which may be a factor.

Thanks, again.

Best,

Mark

On 12 Feb 2007, at 02:32, Jud White wrote:

> Just tested this.. if you're writing the BOM reversed (should be  
> 0xFF 0xFE) you'll get oriental characters in iTunes.
>
> Jud White wrote:
>> Mark,
>>
>> This isn't a UCS-2 vs UTF-16 issue.  The differences in these two  
>> only occur over 0xffff.  Also it's not an issue with BOM since  
>> iTunes can cope without BOM.
>>
>> I was able to reproduce this behavior by writing a text encoding  
>> byte of "Unicode" (0x01) but writing the actual string in UTF-8.   
>> Maybe your implementation is doing something similar?
>>
>> -Jud
>>
>>
>>
>> Mark Smith wrote:
>>> I'm getting a bit exasperated with trying to handle Unicode  
>>> correctly. In my library, I'm handling all strings as UTF8  
>>> internally, but since the 2.3 spec (as I've understood it) only  
>>> allows for iso 8559-1 and UCS-2 (for the moment I'm treating  
>>> UCS-2 as if it were UTF-16), I'm writing out as UTF-16, where  
>>> necessary.
>>>
>>> What I'm finding is that if I write out a TALB frame as  
>>> "Er?t" (thats E - r - e with acute accent - t, if your mail  
>>> client displays something else) as UTF-16, iTunes and the other  
>>> two tagging apps I've checked out display it in an oriental font.
>>>
>>> So the question is, am I wrong, or are other people just not  
>>> bothering to deal with anything but english?
>>>
>>> Any insights gratefully recieved....
>>>
>>> Thanks,
>>>
>>> Mark
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>>> For additional commands, e-mail: id3v2-help at id3.org
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From benski at winamp.com  Tue Feb 13 10:07:39 2007
From: benski at winamp.com (Ben Allison)
Date: Tue, 13 Feb 2007 13:07:39 -0500
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <20070213025831464946.c391ac65@kde.org> <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com>
Message-ID: <45D1FE6B.701@winamp.com>

Ernest Prabhakar wrote:
>
> Also, if you can identify anything other than Amarok that has this 
> problem interoperating with iTunes, it would help raise the priority.  
> It doesn't have to run on the Mac, though it should at least run on 
> Windows (since those are the two platforms we worry most about).
Winamp 5.33 (Due out very soon but currently in public beta) will read 
id3v2.4 tags but choke on the non-syncsafe sizes.  However, it has some 
heuristics, so you'll have to make just the right frame size to get it 
to work.  If the high bit in any byte isn't set, you have a good chance 
of fooling the heuristics, so a frame size of 512 should do the trick.  
Winamp, however, won't write a new id3v2.4 tag, only modify an existing 
one (it writes new tags as 2.3)



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From teuber01_zigr at yahoo.de  Thu Feb  1 05:52:46 2007
From: teuber01_zigr at yahoo.de (Manuel Teuber)
Date: Thu, 01 Feb 2007 14:52:46 +0100
Subject: [ID3 Dev] 2.3 - I'm confused
In-Reply-To: <43F1431C-95B3-4758-8243-A08B8B9D9086@maseurope.net>
References: <43F1431C-95B3-4758-8243-A08B8B9D9086@maseurope.net>
Message-ID: <45C1F0AE.3030002@yahoo.de>

The Text-Encoding description byte is part of the frame content. it does 
NOT belong to the header.

Greets
Manuel Teuber

Mark Smith schrieb:
> From the 2.3 spec :
>
> A) "The frame ID is followed by a size descriptor, making a total 
> header size of ten bytes in every frame."
>
> B) "Frames that allow different types of text
>    encoding have a text encoding description byte directly after the
>    frame size. If ISO-8859-1 is used this byte should be $00, if Unicode
>    is used it should be $01."
>
> If B is true, and we put $00 or $01 directly after the framesize, we 
> have an 11 byte header, which seems to contradict A.
>
>
> What do we do?
>
> Best,
>
> Mark Smith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>



	
		
___________________________________________________________ 
Der fr?he Vogel f?ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Sat Feb 10 02:30:26 2007
From: mark at maseurope.net (Mark Smith)
Date: Sat, 10 Feb 2007 10:30:26 +0000
Subject: [ID3 Dev] An addition for the Compliance Issues list.
In-Reply-To: <BAY111-DAV13720B4F14E066536CDF3CDD930@phx.gbl>
References: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl> <A5027469-5A38-4356-A51A-A3D8BCD7755F@maseurope.net> <BAY111-DAV13720B4F14E066536CDF3CDD930@phx.gbl>
Message-ID: <9AF2FC64-2075-4535-9A47-CBFB1C7CC3C2@maseurope.net>

Well,  thanks for bringing it up. I'm just in the process of writing  
a tagging library for a high-level scripting language called  
Revolution (formerly metaCard), and it's good to test my  
understanding of the specs when questions arise and discussion  
happens....


Best,

Mark

On 10 Feb 2007, at 04:12, Dale Preston wrote:

> Yeah, as Jud said, as well.  That was hard to accept; I've been  
> doing it
> wrong for 2 years.
>
> Dale
>
>
> -----Original Message-----
> From: Mark Smith [mailto:masmit at gmail.com] On Behalf Of Mark Smith
> Sent: Friday, February 09, 2007 8:54 PM
> To: id3v2 at id3.org
> Subject: Re: [ID3 Dev] An addition for the Compliance Issues list.
>
> The spec also says, with regard to all the text frames excluding TXXX:
>
> 4.2 <Header for 'Text information frame', ID: "T000" - "TZZZ",
>       excluding "TXXX" described in 4.2.2.>
>       Text encoding                $xx
>       Information                  <text string according to encoding>
>
> And it doesn't specifically exclude the TYER frame. Nor does it
> exclude the TYER frame from being a null-terminated string. The data
> itself is still just 4 chars, so it seems kind of open to
> interpretation. iTunes 7 does the same (nulls front and back), for
> what it's worth.
>
> On the other hand, maybe MS and Apple are thinking really, really
> long-term, and are leaving space in there for the year 10000 and  
> beyond.
>
> Mark
>
>
> On 10 Feb 2007, at 02:05, Dale Preston wrote:
>
>> I have a couple additions for the compliance issues list.
>>
>>
>>
>> Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They
>> are 5 bytes long though the standard specifically states they are
>> always 4 bytes long.  The leading byte is a zero value.
>>
>>
>>
>> Windows Media Player 11 leads with a zero value byte but also
>> appends a zero value byte, giving a length of 6 bytes for the
>> ID3V2.3 TYER frame.
>>
>>
>>
>> I can provide samples if necessary.
>>
>>
>>
>>
>>
>> Dale
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From rmanson at gracenote.com  Mon Feb 12 12:22:02 2007
From: rmanson at gracenote.com (Robert Manson)
Date: Mon, 12 Feb 2007 12:22:02 -0800
Subject: [ID3 Dev] Unicode
In-Reply-To: <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>    <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>    <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>    <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>    <45CFF2A1.4050706@cdtag.com> <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com>
Message-ID: <119461A3B1C2A847BABA421E6EB62CEA183F57@EMAIL1.gracenote.gracenote.com>

Hi Ben,
With regards to your comment:
>>it will also do the right thing, regardless of platform.
If you're intent here was to indicate that the code snippets you posted
are portable I'm afraid you are mistaken.

The wchar_t type is not portable instead you should use ui16_t for
UTF-16 (or UCS-2). (whar_t is 16 bits on windows but 32 bits on linux,
and is not guaranteed to be more than 7 bits) Also note that ui16_t is
guaranteed to be *at least* 2 bytes so you should not use sizeof(),
instead you should use the number 2.

Also, while it is true that literal values are big endian, the byte
ordering of the lval is system dependent so the code snippets will
produce different results depending on whether or not the platform is
big or little endian.

-Rob

-----Original Message-----
From: Ben Allison [mailto:benski at winamp.com] 
Sent: Sunday, February 11, 2007 9:04 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] Unicode

And just a note that C compilers treat literal numbers as big endian.

So if you do this
wchar_t BOM = 0xFEFF;
fwrite(&BOM, 1, sizeof(BOM), fp);

it will "do the right thing" regardless of the platform.

similiarly, if you do this:
wchar_t BOM;
fread(&BOM, 1, sizeof(BOM), fp);
if (BOM == 0xFEFF) // don't switch endian
{
}
else // switch endian
{
}

it will also do the right thing, regardless of platform.

> Mark,
>
> This is backwards.  Little endian BOM is FF FE and big endian BOM is
FE FF
>
> Mark Smith wrote:
>> 0xFF 0xFE for big-endian, or 0xFE 0xFF for little-endian.
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Wed Feb 14 06:07:41 2007
From: mark at maseurope.net (Mark Smith)
Date: Wed, 14 Feb 2007 14:07:41 +0000
Subject: [ID3 Dev] Minimum length of an ID3v23 tag
In-Reply-To: <45D2E626.7000009@fastmail.fm>
References: <45D2E626.7000009@fastmail.fm>
Message-ID: <E543642B-CFC9-4D50-ABD2-6F49C55E6D06@maseurope.net>

Paul, from the 2.3 spec:

A tag must contain at least one frame. A frame must be at least 1
    byte big, excluding the header.

So that would make the minimum size for a 2.3 tag 21 bytes (tag  
header=10 + 1 frame header=10, + 1 byte of data)

Best,

Mark

On 14 Feb 2007, at 10:36, Paul Taylor wrote:

> Hi, what is the minimum allowable length of an ID3v23 (and ID3v22  
> and ID3v24) tag, is it just 10 bytes (the tag header) or does it  
> have to be greater than that.
>
> thanks paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Tue Feb 13 11:04:25 2007
From: jwhite at cdtag.com (Jud White)
Date: Tue, 13 Feb 2007 13:04:25 -0600
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <106099C4-D9BA-4B64-899D-E5CEC3754ACF@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <20070213025831464946.c391ac65@kde.org> <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com> <45D204EC.8040101@kde.org> <106099C4-D9BA-4B64-899D-E5CEC3754ACF@apple.com>
Message-ID: <45D20BB9.3060108@cdtag.com>

TTA allows it.

FLAC, APE, WMA, SHN, WavPack all do not allow it.

Not sure about others.

Ernest Prabhakar wrote:
> Out of curiosity, do you know if ID3v4.2 is being used in any lossless 
> formats?
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From prabhaka at apple.com  Sun Feb 11 17:05:08 2007
From: prabhaka at apple.com (Ernest Prabhakar)
Date: Sun, 11 Feb 2007 17:05:08 -0800
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl>
Message-ID: <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com>

Have you filed a bug?

http://developer.apple.com/bugreporter/bugbestpractices.html

If you can file a specific bug explaining the concrete, real-world  
interoperability consequences, I can help escalate it to the iTunes  
team.

-- Ernie P.

On Feb 9, 2007, at 6:46 PM, Dale Preston wrote:

> Apple iTunes suffers from the same problem as Windows Media Player  
> 11 when it comes to ID3V2.2 TYE and ID3V2.3 TYER frames.  In both  
> tag versions iTunes adds a leading and trailing zero byte to the  
> frame.
>
>
>
> And, of course, there?s the issue of iTunes defaulting to the  
> obsolete ID3V2.2 tag in the first place.
>
>
>
> Dale
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070211/218bd6d0/attachment.html>

From erochenski at kajedev.com  Fri Feb  2 13:19:40 2007
From: erochenski at kajedev.com (Edward R. Rochenski)
Date: Fri, 2 Feb 2007 16:19:40 -0500
Subject: [ID3 Dev] .NET library
In-Reply-To: <6BB184CB7C064412BBA6F80BC4FFC7B7.MAI@cdtag.com>
References: <6BB184CB7C064412BBA6F80BC4FFC7B7.MAI@cdtag.com>
Message-ID: <369A997348C642B980127A7E0A2DFE8B@PREC670>

Hey Jud,

Thanks for the heads up!  We have had an on-going project here to do the
same, and it never has gotten the attention it deserved.  I definitely look
forward to taking a look, and hopefully I can provide some useful feedback
and testing results for you.

Thanks,

Ed 

-----Original Message-----
From: Jud White [mailto:jwhite at cdtag.com] 
Sent: Friday, February 02, 2007 4:13 PM
To: id3v2 at id3.org
Subject: [ID3 Dev] .NET library

Hello,

I just wanted to take a minute to let you guys know about the first release
of a .NET 2.0 tagging library I've been working on called IdSharp.  The name
is inspired by my clumsy habbit of holding shift to type "ID3" and
forgetting to let go on the last character :)

It supports reading and writing 2.2, 2.3, 2.4 and converting between the
formats.  There's also preliminary COM interop support which has been tested
with VB6 and VC++6.

Here's the link: http://idsharp.com/download/idsharp.zip

It could use some testing, if anyone is so inclined.  If anyone's REALLY
interested, there's also a SVN repository you're welcome to check out.
Anyway just wanted to make a small announcement - if you'd like to reply
please do so privately or on the forums to keep the clutter down here.

-Jud




---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org



From mark at maseurope.net  Sat Feb  3 20:49:53 2007
From: mark at maseurope.net (Mark Smith)
Date: Sun, 4 Feb 2007 04:49:53 +0000
Subject: [ID3 Dev] Opinions
In-Reply-To: <BAY111-DAV92A5BF8F7CC1CB721FEF9DD9A0@phx.gbl>
References: <B59E02A9-A334-4897-B414-201C2D14921D@maseurope.net> <BAY111-DAV92A5BF8F7CC1CB721FEF9DD9A0@phx.gbl>
Message-ID: <D916E2E7-E408-44AC-9103-EC053FBC8516@maseurope.net>

Thanks, Dale. That sounds like a good way to go.

Best,

Mark

On 3 Feb 2007, at 21:01, Dale Preston wrote:

> I display the first one and ignore any duplicates.  The only time I  
> check
> for un-allowed duplicates in my library is if the client attempts  
> to create
> a new frame.  Then, if the frame exists and only one is allowed, an
> exception is thrown.  That way, as much as is possible, I don't  
> mess with
> bad tags that I didn't create while still trying not to create bad  
> tags of
> my own.
>
> HTH,
>
> Dale
>
>
>
> -----Original Message-----
> From: Mark Smith [mailto:masmit at gmail.com] On Behalf Of Mark Smith
> Sent: Saturday, February 03, 2007 11:59 AM
> To: id3v2 at id3.org
> Subject: [ID3 Dev] Opinions
>
> What does everyone think is the best way to deal with situations
> where you find more than one version of a one-only frame eg. TPE1 in
> a tag?
>
> Just use the first one encountered?
>
> Any advice gratefully recieved.
>
> Best,
>
> Mark Smith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From Nick.Rogers at NorthDown.gov.uk  Mon Feb  5 02:48:28 2007
From: Nick.Rogers at NorthDown.gov.uk (Nick.Rogers at NorthDown.gov.uk)
Date: Mon, 5 Feb 2007 10:48:28 +0000
Subject: [ID3 Dev] Tag for MP3 Video Clips
Message-ID: <OF82A8D8E7.02E01E66-ON80257279.003A640A-80257279.003B5EC6@northdown.gov.uk>

Good Morning from Open Communities in Ireland.. also at www.audiotours.net 
where our 101 guide is freely available for download

We are developing an open source approach to building Audio Tours for free 
use by local communities wishing to build tours of their local community 
and publish them on the web to encourage people to understand them and 
visit their area... 

We  have suggested using the ID3 picture tagging with great effect for 
recognition pictures  - 'where am I .. Oh I recognise that building ... 
etc.. etc'.. or overlaid with an arrow to say 'turn right at the market 
square'

The success of the project is the ability to distribute the tours and 
guides without resort to proprietary software.. iPod can play video clips 
but you are locked into an iPod to play them.. 

Can anyone in the ID3 community suggest a way or extending the MP3 picture 
tag to play a short open source standard video clip.. we really want to 
promote open access to people and places around the world - not add to the 
revenue line for an already successful company..
www.opencommunities.eu

********************************************************************************
This e-mail (including any attachments) is intended  for the above-named person(s). It is confidential and may contain legally privileged information. Any  opinions expressed are not necessarily those of the  company. If you receive it in error please delete it, inform the sender and do not copy, distribute or take any action in reliance upon it. 

We may monitor all incoming and outgoing emails in  line with current legislation. We have taken steps to ensure that this email and attachments are free from  any virus, but it remains your responsibility to  ensure that viruses do not adversely affect you.
******************************************************************************
This email has been scanned for viruses by the Email Protection Agency
For more information please visit http://www.epagency.net 
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070205/dd3c04dc/attachment.html>

From fiji at ayup.limey.net  Mon Feb 12 16:58:34 2007
From: fiji at ayup.limey.net (Ben Bennett)
Date: Mon, 12 Feb 2007 19:58:34 -0500
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com>
Message-ID: <20070213005834.GA28083@ayup.limey.net>

On Mon, Feb 12, 2007 at 03:41:47PM -0800, Ernest Prabhakar wrote:
> On Feb 12, 2007, at 12:08 PM, Mitchell S. Honnert wrote:
> >I have a quick follow-up question.  What is your criteria for "real- 
> >world interoperability consequences"?
> 
> Thanks for your query, and I can appreciate your concern.  The sort  
> of data I'm looking for is "When I obtain an MP3 track from this  
> legal download site, it contains this information which is *not*  
> usable from iTunes."

You can see the syncsafe size problem any time anyone has a frame 128
bytes long or greater.  This is most obvious with cover images.

I am not sure that any "legal download sites" are shipping mp3s with
cover art in a 2.4 tag, so requiring that is a bit disingenuous.
However, being unable to parse a tag correctly if there is a 128 byte
frame is a pretty serious bug.  Try using one of the other mp3
programs that supports id3 v2.4 (e.g. Amarok, I am not sure what
windows or mac alternatives are) and either adding a picture to it, or
typing in more than 128 characters into a text frame.  If you look at
that file in iTunes it will misread it, and will not be able to read
any subsequent frame.  If you do the inverse (create the tag with
iTunes) and try to read it in the other program it will be similarly
broken.

Note that iTunes may appear to handle it correctly if the frame is at
the end of the tag, since it thinks the frame is longer than it really
is it will read until the end of the tag and stop.

For that reason, if you must have frames >= 128 bytes in a tag, it is
best to put them at the end of the file to work around iTunes'
braindamage.

Note, I am not sure how iTunes can actually fix this.  Given that they
have been writing horribly broken frames, they have to be able to read
them or people will scream.  I think the only hope is for us to rev
2.4.0 to 2.4.1, but keep the spec essentially the same but really
LOUDLY note this mandatory change.  That way everyone can trust a
2.4.1 tag will not have sync errors in the frames, and it will give
iTunes a safe recovery path.  (And yes... I know you can apply
heuristics to catch the error most of the time, but that is gross).

			    -ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From benski at winamp.com  Mon Feb 12 12:43:14 2007
From: benski at winamp.com (Ben Allison)
Date: Mon, 12 Feb 2007 15:43:14 -0500
Subject: [ID3 Dev] Unicode
In-Reply-To: <119461A3B1C2A847BABA421E6EB62CEA183F57@EMAIL1.gracenote.gracenote.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>    <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>    <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>    <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>    <45CFF2A1.4050706@cdtag.com> <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com> <119461A3B1C2A847BABA421E6EB62CEA183F57@EMAIL1.gracenote.gracenote.com>
Message-ID: <45D0D162.7080006@winamp.com>

Rob,

Had forgotten about the sizeof(wchar_t) != 2 on all platforms (see 
earlier post).  But the rest of the code is OK.  It's not detecting 
big-endian versus little-endian, just whether or not you need to swap 
endianness.

The intent of my post was to be sure that people aren't confused by the 
fact that literal numbers in C are defined in big endian notation.  I 
think I probably just made the situation worse, though :)

-ben

Robert Manson wrote:
> Hi Ben,
> With regards to your comment:
>   
>>> it will also do the right thing, regardless of platform.
>>>       
> If you're intent here was to indicate that the code snippets you posted
> are portable I'm afraid you are mistaken.
>
> The wchar_t type is not portable instead you should use ui16_t for
> UTF-16 (or UCS-2). (whar_t is 16 bits on windows but 32 bits on linux,
> and is not guaranteed to be more than 7 bits) Also note that ui16_t is
> guaranteed to be *at least* 2 bytes so you should not use sizeof(),
> instead you should use the number 2.
>
> Also, while it is true that literal values are big endian, the byte
> ordering of the lval is system dependent so the code snippets will
> produce different results depending on whether or not the platform is
> big or little endian.
>
> -Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From prabhaka at apple.com  Mon Feb 12 15:41:47 2007
From: prabhaka at apple.com (Ernest Prabhakar)
Date: Mon, 12 Feb 2007 15:41:47 -0800
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <00c101c74ee1$9c86da40$79030105@kendle.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com>
Message-ID: <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com>

Hi Mitchell,

On Feb 12, 2007, at 12:08 PM, Mitchell S. Honnert wrote:
> Hello Ernie.  I'm sure most of the members of this list would  
> greatly appreciate any help you could give with resolving the  
> iTunes ID3 compliance issues.  As you can see from the other  
> responses, there are some fairly big problems with the way iTunes  
> implements the ID3 standards.
>
> I have a quick follow-up question.  What is your criteria for "real- 
> world interoperability consequences"?

Thanks for your query, and I can appreciate your concern.  The sort  
of data I'm looking for is "When I obtain an MP3 track from this  
legal download site, it contains this information which is *not*  
usable from iTunes."

That is, while I realize you live in a world where spec conformance  
is its own reward, I need to be able to provide concrete customer  
usage problems to motivate change.

Does that make sense?

-- Ernie P.




>   I think that by definition ID3 developers are a nitpicky lot, so  
> I'm not asking about highly esoteric issues in rarely used frames.   
> But it seems to me that problems like the ID3v2.4 non-syncsafe size  
> issue and iTunes inexplicable preference for a deprecated ID3  
> version (ID3 v2.2) would cause interoperability consequences that  
> would warrant attention from Apple.
>
> Again, thanks for your reply.  I hope that the list has found  
> resource that can help address these problems from within.
>
>  - Mitchell S. Honnert
>
> ----- Original Message -----
> From: Ernest Prabhakar
> To: id3v2 at id3.org
> Sent: Sunday, February 11, 2007 8:05 PM
> Subject: Re: [ID3 Dev] Apple iTunes complicance issues
>
> Have you filed a bug?
>
> http://developer.apple.com/bugreporter/bugbestpractices.html
>
> If you can file a specific bug explaining the concrete, real-world  
> interoperability consequences, I can help escalate it to the iTunes  
> team.
>
> -- Ernie P.
>
> On Feb 9, 2007, at 6:46 PM, Dale Preston wrote:
>
>> Apple iTunes suffers from the same problem as Windows Media Player  
>> 11 when it comes to ID3V2.2 TYE and ID3V2.3 TYER frames.  In both  
>> tag versions iTunes adds a leading and trailing zero byte to the  
>> frame.
>>
>>
>> And, of course, there?s the issue of iTunes defaulting to the  
>> obsolete ID3V2.2 tag in the first place.
>>
>>
>> Dale
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070212/f1067dd8/attachment.html>

From mark at maseurope.net  Sat Feb  3 09:58:54 2007
From: mark at maseurope.net (Mark Smith)
Date: Sat, 3 Feb 2007 17:58:54 +0000
Subject: [ID3 Dev] Opinions
Message-ID: <B59E02A9-A334-4897-B414-201C2D14921D@maseurope.net>

What does everyone think is the best way to deal with situations  
where you find more than one version of a one-only frame eg. TPE1 in  
a tag?

Just use the first one encountered?

Any advice gratefully recieved.

Best,

Mark Smith

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Sun Feb 11 18:26:08 2007
From: jwhite at cdtag.com (Jud White)
Date: Sun, 11 Feb 2007 20:26:08 -0600
Subject: [ID3 Dev] Unicode
In-Reply-To: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>
Message-ID: <45CFD040.6040707@cdtag.com>

Mark,

This isn't a UCS-2 vs UTF-16 issue.  The differences in these two only 
occur over 0xffff.  Also it's not an issue with BOM since iTunes can 
cope without BOM.

I was able to reproduce this behavior by writing a text encoding byte of 
"Unicode" (0x01) but writing the actual string in UTF-8.  Maybe your 
implementation is doing something similar?

-Jud



Mark Smith wrote:
> I'm getting a bit exasperated with trying to handle Unicode correctly. 
> In my library, I'm handling all strings as UTF8 internally, but since 
> the 2.3 spec (as I've understood it) only allows for iso 8559-1 and 
> UCS-2 (for the moment I'm treating UCS-2 as if it were UTF-16), I'm 
> writing out as UTF-16, where necessary.
>
> What I'm finding is that if I write out a TALB frame as "Er?t" (thats 
> E - r - e with acute accent - t, if your mail client displays 
> something else) as UTF-16, iTunes and the other two tagging apps I've 
> checked out display it in an oriental font.
>
> So the question is, am I wrong, or are other people just not bothering 
> to deal with anything but english?
>
> Any insights gratefully recieved....
>
> Thanks,
>
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Tue Feb 13 10:12:33 2007
From: jwhite at cdtag.com (Jud White)
Date: Tue, 13 Feb 2007 12:12:33 -0600
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <20070213025831464946.c391ac65@kde.org> <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com>
Message-ID: <45D1FF91.5080804@cdtag.com>

Ernest,

I submitted the same issue (v2.4 syncsafe) on Sunday.  Apple responded: 
"After further investigation it has been determined that this is a known 
issue, which is currently being investigated by engineering. This issue 
has been filed in our bug database under the original Bug ID# 3929557."

The other issue I submitted related to APIC text encoding is #4990808.



Ernest Prabhakar wrote:
> Hi Scott,
>
> On Feb 12, 2007, at 5:58 PM, Scott Wheeler wrote:
>> Yes, here is the bug report that came through for Amarok:
>>
>> http://bugs.kde.org/show_bug.cgi?id=121400
>>
>> As noted, I filed this with Apple more than a year ago.
>
> Thanks.  Can you perhaps find the Apple bug number, so I can track it?
>
> Also, if you can identify anything other than Amarok that has this 
> problem interoperating with iTunes, it would help raise the priority.  
> It doesn't have to run on the Mac, though it should at least run on 
> Windows (since those are the two platforms we worry most about).
>
> Best,
> -- Ernie P.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From prabhaka at apple.com  Tue Feb 13 10:01:54 2007
From: prabhaka at apple.com (Ernest Prabhakar)
Date: Tue, 13 Feb 2007 10:01:54 -0800
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <20070213025831464946.c391ac65@kde.org>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl> <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com> <00c101c74ee1$9c86da40$79030105@kendle.com> <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com> <20070213005834.GA28083@ayup.limey.net> <20070213025831464946.c391ac65@kde.org>
Message-ID: <B8A493F8-33EE-43DA-B388-F3BC2D4BF7C8@apple.com>

Hi Scott,

On Feb 12, 2007, at 5:58 PM, Scott Wheeler wrote:
> Yes, here is the bug report that came through for Amarok:
>
> http://bugs.kde.org/show_bug.cgi?id=121400
>
> As noted, I filed this with Apple more than a year ago.

Thanks.  Can you perhaps find the Apple bug number, so I can track it?

Also, if you can identify anything other than Amarok that has this  
problem interoperating with iTunes, it would help raise the  
priority.  It doesn't have to run on the Mac, though it should at  
least run on Windows (since those are the two platforms we worry most  
about).

Best,
-- Ernie P.

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Sun Feb 11 11:28:45 2007
From: dalepres at msn.com (Dale Preston)
Date: Sun, 11 Feb 2007 13:28:45 -0600
Subject: [ID3 Dev] Can text frames be empty
Message-ID: <BAY111-DAV134CB1B9DD44B430FF92A7DD920@phx.gbl>

The description for ID3V2.3 frames says that frames must include at least
one byte of data.  How does this rule applied to text frames?  For instance,
if track number is not set, is a TRCK frame with the frame data as { 0, 0 },
representing an encoding byte, no string data, and then a null termination
byte, considered a valid frame?  

 

If it is valid, is it still better to remove the empty frame?  For instance,
if track number is not set, is it better to leave an existing TRCK frame
with 0,0 for the data or is it better to remove the TRCK frame altogether?

 

Thanks,

 

 

Dale

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070211/65491e9e/attachment.html>

From benski at winamp.com  Sun Feb 11 21:04:14 2007
From: benski at winamp.com (Ben Allison)
Date: Mon, 12 Feb 2007 00:04:14 -0500 (EST)
Subject: [ID3 Dev] Unicode
In-Reply-To: <45CFF2A1.4050706@cdtag.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net>
    <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com>
    <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl>
    <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
    <45CFF2A1.4050706@cdtag.com>
Message-ID: <49887.75.75.86.10.1171256654.squirrel@mail.winamp.com>

And just a note that C compilers treat literal numbers as big endian.

So if you do this
wchar_t BOM = 0xFEFF;
fwrite(&BOM, 1, sizeof(BOM), fp);

it will "do the right thing" regardless of the platform.

similiarly, if you do this:
wchar_t BOM;
fread(&BOM, 1, sizeof(BOM), fp);
if (BOM == 0xFEFF) // don't switch endian
{
}
else // switch endian
{
}

it will also do the right thing, regardless of platform.

> Mark,
>
> This is backwards.  Little endian BOM is FF FE and big endian BOM is FE FF
>
> Mark Smith wrote:
>> 0xFF 0xFE for big-endian, or 0xFE 0xFF for little-endian.
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From sales at tagtuner.com  Sat Feb 17 19:33:46 2007
From: sales at tagtuner.com (Kirill)
Date: Sun, 18 Feb 2007 05:33:46 +0200
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <45D79568.6040407@cdtag.com>
References: <45D79568.6040407@cdtag.com>
Message-ID: <137403647953.20070218053346@tagtuner.com>

Hello Jud,

I tried to open this file with my software and found a problem with
UTF-16 encoded description. Maybe other applications have a similar
problem.

The multiple covers works fine. Try UTF-8 instead.

-- 
Best regards,
 Kirill                            mailto:sales at tagtuner.com

Sunday, February 18, 2007, 1:53:12 AM, you wrote:

JW> Does anyone see a problem with the tag in this file?  
JW> http://idsharp.com/id3v2/itunes-nopics.mp3  specifically the two APIC 
JW> frames.

JW> IdSharp and UltraID3Lib are both able to read the two pics. Tag&Rename 
JW> shows no pics, The Godfather shows something weird (probably doesn't 
JW> support Unicode), WMP shows the first picture, and iTunes shows no pics.

JW> Thanks


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From mark at maseurope.net  Sat Feb 17 17:49:39 2007
From: mark at maseurope.net (Mark Smith)
Date: Sun, 18 Feb 2007 01:49:39 +0000
Subject: [ID3 Dev] iTunes / APIC with Unicode text encoding
In-Reply-To: <45D79568.6040407@cdtag.com>
References: <45D79568.6040407@cdtag.com>
Message-ID: <D52989EF-51D1-4E23-A21D-DDD936C86C5E@maseurope.net>

iTunes 7.0.2 on this G4 mac shows the cover picture....

Best,

Mark

On 17 Feb 2007, at 23:53, Jud White wrote:

> Does anyone see a problem with the tag in this file?  http:// 
> idsharp.com/id3v2/itunes-nopics.mp3  specifically the two APIC frames.
>
> IdSharp and UltraID3Lib are both able to read the two pics.  
> Tag&Rename shows no pics, The Godfather shows something weird  
> (probably doesn't support Unicode), WMP shows the first picture,  
> and iTunes shows no pics.
>
> Thanks
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jwhite at cdtag.com  Fri Feb  2 13:13:27 2007
From: jwhite at cdtag.com (Jud White)
Date: Fri, 2 Feb 2007 15:13:27 -0600
Subject: [ID3 Dev] .NET library
Message-ID: <6BB184CB7C064412BBA6F80BC4FFC7B7.MAI@cdtag.com>

Hello,

I just wanted to take a minute to let you guys know about the first release of a .NET 2.0 tagging library I've been working on called IdSharp.  The name is inspired by my clumsy habbit of holding shift to type "ID3" and forgetting to let go on the last character :)

It supports reading and writing 2.2, 2.3, 2.4 and converting between the formats.  There's also preliminary COM interop support which has been tested with VB6 and VC++6.

Here's the link: http://idsharp.com/download/idsharp.zip

It could use some testing, if anyone is so inclined.  If anyone's REALLY interested, there's also a SVN repository you're welcome to check out.  Anyway just wanted to make a small announcement - if you'd like to reply please do so privately or on the forums to keep the clutter down here.

-Jud


-------------- next part --------------
---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org

From jwhite at cdtag.com  Sun Feb 11 20:52:49 2007
From: jwhite at cdtag.com (Jud White)
Date: Sun, 11 Feb 2007 22:52:49 -0600
Subject: [ID3 Dev] Unicode
In-Reply-To: <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com> <45CFD1A2.9060502@cdtag.com> <BAY111-DAV54E3555D8922A05F48744DD910@phx.gbl> <8ACA52F5-873E-4F58-9291-CB3EAC2857C7@maseurope.net>
Message-ID: <45CFF2A1.4050706@cdtag.com>

Mark,

This is backwards.  Little endian BOM is FF FE and big endian BOM is FE FF

Mark Smith wrote:
> 0xFF 0xFE for big-endian, or 0xFE 0xFF for little-endian.
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Fri Feb  9 18:05:37 2007
From: dalepres at msn.com (Dale Preston)
Date: Fri, 9 Feb 2007 20:05:37 -0600
Subject: [ID3 Dev] An addition for the Compliance Issues list.
Message-ID: <BAY111-DAV3DFFCEBBEF24D74516F3EDD930@phx.gbl>

I have a couple additions for the compliance issues list.  

 

Windows Media Player 10 creates improper ID3V2.3 TYER frames.  They are 5
bytes long though the standard specifically states they are always 4 bytes
long.  The leading byte is a zero value.

 

Windows Media Player 11 leads with a zero value byte but also appends a zero
value byte, giving a length of 6 bytes for the ID3V2.3 TYER frame.

 

I can provide samples if necessary.

 

 

Dale

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070209/8c48cd40/attachment.html>

From jwhite at cdtag.com  Sun Feb 11 18:32:02 2007
From: jwhite at cdtag.com (Jud White)
Date: Sun, 11 Feb 2007 20:32:02 -0600
Subject: [ID3 Dev] Unicode
In-Reply-To: <45CFD040.6040707@cdtag.com>
References: <1537E15E-AFCF-40C0-9B2C-563A8C604C86@maseurope.net> <45CFD040.6040707@cdtag.com>
Message-ID: <45CFD1A2.9060502@cdtag.com>

Just tested this.. if you're writing the BOM reversed (should be 0xFF 
0xFE) you'll get oriental characters in iTunes.

Jud White wrote:
> Mark,
>
> This isn't a UCS-2 vs UTF-16 issue.  The differences in these two only 
> occur over 0xffff.  Also it's not an issue with BOM since iTunes can 
> cope without BOM.
>
> I was able to reproduce this behavior by writing a text encoding byte 
> of "Unicode" (0x01) but writing the actual string in UTF-8.  Maybe 
> your implementation is doing something similar?
>
> -Jud
>
>
>
> Mark Smith wrote:
>> I'm getting a bit exasperated with trying to handle Unicode 
>> correctly. In my library, I'm handling all strings as UTF8 
>> internally, but since the 2.3 spec (as I've understood it) only 
>> allows for iso 8559-1 and UCS-2 (for the moment I'm treating UCS-2 as 
>> if it were UTF-16), I'm writing out as UTF-16, where necessary.
>>
>> What I'm finding is that if I write out a TALB frame as "Er?t" (thats 
>> E - r - e with acute accent - t, if your mail client displays 
>> something else) as UTF-16, iTunes and the other two tagging apps I've 
>> checked out display it in an oriental font.
>>
>> So the question is, am I wrong, or are other people just not 
>> bothering to deal with anything but english?
>>
>> Any insights gratefully recieved....
>>
>> Thanks,
>>
>> Mark
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Mon Feb 12 17:58:31 2007
From: wheeler at kde.org (Scott Wheeler)
Date: Tue, 13 Feb 2007 02:58:31 +0100
Subject: [ID3 Dev] Apple iTunes complicance issues
In-Reply-To: <20070213005834.GA28083@ayup.limey.net>
References: <BAY111-DAV2C5302053390A7DBF8515DD930@phx.gbl>
 <9223AD59-81D8-4175-91A7-2A04804E8D94@apple.com>
 <00c101c74ee1$9c86da40$79030105@kendle.com>
 <B32BF68D-F161-4A3F-AC0C-747E1A33D07A@apple.com>
 <20070213005834.GA28083@ayup.limey.net>
Message-ID: <20070213025831464946.c391ac65@kde.org>

On Mon, 12 Feb 2007 19:58:34 -0500, Ben Bennett wrote:
> Note, I am not sure how iTunes can actually fix this.  Given that they
> have been writing horribly broken frames, they have to be able to read
> them or people will scream.  I think the only hope is for us to rev
> 2.4.0 to 2.4.1 [...]

It's a lot easier than that.  Here's a pseudocode algorithm:

size = read(4 bytes)

if ( the upper bit of any byte in size is 1 )
  synchsafe = false
else
  if ( next frame starts at synchsafe interpretation + 1 )
    synchsafe = true
  else
    synchsafe = false

And then proceed based on the value of synchsafe.

Combining replies:

On Mon, 12 Feb 2007 17:42:50 -0800, Ernest Prabhakar wrote:
> For example, it sounds like the usage:
> 
> a) Add an MP3 file to Amarok
> b) Add a picture
> c) Import it into iTunes
> 
> will result in broken image.  Right?

Yes, here is the bug report that came through for Amarok:

http://bugs.kde.org/show_bug.cgi?id=121400

As noted, I filed this with Apple more than a year ago.

-Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From dalepres at msn.com  Sun Feb 18 19:54:47 2007
From: dalepres at msn.com (Dale Preston)
Date: Sun, 18 Feb 2007 21:54:47 -0600
Subject: [ID3 Dev] Need Help Understanding My Own Tags
In-Reply-To: <491749.19627.qm@web53503.mail.yahoo.com>
References: <491749.19627.qm@web53503.mail.yahoo.com>
Message-ID: <BAY111-DAV7FBA15945ECBAD29B6842DD8A0@phx.gbl>

You can try my ID3 Raw Tag Viewer at
http://www.dalepreston.com/Blog/2007/02/id3-raw-tag-viewer.html.  It may be
just what you're looking for.  It doesn't yet support ID3V2.4 but it does
support ID3V1, V1.1, V2.2, V2.3.

 

Dale

 

From: John Slane [mailto:jaslane64 at yahoo.com] 
Sent: Sunday, February 18, 2007 12:15 PM
To: id3v2 at id3.org
Subject: [ID3 Dev] Need Help Understanding My Own Tags

 

I am not a developer.  I am a user who is very confused about how my id3v2
tags are being created and read by various software packages.  I have used
programs like iTunes, MediaMonkey, id3Tag, AllFrames Tagger, and more.  Each
of these seems to have its own way of writing metadata to an id3v2 tag.  And
each can read SOME of the frames written by the others.  Some of the frames
written are STANDARD frames (like YEAR), and others are NONSTANDARD (like
COMMENT MUSICMATCH_MOOD).  I am near despair in trying to figure out how one
program is going to interpret the frames written by another.

It seems to me that I would benefit greatly if I could simply see what
actual frames these programs are writing to.  The id3v2 standard defines
74(?) frames: AENC, APIC, COMM, COMR, ..... etc.  None of the tagger
software I mentioned above identifies which of these frames is actually
being used.  Therefore, I have no way of directly comparing the way these
programs read and write.

Can you suggest any available Windows software that will let me:
- read the tag of an mp3 file, 
- see the metadata in ALL the frames, and - most importantly -
- see the 4-letter code name (AENC, APIC, ...) for each frame?  

With such a tool, I could see what my music software is actually doing to
the tags, and figure out how to make the tags from one program work with
another.

Freeware would be best, of course.... but I'm getting desperate enough to
buy if necessary. ;-)

Any help you can provide would be greatly appreciated.  I have been working
on this for weeks, with virtually no progress whatsoever.

If my questions are not within the scope of this mailing list, please
forgive my ignorance.

If there is another authority I might more appropriately contact, I would
appreciate contact info.

Gratefully,
John Slane
Dublin OH
jaslane64 at yahoo.com

  

  _____  

Everyone is raving about the
<http://us.rd.yahoo.com/evt=42297/*http:/advision.webevents.yahoo.com/mailbe
ta>  all-new Yahoo! Mail beta.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20070218/ce663d8b/attachment.html>