[ID3 Dev] 'Extending' ID3 V2.4

[Tom Sorensen]

I hope you're just taking this concept to a logical absurdity, and not
actually trying to be serious.

Personally, while I think the v2.4 standard has a large number of useless
(or at least mostly unused) frames, I also don't support the idea of going
to a less formalized or rigorous standard (ala Ogg Vorbis). Vorbis tags are
at the other end of the extreme -- too loose. Some of the implementation is
smart (always UTF-8 encoded for instance), but they don't have to deal with
"synchsafe integers" and the like either. And once you go beyond the minimal
set of "well known" tags then you're off in a minefield.

Any attempt to create a new ID3 standard, however, must tackle the
complexity of the current standard and not only reduce it but also spell
things out more clearly. That includes pseudo-code in some areas (like, oh
say, synch-safe integers). I think this is one major reason that V2.4 is
poorly adopted and often poorly implemented.

There's got to be a decent middle ground between ID3V2.4 and Ogg Vorbis
style tags.


On 2/10/06, Ion Todirel <iontodirel at yahoo.co.uk> wrote:
>
> why use a binary representation of data containing in files why just not
> use xml? and why storing this data inside the files and not providing a
> unified database for fast access and that will store all needed information?
>
> *Michal Vician <id3v2 at audiott.com>* wrote:
>
> > ...In this case specifically, I can certainly imagine an ID3 spec
> > that would be possible to implement completely, with less code,
> > without reducing the functionality provided.
>
> As far as I'm concerned I don't have any problems with code lenght.
> But if have you any concrete ideas (I mean something like a sketch of new
> ID3 version), just post them. Maybe we can move ID3 spec forward.
>
> Best regards
> Miso
>
> > On Thursday 09 February 2006 22:16, Michal Vician wrote:
> >> Can't see the merit of deprecating frames. ID3v2 is proposed so frames
> >> you
> >> would like to deprecate doesn't limit/restrict you in any way. There is
> >> no
> >> need to deprecate them. So why do they annoy you?
> >
> > Three notes:
> >
> > - I'm mostly just babbling about what I would like to see for an ID3v2.5
> > or
> > ID3v3, so take this as such. I don't actually expect either of those
> > versions happen since it's been about 5 years since the last ID3
> revision.
> > I
> > certainly don't expect a 2.4.1 or something to deprecate frames.
> >
> > - For the moment I do just ignore them in my implementation. They're
> > parsed
> > as an "unknown frame".
> >
> > - It's really about complexity and cleanliness. ID3v2 is too complex for
> > what it achieves (saying this as a person who has implemented several
> tag
> > formats). In theory, an ID3 spec could do basically everything that
> ID3v2
> > does now and be much easier to implement completely.
> >
> > Basically a spec is only as good as its implementations. If portions of
> a
> > spec are wholesale ignored across many implementations, then it's
> probably
> > fair to say that the spec is too complicated. In this case specifically,
> > I
> > can certainly imagine an ID3 spec that would be possible to implement
> > completely, with less code, without reducing the functionality provided.
> > Adding more frames would just, in my opinion, increase the amount of
> ID3v2
> > that would be ignored by implementors.
> >
> > Cheers,
> >
> > -Scott
>
>
> --
> Michal Vician
> id3v2 at audiott.com
> http://www.audiott.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>
> ------------------------------
> To help you stay safe and secure online, we've developed the all new *Yahoo!
> Security Centre*<http://us.rd.yahoo.com/mail/uk/taglines/default/security_centre/*http://uk.security.yahoo.com/>
> .
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060210/bec567b8/attachment.html>