[ID3 Dev] ID3v2.5

[Mitchell S. Honnert]

>As someone else said, simply adding UTF-8 to ID2v2.3 and marking it as
>v2.3.1 ($03 01 in the header) would probably be a far better option.
>And clarify multiple genres (space or NULL separated), along with any
>other simple issues. ID3v2.3 is far from perfect, but it's at least
>widespread and well adopted.
Tom, I have to agree.  While I admit that it's very interesting to think 
about how we could rewrite the entire ID3 standard from the ground up, it's 
all just an academic exercise given the pervasiveness of the current 
versions.  I think your suggestion of refining the existing standards is the 
only practical solution.  No matter how much the pure programmer in me wants 
to get in there an rip everything up and "make it better", my project lead 
experience tells me that a more reasoned approach is necessary.

To use your example -- and one of my pet issues with the current 
standards -- I'd be happy is the standard codified the Genre frame format as 
implemented by ID3-TagIt (i.e. the null-terminated genre list).  Sure, I 
have visions of how the standard could be overhauled, but really there are 
just a few key areas that could be refined and many issues would go away.

Who knows?  Maybe there will be some opportunity to implement a completely 
redesigned "ID3v3" which steamlines the design and uses XML in some fashion. 
But personally I don't think that day is today.

 - Mitchell S. Honnert


----- Original Message ----- 
From: "Tom Sorensen" <tsorensen at gmail.com>
To: <id3v2 at id3.org>
Sent: Tuesday, February 28, 2006 8:59 AM
Subject: Re: [ID3 Dev] ID3v2.5


I disagree completely. If this was true, there wouldn't be nearly as
many tag editors, metadata services (with multiple versions of albums
in them), and so forth. Tag editing is certainly frequent enough to be
a concern. Padding is essential.

And, frankly, as far as encoding goes -- why not just mandate UTF-8
and be done with it? There would certainly be some breakage from files
encoded in other codepages, but there's a lot of breakage there
already.

And, finally, getting anything new adopted at this point would be nigh
impossible. ID3v2.4 is still pretty well unsupported. A simpler tag
structure would help, but unless you get industry giants onboard
(Apple, Creative, WinAmp, various chipset manufacturers, etc) then
expect adoption to occur sometime next decade, if ever.

As someone else said, simply adding UTF-8 to ID2v2.3 and marking it as
v2.3.1 ($03 01 in the header) would probably be a far better option.
And clarify multiple genres (space or NULL separated), along with any
other simple issues. ID3v2.3 is far from perfect, but it's at least
widespread and well adopted. And existing libraries (even dead ones,
like id3lib) could be trivially modified to support the changes.

Tom

On 2/27/06, Michal Vician <id3v2 at audiott.com> wrote:
> > Having the tag at the beginning of the file and no padding means that a
> > rewrite of the entire file will often be necessary if the tag is
> > modified.
>
> This is very disputable, because user mostly edits the tag only once and
> then burns it on CD. In this case there is no need to rewrite entire file
> again and again...
>
> Regards
> Miso
>
>
> ---------------------------------------------------------------------
> 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