[ID3 Dev] Multiple Values proposal

[Audio Ranger Development]

Hi,

we had this exact discussion when talking about v 2.31 about a year ago:

 > > [Mathias Kunter]
 > > Multiple frames would also break backwards compatibility -
 > > "There may only be one text information frame of its kind
 > > in an tag." Well, breaking this rule won't make any existing
 > > parser fail, but many existing implementations would probably
 > > just use the last frame [...]
 > >
 > > Null-delimited frames seem to be the better choice for me,
 > > since they behave identically for current parsers, assuming
 > > that they read the frame data as simple null-terminated
 > > string.
 >
 > [Ben Allison]
 > Yeah, I agree with this. I mentioned multiple frames only
 > because that's how some other metadata formats handle this. I'm
 > not particularly partial to it and I agree that it conflicts
 > with the existing spec.


But we somehow never actually got to work on ID3 v 2.31. We still have 
that github repository at https://github.com/id3 and the collected ideas 
at https://github.com/id3/ID3v2.3/blob/master/collected-ideas.txt for 
that purpose.

Maybe I can find some time to work on a v 2.31 draft within the next 
weeks. It wouldn't be that much work to at least add UTF-8 and multiple 
value support to the specification.

Mathias


Am 06.03.2012 23:00, schrieb Ben Allison:
> I know we had this conversation a little while ago, but here's another
> suggestion.  I'm not sure if we discussed this one or not.
>
> Vorbis comments (as well as APEv2 and FLAC which uses a very similar
> scheme) supports multiple values by having a key repeated more than once
> in the tag.
>
> Could we not do something similar with ID3v2?  If you want multiple
> artists, for example, just create multiple TPE1 frames.
>
> We could increment the versions to v2.31 and v2.41 to signify the change.
> The main questions are:
> 1) Would any major existing implementations completely fail or return a
> parsing error when encountering duplicate frames
> 2) Would any major existing implementations do anything strange, like use
> the last-encountered frame rather than the first-encountered frame, as the
> value.
>
> For a variety of reasons, this feels like a superior alternative to
> NULL-delimited strings.
>
> Thoughts?
> -Ben Allison
> Nullsoft, Inc.
>
> ---------------------------------------------------------------------
> 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