From paul_t100 at fastmail.fm Tue Mar 6 14:11:07 2012 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Tue, 06 Mar 2012 22:11:07 +0000 Subject: [ID3 Dev] Multiple Values proposal In-Reply-To: References: Message-ID: <4F568B7B.6040504@fastmail.fm> On 06/03/2012 22:00, Ben Allison wrote: > 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. Hi Ben Can you spell out the reasons because to my mind the null terminated values method supported by ID3v24 works perfectly well, and certainly uses alot less space than having to create a whole new frame for each value. If you introduced this new method then there would be two ways of doing the same thing in ID3v24 which is not good, unless you remove support for null terminated values thus making 2.4.1 incompatible with 2.4. I would much prefer to just officially support null terminated values in ID3v231 Paul, Jaikoz, JThink --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From benski at winamp.com Tue Mar 6 14:00:44 2012 From: benski at winamp.com (Ben Allison) Date: Tue, 6 Mar 2012 17:00:44 -0500 Subject: [ID3 Dev] Multiple Values proposal Message-ID: 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 From pradhan.pushkar at gmail.com Wed Mar 14 19:22:21 2012 From: pradhan.pushkar at gmail.com (Pushkar Pradhan) Date: Wed, 14 Mar 2012 19:22:21 -0700 Subject: [ID3 Dev] Support for ID3 v2.4 Message-ID: Hello, I was looking at id3v2 to generate ID3 v2.4 tags. I looked at the ldd output and saw that it uses libid3-3.8.so which only produces ID3 v2.3 tags and this library is not maintained anymore. Any plans of supporting 2.4? Does anyone know of a ID3 v2.4 library? -- pushkar -------------- next part -------------- An HTML attachment was scrubbed... URL: From developer at audioranger.com Wed Mar 7 00:30:48 2012 From: developer at audioranger.com (Audio Ranger Development) Date: Wed, 07 Mar 2012 09:30:48 +0100 Subject: [ID3 Dev] Multiple Values proposal In-Reply-To: References: Message-ID: <4F571CB8.5080209@audioranger.com> 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