[ID3 Dev] 'Extending' ID3 V2.4
Ion Todirel
iontodirel at yahoo.co.uk
Sat Feb 11 13:20:30 PST 2006
"Why do you think it’s a bad idea? Do you mean there are too many frames in the existing standard or in the idea I discussed? (I only gave an example of six base frames.)", too many... and xml.
"let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here. What about the mailing list don’t you like?", i think that mailing list is a stupid idea, besides if we have a blog many people will be implicated, more more publicity, what we talking about: ID3,org MUST HAVE A BLOG, who is with me?. We can read coments very easy using an RSS Reader.
"using an library too for read/write info "powered by" ID3.org? There are groups out there that are already doing this. The two that spring to mind are MusicBrainz and FreeDB. Besides, the scope of id3.org (as I understand it) is to define and promote the standard for imbedding metadata in a file, not to be the *source* of that data."
yep right like i sed: a library for read/write info (metadata : data about data) in
files "powered by" ID3.org. So if Apple wont to use ID3 standard will use
library created by ID3 group. What this mean: a unified standard not only on
papers by implemented too. So will not be problems and incompatibility with
tags, written by a different id3 library.
"Mitchell S. Honnert" <mitch at honnert.com> wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} st1\:*{behavior:url(#default#ieooui) } >eh, sounds bad, maybe in future we use xml ... but frames are too many...
Why do you think it’s a bad idea? Do you mean there are too many frames in the existing standard or in the idea I discussed? (I only gave an example of six base frames.)
>- let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here.
What about the mailing list don’t you like?
>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?
There are groups out there that are already doing this. The two that spring to mind are MusicBrainz and FreeDB. Besides, the scope of id3.org (as I understand it) is to define and promote the standard for imbedding metadata in a file, not to be the *source* of that data.
Mitchell S. Honnert
www.UltraID3Lib.com
---------------------------------
From: Ion Todirel [mailto:iontodirel at yahoo.co.uk]
Sent: Saturday, February 11, 2006 3:35 PM
To: id3v2 at id3.org
Subject: RE: [ID3 Dev] 'Extending' ID3 V2.4
eh, sounds bad, maybe in future we use xml ... but frames are too many...
anyway, i have two sugestions:
- let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here.
- 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?
"Mitchell S. Honnert" <mitch at honnert.com> wrote:
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
---------------------------------
Yahoo! Photos – NEW, now offering a quality print service from just 8p a photo.
---------------------------------
Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with voicemail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060211/30da3780/attachment.html>
More information about the ID3v2
mailing list