[ID3 Dev] updates to existing ID3v2 standards?

[Mitchell S. Honnert]

>I wholeheartedly agree with the idea of opening 2.4.0 up for
>revision (to produce 2.4.1).
I probably should have spelled it out more clearly -- oh, irony -- but I was
also proposing that the ID3 v2.3 be opened up for revision.  In fact, given
v2.3's ongoing popularity, it's probably more important to make some
clarifications/tweaks to that version.  Obviously many of the revisions
would apply to both v2.3 and v2.4, but for me the driving factor would be
the changes to the v2.3 spec.

 - Mitchell S. Honnert

-----Original Message-----
From: Ben Bennett [mailto:fiji at ayup.limey.net] 
Sent: Monday, December 25, 2006 9:07 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] updates to existing ID3v2 standards?

I wholeheartedly agree with the idea of opening 2.4.0 up for revision
(to produce 2.4.1).

Another proposal would be to LOUDLY scream that the frame length must
be a syncsafe integer, and if you claim 2.4.1 compliance then
goddamnit you had better be emmitting syncsafe ints (APPLE!).  Of
course that is not a change from 2.4.0, but it is hit or miss what
people will do.

				-ben

On Mon, Dec 25, 2006 at 08:03:51PM -0500, Mitchell S. Honnert wrote:
> [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
> 

---------------------------------------------------------------------
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