[ID3 Dev] updates to existing ID3v2 standards?

[Mitchell S. Honnert]

[OK, this got to be a lot longer than I had intended, but I found it was
necessary to use this much space to fully explain my request. - MSH]

 

I'd like to propose that we open up the existing ID3 specifications for
updates in order to make clarifications or to make slight tweaks to existing
sections.  I understand that there are risks in changing standards
documentation after they've been published, but based on what I've seen,
more harm is being done by ambiguous and sometimes downright confusing ID3
documentation than the potential harm of changing the documentation after
the fact.  The normal process of publishing new, updated versions of a spec
just doesn't work with ID3.  (ID3v2.4 has been out for a long time and
ID3v2.3 is still far more popular.)  I think we could make some relatively
small changes that would have a large beneficial impact.   By limiting the
updates to the two very specific cases below, I think we could adhere to the
principle that no update would break existing implementations.  (A principle
which we've already used recently when adding the accessibility frames.)

 

1) Clarifications of an existing specification which don't change the spec

I've been working with the ID3 specs for years now (in my work on my own ID3
library) so I'm familiar with many of their quirks and eccentricities of the
documentation.  But even other supporters of the ID3 format would have to
admit that some of the specifications can be confusing to a brand new
reader.  Sure, there are sources outside the spec (such as the ID3.org FAQ
and this discussion list itself), but why not just update the spec itself to
eliminate the confusion?  I think that with some relatively minor edits, we
could make the standard much more clear and user-friendly.  Of course we'd
have to come up with a consensus on what certain specs actually meant.  But
wouldn't it be better to do that work once rather than leave it to be done
every time a new developer sits down to implement the standard?

 

2) Slight alteration of an existing standard in light of de facto standards
used by overwhelming majority of ID3 apps/libs

Standards are nice and everything, but in the end, their success can be
measured by their compliance.  What use is having a standard frame format
that is all but ignored?  Wouldn't it be better to acquiesce to the real
implementations out there than to stubbornly hold on to what has become an
irrelevant and ignored section of the standard?  Again, I'm not saying to
remove support for any feature; just to tweak a standard so that it would
also comply with existing implementations.  I think we could tweak a frame's
specification slightly, thus updating it to support both the existing spec
as well as a de facto standard.  I'm not saying to change the spec willy
nilly to match existing implementations.  (Just because iTunes or WinAmp
does something a particular way, doesn't make it the best or right way.)
Instead we would add to the spec so that it matches implementations that
don't necessarily conform to how the spec was written, but in hindsight
conforms to how the spec should have been written.

 

(I'm hoping that the use of the ID3.org Wiki, with its revision history,
will alleviate some of the hesitation to make the kinds of changes I
suggest.)

 

Because the Genre/Content Type/TCON frame is what got me thinking about this
topic, I'll use it as an example.  I consider myself to be a staunch
supporter of the ID3 format, but I have to say that the ID3 v2
specifications for the TCON frame are just plain awful.  Why in the world
would you add the level of complexity to the frame's format by including the
ID3v1 genre numbers, especially since the spec itself admits that the
"category list would be impossible to maintain with accurate and up to date
categories"?  To use the example in the TCON spec, what is the point of
having "(4)Eurodisco" (where 4 is the ID3v1 Genre number for "Disco") when
"Eurodisco" by itself would do just fine?  

 

I don't think that the goal of the TCON frame was to create a
subcategorization system whereby you could represent "Disco with a
subcategory of Eurodisco".  But this is what is implied by the TCON spec.
According to a literal reading of the TCON frame spec, custom genres are not
allowed, only custom refinements to the standard genres.  WinAmp allows you
to type in "Eurodisco" into the Genre field?  Sorry, according to the
existing spec, you should have to select "Disco" from a finite list of
values, then type in "Eurodisco" as a modifier so that WinAmp can store
"(4)Eurodisco" in the TCON frame.  Why do we have a spec, that as written,
nobody implements?  Why would we want to leave developers saying "Well,
surely that's not what they really meant" when we can clarify what was
really meant?

 

So, how do I think we should update the TCON frame spec?  Well, if we
acknowledge that the vast majority of ID3v2 implementations ignore the silly
parenthetical ID3v1 Genre number, then I would reword the frame's spec to
describe a simple null-delimited list of custom genre strings.  For backward
compatibility's sake, I would place the "(4)Eurodisco" format gobbledygook
in an "Optional" section.  Also, the TCON spec states that multiple genres
are supported, but without some rather subjective interpretations of the
spec, I don't see how it's supposed to be done.  (Unless you only use the
numeric sections as delimiters for the "refinements", the spec doesn't make
any sense for multiple genres.)  Personally, if we did nothing more than
promote the use of multiple genres by tweaking the TCON spec, I'd consider
it a great success.  Oh, and I'd also correct the spelling of "numerig".

 

The details of changes aren't so important now.  I'm sure that there would
be much discussion by the members of this over what would be changed and
how.  I admit that I have some strong opinions on how the TCON spec could be
improved, but my goal for this e-mail was to get input on whether updates
like this would even be accepted.

 

For the record, I don't make this suggestion lightly.  I understand the
problems associated with altering an existing specification.  But I think
that failing to bring the spec in line with reality is actually causing more
harm than good.  Because the specs have remained in the original state,
along with all of their original flaws, developers have for years been left
to their own subjective judgments on how best to implement
ambiguously-worded specs.  This has, I believe, led to a fracturing of the
standard.  We can't do much about existing implementations, especially those
coded into hardware devices.  But we could make it easier for anyone else
trying to implement the standard.  I believe that the people on this list
are the wardens of the ID3 standard.  And as the wardens, I believe that it
our responsibility to do what we can to minimize further fracturing, even if
it means retrofitting the standard to fit "noncompliant" implementations.
In short, I think we can make compromises on the ID3 standard without
compromising the ID3 standard.

 

Mitchell S. Honnert

www.UltraID3Lib.com

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