<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Arial;
color:windowtext;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
/* List Definitions */
@list l0
{mso-list-id:294913489;
mso-list-type:hybrid;
mso-list-template-ids:1079947624 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>[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]<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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.)<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>1) Clarifications of an existing specification which don’t
change the spec<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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 <i><span
style='font-style:italic'>once</span></i> rather than leave it to be done every
time a new developer sits down to implement the standard?<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>2) Slight alteration of an existing standard in light of de
facto standards used by overwhelming majority of ID3 apps/libs<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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 <i><span style='font-style:italic'>should
have</span></i> been written.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>(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.)<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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? <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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 <i><span style='font-style:italic'>refinements</span></i>
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?<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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”.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'> <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Mitchell S. Honnert<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>www.UltraID3Lib.com<o:p></o:p></span></font></p>
</div>
</body>
</html>