[ID3 Dev] 'Extending' ID3 V2.4

[Mitchell S. Honnert]

For what it's worth, here's my two cents...

While I think the highly complex, specialized nature of the ID3v2 spec can
work against its uniform adoption, I'm not a big fan of a wholesale
replacement of the frame collection paradigm with XML.  But what about a
hybrid?  What if the next gen version of ID3 limited itself to a few "base"
frame types, one of which was a frame flagged to contain XML?  

So, to throw out some ideas, these "base" frames might be...

TextFrame - what's now the "T" frames i.e. Artist, Title, Album

NumberFrame - a strongly typed frame to store numbers i.e. Track Number,
Year, Beats Per Minutes, Duration (MS)

BinaryFrame - generically store pictures or any BLOB's/GEOB's

TextCollectionFrame - a list of text values i.e. Genres

DictionaryFrame - a collection of text key/value pairs i.e. Involved People.

XMLFrame - basically the same as TextFrame but flagged as storing XML.

You'd still have tag ID's to identify what's in each of these frames, but
all data would fit into one of the handful of base frames.

In designing my ID3 library, I used a set of base classes in an OO hierarchy
to minimize the amount of duplicate code I'd have.  So, when I'm
implementing a new frame, I always begin by thinking "Can I just start off
by inheriting one of my existing base Frame classes or do I have to start
from scratch?"  If the new standard had a small number of these "base"
frames -- and relied on the XML frame as a catchall for the more complex
metadata -- then implementers could write the base encoding/decoding code
for these frames very quickly.  

It would only be if you needed to access the more complex frames (read
"rarely used" frames) that you'd have to parse XML or use a DOM.  For
example, if this style of ID3 format were in place, the addition of a
Chapter frame wouldn't have required the creation of a whole new base frame
type.  Instead of having to focus on the binary format of this new frame, we
would just have had to agree on an XML schema.  Sure, anyone implementing
this new frame would have had to write new code to handle the specific XML
format, but -- here's the important part -- it wouldn't require you to
revisit the area of your library where binary parsing is done.  "You want to
implement a ChapterFrame?  Fine, inherit the XMLFrame and parse the (Friend)
XMLFrame.XML property."

Personally, what my goal for a next generation ID3 standard would be is an
elegant combination of support for simple, commonly-used metadata and
complex, rarely-used metadata.  The basic implementation would be so simple
and streamlined that it would promote a uniformity of application.  But it
would also support complex metadata, if that's what you needed.  I think
using a small set of "base" frames which included one to support XML could
meet this goal.  

Sure, the current IDv2 can support almost any metadata requirement
imaginable, but the learning curve is very steep.  In theory this shouldn't
matter.  In designing a metadata tag format, you shouldn't have to account
for bad (but popular) implementations that all but render the standard
useless.  But in reality, you do have to worry about the learning curve of
your format and how it will affect implementation and adoption.  Creating
something with an "Easy to learn, hard to master" learning curve would go a
long way to reducing the number of corrupt implementations.

I could go one with my pros (and some of the cons) of this idea, but I've
already rambled on too much, so I thought I'd throw this out there for now.

Mitchell S. Honnert
www.UltraID3Lib.com





-----Original Message-----
From: Paul Taylor [mailto:paul_t100 at fastmail.fm] 
Sent: Saturday, February 11, 2006 5:11 AM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4

Completely agree XML must be the way to go it would be so much easier to 
enforcer validation,implement a libray and be able to view directly in a 
human readable form. MusicBrainz (ww.musicbrainz.org) uses XML RDF to 
store its track data maybe this could be used as the basis of an XML 
Format. I know there are a number of formats additional to ID3v2, do any 
of these already use XML ?

Paul Grebenc wrote:

>
>> Another "problem" with XML is that it is so flexible when it comes to
>> the text encoding of the actual document.  Having to support so many
>> text encodings can be a big problem, especially in the embedded space.
>
>
> The specification could dictate that the tag has to use UTF-8.  Or, it 
> would be just as easy to not dictate that and let anyone use their 
> preference.  As it stands, ID3v2 supports Unicode, but I doubt there 
> are very many embedded devices that will correctly display anything 
> outside the standard ASCII character set.  There are probably enough 
> desktop applications that support ID3v2 that won't do the right thing 
> with Unicode, as it is.
>
> I don't want to argue this point forever.  I just want to express 
> three opinions:
>
> 1. Parsing XML without a full-blown parser/DOM support does not have 
> to be hard.
>
> 2. A new version should target the embedded devices that will be 
> designed a few years from now as the minimum embedded platform.  
> Existing devices aren't going to retroactively support any new 
> version, regardless of how simple it is, so there's no value in 
> wondering whether a three year old 32MB keychain player can 'handle it'.
>
> 3. XML has some disadvantages, but the one enormous advantage it has, 
> considering that half the traffic on this list is moaning about bad 
> ID3v2 implementations, is the ability it provides to universally 
> enforce validation.
>
> 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


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