From id3v2 at northpb.com Tue Jun 14 06:24:25 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Tue, 14 Jun 2005 06:24:25 -0700 Subject: [ID3 Dev] Version 3 of ID3? Message-ID: <42AEDA89.6020909@northpb.com> >Date: Tue, 14 Jun 2005 12:00:29 +0100 >To: id3v2 at id3.org >From: Chris Newell >Subject: Version 3 of ID3? >> >Hi, > >Is there a version 3 of ID3 under discussion? If so, how do we >contribute input to this process? > >Chris > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >Dr J.C. Newell >Digital Media Group, BBC Research & Development >Kingswood Warren, Woodland Way, Tadworth, Surrey >KT20 6NP UK >mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd >Tel: +44 (0)1737 839659 >Switchboard: +44 1737 839500 >Fax: +44 (0)1737 839665 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From ygor at comcast.net Mon Jun 27 09:05:40 2005 From: ygor at comcast.net (ygor at comcast.net) Date: Mon, 27 Jun 2005 16:05:40 +0000 Subject: [ID3 Dev] Future development of ID3 Message-ID: <062720051605.19393.42C023D1000A251200004BC122058861729D010997@comcast.net> I am also interested in this feature for use in AudioBooks. Rather than having one sound-file per chapter, It would be nice to put the book into a single file with "chapter stops" in it. Do the v2.4 tags facilitate this ? > > 2) many radio programmes consist of several concatenated > > articles. In some cases it would be useful to provide information > > specific to each article and support navigation between articles. > > Could you put a new tag in front of each article? Or use the tag > inforation change stuff in v2.4? > > -ben > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Mon Jun 27 06:54:08 2005 From: fiji at ayup.limey.net (Ben Bennett) Date: Mon, 27 Jun 2005 09:54:08 -0400 Subject: [ID3 Dev] Future development of ID3 In-Reply-To: <6.1.2.0.2.20050627103054.02bf35b0@pop3> References: <6.1.2.0.2.20050627103054.02bf35b0@pop3> Message-ID: <20050627135408.GA20393@ayup.limey.net> On Mon, Jun 27, 2005 at 11:28:27AM +0100, Chris Newell wrote: > I haven't seen any answers to my original query (below) about the > future development of ID3. There are two potential areas for > development which interest me. I ignored you because there was not enough detail. This message is a great start at provising the missing information. > 1) some of the existing tags are not a good match to the > requirements for podcasting radio programmes. Because they're not a > good match people are using them inconsistently and the presentation > of these tags by client software does not always make sense. Can you provide examples of where the current tags fall short and what you would like to see? > 2) many radio programmes consist of several concatenated > articles. In some cases it would be useful to provide information > specific to each article and support navigation between articles. Could you put a new tag in front of each article? Or use the tag inforation change stuff in v2.4? -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From bmearns at coe.neu.edu Wed Jun 8 21:09:20 2005 From: bmearns at coe.neu.edu (Brian Mearns) Date: Thu, 9 Jun 2005 00:09:20 -0400 Subject: [ID3 Dev] Windows Media Frames appear to use invalid FrameSizes Message-ID: <200506090409.j5949EjS002150@wright.coe.neu.edu> I'm trying to parse some id3v2 tags off an mp3, and I keep running into problems with a PRIV frame, with no Owner identifier and private data beginning with: "WM/UniqueFileIdentifier", and then a bunch more after it. I can tell visually that the frame is 148 bytes, giving it a FrameSize of 138. For some reason, whoever wrote the tag stored the whole value in the first byte of the size, making it 10001010 ( -118 in signed dec), and thereby breaking with the synchsafe standard. Based on the "WM" preceeding the data--and there are several other "WM/..." PRIV frames in the file--I'm thinking it's something Windows Media player is doing, but I'm not positive. Has anyone else come across such a thing before, or have a good ideaof how to handle it? I can put some hooks in my code to handle it, but I'd rather not write it out in this broken format, so if I ever get a tag which doesn't syncsafe any bytes in the size, I'm going to be in trouble. Just in case I'm missing something stupid, here are the bytes in the frame (in hex, obviously). Note the 8a in the 8th byte (1-based), the last byte of the frame size element. 50 52 49 56 00 00 00 8a 00 00 57 4d 2f 55 6e 69 71 75 65 46 69 6c 65 49 64 65 6e 74 69 66 69 65 72 00 41 00 4d 00 47 00 61 00 5f 00 69 00 64 00 3d 00 52 00 20 00 20 00 20 00 33 00 36 00 37 00 39 00 39 00 32 00 3b 00 41 00 4d 00 47 00 70 00 5f 00 69 00 64 00 3d 00 50 00 20 00 20 00 20 00 20 00 33 00 38 00 33 00 38 00 33 00 3b 00 41 00 4d 00 47 00 74 00 5f 00 69 00 64 00 3d 00 54 00 20 00 20 00 35 00 31 00 33 00 39 00 34 00 39 00 39 00 00 -Brian Mearns (bmearns at coe.neu.edu) --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From chris.newell at rd.bbc.co.uk Tue Jun 28 03:56:06 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Tue, 28 Jun 2005 11:56:06 +0100 Subject: [ID3 Dev] Future development of ID3 In-Reply-To: <20050627135408.GA20393@ayup.limey.net> References: <6.1.2.0.2.20050627103054.02bf35b0@pop3> <20050627135408.GA20393@ayup.limey.net> Message-ID: <6.1.2.0.2.20050628115438.02d9aa38@pop3> At 14:54 27/06/2005, Ben Bennett wrote: >On Mon, Jun 27, 2005 at 11:28:27AM +0100, Chris Newell wrote: >> I haven't seen any answers to my original query (below) about the >> future development of ID3. There are two potential areas for >> development which interest me. > >I ignored you because there was not enough detail. This message is a >great start at provising the missing information. > >> 1) some of the existing tags are not a good match to the >> requirements for podcasting radio programmes. Because they're not a >> good match people are using them inconsistently and the presentation >> of these tags by client software does not always make sense. > >Can you provide examples of where the current tags fall short and what >you would like to see? The structure of the current tags is based around the assumption that you're describing music. So you typically have: Title / Album / Artist Radio program podcasters appear to be using the following mappings to these tags: - they use the "Title" tag to carry the Episode Name or Date - they use the "Album" tag for carry the Series Name or omit this tag - they use the "Artist" tag to carry the Channel Name or Broadcaster Name or Presenter Name Ideally, I'd like to see a more consistent and coherent way to describe radio programmes. >> 2) many radio programmes consist of several concatenated >> articles. In some cases it would be useful to provide information >> specific to each article and support navigation between articles. > >Could you put a new tag in front of each article? From the navigation point of view it would be better to put all the information at the beginning of the file - this would allow a player to display a "playlist" of the articles (or chapters) within the file without having to scan through it. > Or use the tag >inforation change stuff in v2.4? I'm not sure whether this currently supports everything needed. Would this approach also require scanning? I could write a description of the requirements if it would help to decide how the functionality could be supported. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From bmearns at coe.neu.edu Thu Jun 9 15:01:45 2005 From: bmearns at coe.neu.edu (Brian Mearns) Date: Thu, 9 Jun 2005 18:01:45 -0400 Subject: [ID3 Dev] Windows Media Frames appear to use invalid FrameSizes In-Reply-To: Message-ID: <200506092201.j59M1dRY027441@wright.coe.neu.edu> v2.3. Thanks, I must have looked at that informal spec 30 times yesterday, and completely blew past those 4 extra "x"'s in the Frame Size element. -Brian _____ From: Pyt [mailto:py.thoulon at gmail.com] Sent: Thursday, June 09, 2005 11:28 AM To: id3v2 at id3.org Subject: Re: [ID3 Dev] Windows Media Frames appear to use invalid FrameSizes Is it a v2.3 or v2.4 tag ? v2.3 does not have the notion of synchsafe integers for frame sizes. The size as coded would be correct in a v2.3 tag. Pyt. On 6/9/05, Brian Mearns wrote: I'm trying to parse some id3v2 tags off an mp3, and I keep running into problems with a PRIV frame, with no Owner identifier and private data beginning with: "WM/UniqueFileIdentifier", and then a bunch more after it. I can tell visually that the frame is 148 bytes, giving it a FrameSize of 138. For some reason, whoever wrote the tag stored the whole value in the first byte of the size, making it 10001010 ( -118 in signed dec), and thereby breaking with the synchsafe standard. Based on the "WM" preceeding the data--and there are several other "WM/..." PRIV frames in the file--I'm thinking it's something Windows Media player is doing, but I'm not positive. Has anyone else come across such a thing before, or have a good ideaof how to handle it? I can put some hooks in my code to handle it, but I'd rather not write it out in this broken format, so if I ever get a tag which doesn't syncsafe any bytes in the size, I'm going to be in trouble. Just in case I'm missing something stupid, here are the bytes in the frame (in hex, obviously). Note the 8a in the 8th byte (1-based), the last byte of the frame size element. 50 52 49 56 00 00 00 8a 00 00 57 4d 2f 55 6e 69 71 75 65 46 69 6c 65 49 64 65 6e 74 69 66 69 65 72 00 41 00 4d 00 47 00 61 00 5f 00 69 00 64 00 3d 00 52 00 20 00 20 00 20 00 33 00 36 00 37 00 39 00 39 00 32 00 3b 00 41 00 4d 00 47 00 70 00 5f 00 69 00 64 00 3d 00 50 00 20 00 20 00 20 00 20 00 33 00 38 00 33 00 38 00 33 00 3b 00 41 00 4d 00 47 00 74 00 5f 00 69 00 64 00 3d 00 54 00 20 00 20 00 35 00 31 00 33 00 39 00 34 00 39 00 39 00 00 -Brian Mearns (bmearns at coe.neu.edu) --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From py.thoulon at gmail.com Thu Jun 9 08:28:17 2005 From: py.thoulon at gmail.com (Pyt) Date: Thu, 9 Jun 2005 17:28:17 +0200 Subject: [ID3 Dev] Windows Media Frames appear to use invalid FrameSizes In-Reply-To: <200506090409.j5949EjS002150@wright.coe.neu.edu> References: <200506090409.j5949EjS002150@wright.coe.neu.edu> Message-ID: Is it a v2.3 or v2.4 tag ? v2.3 does not have the notion of synchsafe integers for frame sizes. The size as coded would be correct in a v2.3 tag. Pyt. On 6/9/05, Brian Mearns wrote: > > > I'm trying to parse some id3v2 tags off an mp3, and I keep running into > problems with a PRIV frame, with no Owner identifier and private data > beginning with: "WM/UniqueFileIdentifier", and then a bunch more after it. > I > can tell visually that the frame is 148 bytes, giving it a FrameSize of > 138. > For some reason, whoever wrote the tag stored the whole value in the first > byte of the size, making it 10001010 ( -118 in signed dec), and thereby > breaking with the synchsafe standard. Based on the "WM" preceeding the > data--and there are several other "WM/..." PRIV frames in the file--I'm > thinking it's something Windows Media player is doing, but I'm not > positive. > > > Has anyone else come across such a thing before, or have a good ideaof how > to handle it? I can put some hooks in my code to handle it, but I'd rather > not write it out in this broken format, so if I ever get a tag which > doesn't > syncsafe any bytes in the size, I'm going to be in trouble. > > Just in case I'm missing something stupid, here are the bytes in the frame > (in hex, obviously). Note the 8a in the 8th byte (1-based), the last byte > of > the frame size element. > > 50 52 49 56 00 00 00 8a 00 00 57 4d 2f 55 6e 69 71 75 65 46 69 6c 65 49 64 > 65 6e 74 69 66 69 65 72 00 41 00 4d 00 47 00 61 00 5f 00 69 00 64 00 3d 00 > 52 00 20 00 20 00 20 00 33 00 36 00 37 00 39 00 39 00 32 00 3b 00 41 00 4d > 00 47 00 70 00 5f 00 69 00 64 00 3d 00 50 00 20 00 20 00 20 00 20 00 33 00 > 38 00 33 00 38 00 33 00 3b 00 41 00 4d 00 47 00 74 00 5f 00 69 00 64 00 3d > 00 54 00 20 00 20 00 35 00 31 00 33 00 39 00 34 00 39 00 39 00 00 > > > > -Brian Mearns > (bmearns at coe.neu.edu) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.newell at rd.bbc.co.uk Mon Jun 27 03:28:27 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Mon, 27 Jun 2005 11:28:27 +0100 Subject: [ID3 Dev] Future development of ID3 Message-ID: <6.1.2.0.2.20050627103054.02bf35b0@pop3> Hi, I haven't seen any answers to my original query (below) about the future development of ID3. There are two potential areas for development which interest me. 1) some of the existing tags are not a good match to the requirements for podcasting radio programmes. Because they're not a good match people are using them inconsistently and the presentation of these tags by client software does not always make sense. 2) many radio programmes consist of several concatenated articles. In some cases it would be useful to provide information specific to each article and support navigation between articles. What would be the best way to take these issues further? Chris >Is there a version 3 of ID3 under discussion? If so, how do we >contribute input to this process? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org