<div>eh, sounds bad, maybe in future we use xml ... but frames are too many...</div>  <div> </div>  <div>anyway, i have two sugestions:</div>  <div> </div>  <div>- let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here.</div>  <div> </div>  <div>- in futere let's create a free ID3.org library for standartisation purpose. Why WMP can using AMG, iTunes, winamp use CDDB, in terms of music info, why not using an library too for read/write info "powered by" ID3.org? So who want to use ID3 she will use a ID3 ID3 library. We can develop using COM, .NET and Java, anywone will be happy. Why just providing a list of library but not create one? <BR><BR><B><I>"Mitchell S. Honnert" <mitch@honnert.com></I></B> wrote:</div>  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">For what it's worth, here's my two cents...<BR><BR>While I think the highly complex,
 specialized nature of the ID3v2 spec can<BR>work against its uniform adoption, I'm not a big fan of a wholesale<BR>replacement of the frame collection paradigm with XML. But what about a<BR>hybrid? What if the next gen version of ID3 limited itself to a few "base"<BR>frame types, one of which was a frame flagged to contain XML? <BR><BR>So, to throw out some ideas, these "base" frames might be...<BR><BR>TextFrame - what's now the "T" frames i.e. Artist, Title, Album<BR><BR>NumberFrame - a strongly typed frame to store numbers i.e. Track Number,<BR>Year, Beats Per Minutes, Duration (MS)<BR><BR>BinaryFrame - generically store pictures or any BLOB's/GEOB's<BR><BR>TextCollectionFrame - a list of text values i.e. Genres<BR><BR>DictionaryFrame - a collection of text key/value pairs i.e. Involved People.<BR><BR>XMLFrame - basically the same as TextFrame but flagged as storing XML.<BR><BR>You'd still have tag ID's to identify what's in each of these frames, but<BR>all data would fit into one
 of the handful of base frames.<BR><BR>In designing my ID3 library, I used a set of base classes in an OO hierarchy<BR>to minimize the amount of duplicate code I'd have. So, when I'm<BR>implementing a new frame, I always begin by thinking "Can I just start off<BR>by inheriting one of my existing base Frame classes or do I have to start<BR>from scratch?" If the new standard had a small number of these "base"<BR>frames -- and relied on the XML frame as a catchall for the more complex<BR>metadata -- then implementers could write the base encoding/decoding code<BR>for these frames very quickly. <BR><BR>It would only be if you needed to access the more complex frames (read<BR>"rarely used" frames) that you'd have to parse XML or use a DOM. For<BR>example, if this style of ID3 format were in place, the addition of a<BR>Chapter frame wouldn't have required the creation of a whole new base frame<BR>type. Instead of having to focus on the binary format of this new frame, we<BR>would just have
 had to agree on an XML schema. Sure, anyone implementing<BR>this new frame would have had to write new code to handle the specific XML<BR>format, but -- here's the important part -- it wouldn't require you to<BR>revisit the area of your library where binary parsing is done. "You want to<BR>implement a ChapterFrame? Fine, inherit the XMLFrame and parse the (Friend)<BR>XMLFrame.XML property."<BR><BR>Personally, what my goal for a next generation ID3 standard would be is an<BR>elegant combination of support for simple, commonly-used metadata and<BR>complex, rarely-used metadata. The basic implementation would be so simple<BR>and streamlined that it would promote a uniformity of application. But it<BR>would also support complex metadata, if that's what you needed. I think<BR>using a small set of "base" frames which included one to support XML could<BR>meet this goal. <BR><BR>Sure, the current IDv2 can support almost any metadata requirement<BR>imaginable, but the learning curve is very
 steep. In theory this shouldn't<BR>matter. In designing a metadata tag format, you shouldn't have to account<BR>for bad (but popular) implementations that all but render the standard<BR>useless. But in reality, you do have to worry about the learning curve of<BR>your format and how it will affect implementation and adoption. Creating<BR>something with an "Easy to learn, hard to master" learning curve would go a<BR>long way to reducing the number of corrupt implementations.<BR><BR>I could go one with my pros (and some of the cons) of this idea, but I've<BR>already rambled on too much, so I thought I'd throw this out there for now.<BR><BR>Mitchell S. Honnert<BR>www.UltraID3Lib.com<BR><BR><BR><BR><BR><BR>-----Original Message-----<BR>From: Paul Taylor [mailto:paul_t100@fastmail.fm] <BR>Sent: Saturday, February 11, 2006 5:11 AM<BR>To: id3v2@id3.org<BR>Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4<BR><BR>Completely agree XML must be the way to go it would be so much easier to <BR>enforcer
 validation,implement a libray and be able to view directly in a <BR>human readable form. MusicBrainz (ww.musicbrainz.org) uses XML RDF to <BR>store its track data maybe this could be used as the basis of an XML <BR>Format. I know there are a number of formats additional to ID3v2, do any <BR>of these already use XML ?<BR><BR>Paul Grebenc wrote:<BR><BR>><BR>>> Another "problem" with XML is that it is so flexible when it comes to<BR>>> the text encoding of the actual document. Having to support so many<BR>>> text encodings can be a big problem, especially in the embedded space.<BR>><BR>><BR>> The specification could dictate that the tag has to use UTF-8. Or, it <BR>> would be just as easy to not dictate that and let anyone use their <BR>> preference. As it stands, ID3v2 supports Unicode, but I doubt there <BR>> are very many embedded devices that will correctly display anything <BR>> outside the standard ASCII character set. There are probably
 enough <BR>> desktop applications that support ID3v2 that won't do the right thing <BR>> with Unicode, as it is.<BR>><BR>> I don't want to argue this point forever. I just want to express <BR>> three opinions:<BR>><BR>> 1. Parsing XML without a full-blown parser/DOM support does not have <BR>> to be hard.<BR>><BR>> 2. A new version should target the embedded devices that will be <BR>> designed a few years from now as the minimum embedded platform. <BR>> Existing devices aren't going to retroactively support any new <BR>> version, regardless of how simple it is, so there's no value in <BR>> wondering whether a three year old 32MB keychain player can 'handle it'.<BR>><BR>> 3. XML has some disadvantages, but the one enormous advantage it has, <BR>> considering that half the traffic on this list is moaning about bad <BR>> ID3v2 implementations, is the ability it provides to universally <BR>> enforce validation.<BR>><BR>>
 Paul<BR>><BR>> ---------------------------------------------------------------------<BR>> To unsubscribe, e-mail: id3v2-unsubscribe@id3.org<BR>> For additional commands, e-mail: id3v2-help@id3.org<BR>><BR>><BR>><BR><BR><BR>---------------------------------------------------------------------<BR>To unsubscribe, e-mail: id3v2-unsubscribe@id3.org<BR>For additional commands, e-mail: id3v2-help@id3.org<BR><BR><BR>---------------------------------------------------------------------<BR>To unsubscribe, e-mail: id3v2-unsubscribe@id3.org<BR>For additional commands, e-mail: id3v2-help@id3.org<BR><BR></BLOCKQUOTE><BR><p>
                <hr size=1><font face="Arial" size="2"><a href="http://us.rd.yahoo.com/mail/uk/taglines/default/photos/*http://uk.photos.yahoo.com/"><b>Yahoo! Photos</b></a> – <font color="red">NEW</font>, now offering a <a href="http://us.rd.yahoo.com/mail/uk/taglines/default/photos/*http://uk.photos.yahoo.com/">quality print service</a> from just 8p a photo.</font>