From tsorensen at gmail.com Tue Feb 28 06:41:43 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Tue, 28 Feb 2006 09:41:43 -0500 Subject: [ID3 Dev] ID3v2.5 In-Reply-To: References: <59516.195.91.64.52.1141136694.squirrel@195.91.64.52> Message-ID: <4da424620602280641w24a0bba9hd7aad90127b2ecda@mail.gmail.com> There's that, there's issues of finding the tag (if a tag is variable length, then it's a lot easier to find it at the start than somewhere in the tail; not that it's a huge issue anyway). Note that you cannot put it after the ID3v1 tag -- that violates the ID3v1 standard (which states that the tag is the last 128 bytes). It must occur before that tag. And while I didn't mention this, realize that dropping synchsafe integers will cause issues. Any older hardware that isn't aware of ID3v2 tags may treat the tag as audio data, creating static for the end user. There's a *lot* of devices out there (particularly in-dash CD/MP3 players and portable CD/MP3 players) that this is applicable to. Worst case, it could crash the device since the data is very much not audio data. Newer devices at least recognize ID3v2 tags at the start of the file and skip the entire tag body. They're unlikely to skip most end tags other than ID3v1 (such as APEv2, ID3v2.4 footer, etc) though -- again, unless they are coded to recognize them. Most aren't. Tom On 2/28/06, Jonathan del Strother wrote: > > On 28 Feb 2006, at 14:24, Michal Vician wrote: > > >> 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***. > > > > Well, wouldn't it be better to save id3v2 tag to the end to the file > > (rigth after the ID3v1)? I'm pretty new to this mailing list (only > > half a > > year) and I really can't imagine why is ID3v2 tag stored at the very > > beginning of file. Can anybody explain, please? > > > I believe this is purely a benefit for streaming mp3s, where you > don't necessarily have the end of the file by the time you start > playing. > > > > > --------------------------------------------------------------------- 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 Tue Feb 7 16:31:26 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 7 Feb 2006 19:31:26 -0500 Subject: [ID3 Dev] archives? In-Reply-To: <200602071702.50105.wheeler@kde.org> References: <200602071041.44778.wheeler@kde.org> <43E8A1A5.6050202@northpb.com> <200602071702.50105.wheeler@kde.org> Message-ID: <20060208003126.GA12507@ayup.limey.net> On Tue, Feb 07, 2006 at 05:02:49PM +0100, Scott Wheeler wrote: > > - Syncsafe integer definitions in v2.4 > > Seeing those two together today is kind of funny since I noticed just > yesterday that in Apple's recent switch to ID3v2.4 they ignore the sync-safe Yes. VERRRY ANNOYING. I have been flaming about it on this list a lot :-) In my mind 2.4 is totally unusable because of the wide variation in implementation from all the different libraries. Sigh. It would be nice if there were a 2.4.1 that clarifies the syncsafeness so that people can get the support right (ha). Also, I would love to see a 2.3.1 which just adds support for UTF-8 to the valid charsets. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Thu Feb 9 13:38:34 2006 From: wheeler at kde.org (Scott Wheeler) Date: Thu, 9 Feb 2006 22:38:34 +0100 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <52134.195.91.64.54.1139519786.squirrel@195.91.64.54> References: <43EB8958.4090504@sympatico.ca> <200602092005.49739.wheeler@kde.org> <52134.195.91.64.54.1139519786.squirrel@195.91.64.54> Message-ID: <200602092238.34817.wheeler@kde.org> On Thursday 09 February 2006 22:16, Michal Vician wrote: > Can't see the merit of deprecating frames. ID3v2 is proposed so frames you > would like to deprecate doesn't limit/restrict you in any way. There is no > need to deprecate them. So why do they annoy you? Three notes: - I'm mostly just babbling about what I would like to see for an ID3v2.5 or ID3v3, so take this as such. I don't actually expect either of those versions happen since it's been about 5 years since the last ID3 revision. I certainly don't expect a 2.4.1 or something to deprecate frames. - For the moment I do just ignore them in my implementation. They're parsed as an "unknown frame". - It's really about complexity and cleanliness. ID3v2 is too complex for what it achieves (saying this as a person who has implemented several tag formats). In theory, an ID3 spec could do basically everything that ID3v2 does now and be much easier to implement completely. Basically a spec is only as good as its implementations. If portions of a spec are wholesale ignored across many implementations, then it's probably fair to say that the spec is too complicated. In this case specifically, I can certainly imagine an ID3 spec that would be possible to implement completely, with less code, without reducing the functionality provided. Adding more frames would just, in my opinion, increase the amount of ID3v2 that would be ignored by implementors. Cheers, -Scott -- New Orleans food is as delicious as the less criminal forms of sin. --Mark Twain --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at audiott.com Tue Feb 28 06:23:38 2006 From: id3v2 at audiott.com (Michal Vician) Date: Tue, 28 Feb 2006 15:23:38 +0100 (CET) Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> Message-ID: <54087.195.91.64.52.1141136618.squirrel@195.91.64.52> > 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***. Well, wouldn't it be better to save id3v2 tag to the end to the file (rigth after the ID3v1)? I'm pretty new to this mailing list (only half a year) and I really can't imagine why is ID3v2 tag stored at the very beginning of file. Can anybody explain, please? Many thanks Miso > 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 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 From wheeler at kde.org Tue Feb 28 06:55:24 2006 From: wheeler at kde.org (Scott Wheeler) Date: Tue, 28 Feb 2006 15:55:24 +0100 Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <54087.195.91.64.52.1141136618.squirrel@195.91.64.52> References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> <54087.195.91.64.52.1141136618.squirrel@195.91.64.52> Message-ID: <200602281555.24472.wheeler@kde.org> On Tuesday 28 February 2006 15:23, Michal Vician wrote: > > 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***. > > Well, wouldn't it be better to save id3v2 tag to the end to the file > (rigth after the ID3v1)? I'm pretty new to this mailing list (only half a > year) and I really can't imagine why is ID3v2 tag stored at the very > beginning of file. Can anybody explain, please? This is covered in the spec (It's for streaming). And of course it would need to be before the ID3v1 tag since ID3v1 is required to be at the end of the file. I do in general agree with Tom though. Without this being something that is done with the major commercial implementations on board, this would just be creating standards for the fun of it. It's taken 6 years for ID3v2.4 to catch on and it's still not completely there. One potentially interesting note is that in the Linux world things do tend to support 2.4 since out of the three notable ID3v2 implementation (TagLib, libid3tag and id3lib) the first two support 2.4. -Scott -- Anyone who has begun to think, places some portion of the world in jeopardy. -John Dewey --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From tsorensen at gmail.com Fri Feb 10 11:34:08 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Fri, 10 Feb 2006 14:34:08 -0500 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <20060210190144.39279.qmail@web86915.mail.ukl.yahoo.com> References: <55709.195.91.64.54.1139580591.squirrel@195.91.64.54> <20060210190144.39279.qmail@web86915.mail.ukl.yahoo.com> Message-ID: <4da424620602101134y72bcb96tefef438e9bccd955@mail.gmail.com> I hope you're just taking this concept to a logical absurdity, and not actually trying to be serious. Personally, while I think the v2.4 standard has a large number of useless (or at least mostly unused) frames, I also don't support the idea of going to a less formalized or rigorous standard (ala Ogg Vorbis). Vorbis tags are at the other end of the extreme -- too loose. Some of the implementation is smart (always UTF-8 encoded for instance), but they don't have to deal with "synchsafe integers" and the like either. And once you go beyond the minimal set of "well known" tags then you're off in a minefield. Any attempt to create a new ID3 standard, however, must tackle the complexity of the current standard and not only reduce it but also spell things out more clearly. That includes pseudo-code in some areas (like, oh say, synch-safe integers). I think this is one major reason that V2.4 is poorly adopted and often poorly implemented. There's got to be a decent middle ground between ID3V2.4 and Ogg Vorbis style tags. On 2/10/06, Ion Todirel wrote: > > why use a binary representation of data containing in files why just not > use xml? and why storing this data inside the files and not providing a > unified database for fast access and that will store all needed information? > > *Michal Vician * wrote: > > > ...In this case specifically, I can certainly imagine an ID3 spec > > that would be possible to implement completely, with less code, > > without reducing the functionality provided. > > As far as I'm concerned I don't have any problems with code lenght. > But if have you any concrete ideas (I mean something like a sketch of new > ID3 version), just post them. Maybe we can move ID3 spec forward. > > Best regards > Miso > > > On Thursday 09 February 2006 22:16, Michal Vician wrote: > >> Can't see the merit of deprecating frames. ID3v2 is proposed so frames > >> you > >> would like to deprecate doesn't limit/restrict you in any way. There is > >> no > >> need to deprecate them. So why do they annoy you? > > > > Three notes: > > > > - I'm mostly just babbling about what I would like to see for an ID3v2.5 > > or > > ID3v3, so take this as such. I don't actually expect either of those > > versions happen since it's been about 5 years since the last ID3 > revision. > > I > > certainly don't expect a 2.4.1 or something to deprecate frames. > > > > - For the moment I do just ignore them in my implementation. They're > > parsed > > as an "unknown frame". > > > > - It's really about complexity and cleanliness. ID3v2 is too complex for > > what it achieves (saying this as a person who has implemented several > tag > > formats). In theory, an ID3 spec could do basically everything that > ID3v2 > > does now and be much easier to implement completely. > > > > Basically a spec is only as good as its implementations. If portions of > a > > spec are wholesale ignored across many implementations, then it's > probably > > fair to say that the spec is too complicated. In this case specifically, > > I > > can certainly imagine an ID3 spec that would be possible to implement > > completely, with less code, without reducing the functionality provided. > > Adding more frames would just, in my opinion, increase the amount of > ID3v2 > > that would be ignored by implementors. > > > > Cheers, > > > > -Scott > > > -- > Michal Vician > id3v2 at audiott.com > http://www.audiott.com/ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > > ------------------------------ > To help you stay safe and secure online, we've developed the all new *Yahoo! > Security Centre* > . > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fiji at ayup.limey.net Mon Feb 27 16:17:42 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Mon, 27 Feb 2006 19:17:42 -0500 Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> Message-ID: <20060228001742.GA29749@ayup.limey.net> On Tue, Feb 28, 2006 at 12:31:47AM +0100, Michal Vician wrote: > 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... I dispute that. A lot of programs modify tags to add their stuff... so if you have stuff on a hard drive and change management programs, or even upgrade, it may desire to rewrite your tags. Simplicity is good. Too much simplicity makes things useless because real life is not simple so programs will cram stuff into custom tags in order to implement unsupported features. Balance is necessary. Frankly id3v2.3 is a good enough spec and pretty widely implemented. I really think it would be perfect if there were a v2.3.1 released that added UTF-8 support and that did a few minor clarifications. Also an v2.4.1 that clarified the syncsafe behavior and any other problem areas would be great. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From benski at winamp.com Mon Feb 6 10:45:03 2006 From: benski at winamp.com (Ben Allison) Date: Mon, 6 Feb 2006 13:45:03 -0500 (EST) Subject: [ID3 Dev] WinAPM and ID3 tags? In-Reply-To: <4da424620602061017h71893a0fl94fde47e3a8bc811@mail.gmail.com> References: <15269.195.91.64.52.1139228287.squirrel@195.91.64.52> <2271.68.100.121.19.1139240586.squirrel@mail.winamp.com> <1997.195.91.64.54.1139249641.squirrel@195.91.64.54> <4da424620602061017h71893a0fl94fde47e3a8bc811@mail.gmail.com> Message-ID: <3724.68.100.121.19.1139251503.squirrel@mail.winamp.com> > The right thing to do at this point would be to read them and (preferably) > write them out in proper UTF-16, but it won't fix any read-only media (CD, > streamed media, etc). It's worth pointing out that this is the new behavior. All frames are written out in UTF-16 if any of the frames are edited. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From tsorensen at gmail.com Mon Feb 6 10:17:43 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Mon, 6 Feb 2006 13:17:43 -0500 Subject: [ID3 Dev] WinAPM and ID3 tags? In-Reply-To: <1997.195.91.64.54.1139249641.squirrel@195.91.64.54> References: <15269.195.91.64.52.1139228287.squirrel@195.91.64.52> <2271.68.100.121.19.1139240586.squirrel@mail.winamp.com> <1997.195.91.64.54.1139249641.squirrel@195.91.64.54> Message-ID: <4da424620602061017h71893a0fl94fde47e3a8bc811@mail.gmail.com> On 2/6/06, Michal Vician wrote: > > > After an avalanche of complaints , I had to go > > back to the old, bad, behavior. > > What complaints? Who complain if something works properly and correctly? As far as they're concerned it's not working properly and correctly -- all their old MP3s with tags they created via Winamp now look corrupt. The right thing to do at this point would be to read them and (preferably) write them out in proper UTF-16, but it won't fix any read-only media (CD, streamed media, etc). -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at audiott.com Mon Feb 6 11:32:35 2006 From: id3v2 at audiott.com (Michal Vician) Date: Mon, 6 Feb 2006 20:32:35 +0100 (CET) Subject: [ID3 Dev] WinAPM and ID3 tags? In-Reply-To: <3724.68.100.121.19.1139251503.squirrel@mail.winamp.com> References: <15269.195.91.64.52.1139228287.squirrel@195.91.64.52> <2271.68.100.121.19.1139240586.squirrel@mail.winamp.com> <1997.195.91.64.54.1139249641.squirrel@195.91.64.54> <4da424620602061017h71893a0fl94fde47e3a8bc811@mail.gmail.com> <3724.68.100.121.19.1139251503.squirrel@mail.winamp.com> Message-ID: <17652.195.91.64.54.1139254355.squirrel@195.91.64.54> >> The right thing to do at this point would be to read them and >> (preferably) >> write them out in proper UTF-16, but it won't fix any read-only media >> (CD, >> streamed media, etc). > > It's worth pointing out that this is the new behavior. All frames are > written out in UTF-16 if any of the frames are edited. Okay, but will you also implement all the other encodings which are very likely to be used by other applications (I mean ISO-8859-1, and also UTF-16BE and UTF-8 if talking about ID3v2.4)?. It would be worth for reading the tag. If yes, how do you want to recognize what encoding was used if the "encoding byte" is set to "$01"? It may be ISO-8859-1 or system default. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at audiott.com Mon Feb 6 10:14:01 2006 From: id3v2 at audiott.com (Michal Vician) Date: Mon, 6 Feb 2006 19:14:01 +0100 (CET) Subject: [ID3 Dev] WinAPM and ID3 tags? In-Reply-To: <2271.68.100.121.19.1139240586.squirrel@mail.winamp.com> References: <15269.195.91.64.52.1139228287.squirrel@195.91.64.52> <2271.68.100.121.19.1139240586.squirrel@mail.winamp.com> Message-ID: <1997.195.91.64.54.1139249641.squirrel@195.91.64.54> > Winamp 5.2 (currently in beta) will write its tags in UTF-16. Why didn't winamp begin with UTF-16 support sooner? You know, users of our applications are mostly dilettantes and they really don't care about the ID3 structure... They just use software we develop. If somebody creates tags using my application, or any other application which don't break the standard, and then open it in winamp, tags seems to be corrupted at a view of user. However, they are not! Many people can't believe that the bug is on winamp's side, therefore I receive many e-mails with complaints on my "wrong" working application. Thus I'm curious about why does winamp knowingly break the standard? If there is a bug and you don't know about it, it's ok. But I can't understand why do somebody break the standard deliberately! > After an avalanche of complaints , I had to go > back to the old, bad, behavior. What complaints? Who complain if something works properly and correctly? > Such is the reality of software :( Hmmm. Fortunately, I haven't ever had such experiences with software :) Regards Miso Ben Allison said: > Winamp 5.2 (currently in beta) will write its tags in UTF-16. Older > versions write, as you said, in the system default encoding. "Encoding > type 0" tags are also read as the system default encoding. > > In the first public beta of Winamp 5.2, it read ASCII tags as ISO-8859-1 > only (the correct way!). After an avalanche of complaints , I had to go > back to the old, bad, behavior. Such is the reality of software :( > > -Ben Allison > >> Last time I was wondering what encoding do WinAMP use to write ID3v1. I >> founded out that it depends on machine, because Winamp uses default >> system >> encoding. However, I was wondering that it also writes ID3v2 in exactly >> the same way! The "encoding" byte of frame indicates that frame text >> should be encoded in ISO-8859-1 (%0), but WinAMP encoded and wrote it in >> my system's default encoding, which seems to be something like "Windows >> 1251". >> Is it possible or do I have hallucination? -- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From iontodirel at yahoo.co.uk Sat Feb 11 12:35:13 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Sat, 11 Feb 2006 20:35:13 +0000 (GMT) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <20060211194608.EEOA14894.gx4.fuse.net@avoca> Message-ID: <20060211203513.14586.qmail@web86905.mail.ukl.yahoo.com> eh, sounds bad, maybe in future we use xml ... but frames are too many... anyway, i have two sugestions: - let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here. - in futere let's create a free ID3.org library for standartisation purpose. Why WMP can using AMG, iTunes, winamp use CDDB, in terms of music info, why not using an library too for read/write info "powered by" ID3.org? So who want to use ID3 she will use a ID3 ID3 library. We can develop using COM, .NET and Java, anywone will be happy. Why just providing a list of library but not create one? "Mitchell S. Honnert" wrote: For what it's worth, here's my two cents... While I think the highly complex, specialized nature of the ID3v2 spec can work against its uniform adoption, I'm not a big fan of a wholesale replacement of the frame collection paradigm with XML. But what about a hybrid? What if the next gen version of ID3 limited itself to a few "base" frame types, one of which was a frame flagged to contain XML? So, to throw out some ideas, these "base" frames might be... TextFrame - what's now the "T" frames i.e. Artist, Title, Album NumberFrame - a strongly typed frame to store numbers i.e. Track Number, Year, Beats Per Minutes, Duration (MS) BinaryFrame - generically store pictures or any BLOB's/GEOB's TextCollectionFrame - a list of text values i.e. Genres DictionaryFrame - a collection of text key/value pairs i.e. Involved People. XMLFrame - basically the same as TextFrame but flagged as storing XML. You'd still have tag ID's to identify what's in each of these frames, but all data would fit into one of the handful of base frames. In designing my ID3 library, I used a set of base classes in an OO hierarchy to minimize the amount of duplicate code I'd have. So, when I'm implementing a new frame, I always begin by thinking "Can I just start off by inheriting one of my existing base Frame classes or do I have to start from scratch?" If the new standard had a small number of these "base" frames -- and relied on the XML frame as a catchall for the more complex metadata -- then implementers could write the base encoding/decoding code for these frames very quickly. It would only be if you needed to access the more complex frames (read "rarely used" frames) that you'd have to parse XML or use a DOM. For example, if this style of ID3 format were in place, the addition of a Chapter frame wouldn't have required the creation of a whole new base frame type. Instead of having to focus on the binary format of this new frame, we would just have had to agree on an XML schema. Sure, anyone implementing this new frame would have had to write new code to handle the specific XML format, but -- here's the important part -- it wouldn't require you to revisit the area of your library where binary parsing is done. "You want to implement a ChapterFrame? Fine, inherit the XMLFrame and parse the (Friend) XMLFrame.XML property." Personally, what my goal for a next generation ID3 standard would be is an elegant combination of support for simple, commonly-used metadata and complex, rarely-used metadata. The basic implementation would be so simple and streamlined that it would promote a uniformity of application. But it would also support complex metadata, if that's what you needed. I think using a small set of "base" frames which included one to support XML could meet this goal. Sure, the current IDv2 can support almost any metadata requirement imaginable, but the learning curve is very steep. In theory this shouldn't matter. In designing a metadata tag format, you shouldn't have to account for bad (but popular) implementations that all but render the standard useless. But in reality, you do have to worry about the learning curve of your format and how it will affect implementation and adoption. Creating something with an "Easy to learn, hard to master" learning curve would go a long way to reducing the number of corrupt implementations. I could go one with my pros (and some of the cons) of this idea, but I've already rambled on too much, so I thought I'd throw this out there for now. Mitchell S. Honnert www.UltraID3Lib.com -----Original Message----- From: Paul Taylor [mailto:paul_t100 at fastmail.fm] Sent: Saturday, February 11, 2006 5:11 AM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 Completely agree XML must be the way to go it would be so much easier to enforcer validation,implement a libray and be able to view directly in a human readable form. MusicBrainz (ww.musicbrainz.org) uses XML RDF to store its track data maybe this could be used as the basis of an XML Format. I know there are a number of formats additional to ID3v2, do any of these already use XML ? Paul Grebenc wrote: > >> Another "problem" with XML is that it is so flexible when it comes to >> the text encoding of the actual document. Having to support so many >> text encodings can be a big problem, especially in the embedded space. > > > The specification could dictate that the tag has to use UTF-8. Or, it > would be just as easy to not dictate that and let anyone use their > preference. As it stands, ID3v2 supports Unicode, but I doubt there > are very many embedded devices that will correctly display anything > outside the standard ASCII character set. There are probably enough > desktop applications that support ID3v2 that won't do the right thing > with Unicode, as it is. > > I don't want to argue this point forever. I just want to express > three opinions: > > 1. Parsing XML without a full-blown parser/DOM support does not have > to be hard. > > 2. A new version should target the embedded devices that will be > designed a few years from now as the minimum embedded platform. > Existing devices aren't going to retroactively support any new > version, regardless of how simple it is, so there's no value in > wondering whether a three year old 32MB keychain player can 'handle it'. > > 3. XML has some disadvantages, but the one enormous advantage it has, > considering that half the traffic on this list is moaning about bad > ID3v2 implementations, is the ability it provides to universally > enforce validation. > > Paul > > --------------------------------------------------------------------- > 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 --------------------------------- Yahoo! Photos ? NEW, now offering a quality print service from just 8p a photo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jid3 at blinkenlights.org Fri Feb 10 18:04:43 2006 From: jid3 at blinkenlights.org (Paul Grebenc) Date: Fri, 10 Feb 2006 21:04:43 -0500 (EST) Subject: [ID3 Dev] 'Extending' ID3 V2.4 Message-ID: >Another "problem" with XML is that it is so flexible when it comes to >the text encoding of the actual document. Having to support so many >text encodings can be a big problem, especially in the embedded space. The specification could dictate that the tag has to use UTF-8. Or, it would be just as easy to not dictate that and let anyone use their preference. As it stands, ID3v2 supports Unicode, but I doubt there are very many embedded devices that will correctly display anything outside the standard ASCII character set. There are probably enough desktop applications that support ID3v2 that won't do the right thing with Unicode, as it is. I don't want to argue this point forever. I just want to express three opinions: 1. Parsing XML without a full-blown parser/DOM support does not have to be hard. 2. A new version should target the embedded devices that will be designed a few years from now as the minimum embedded platform. Existing devices aren't going to retroactively support any new version, regardless of how simple it is, so there's no value in wondering whether a three year old 32MB keychain player can 'handle it'. 3. XML has some disadvantages, but the one enormous advantage it has, considering that half the traffic on this list is moaning about bad ID3v2 implementations, is the ability it provides to universally enforce validation. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From benski at winamp.com Sat Feb 4 11:54:21 2006 From: benski at winamp.com (Ben Allison) Date: Sat, 4 Feb 2006 14:54:21 -0500 (EST) Subject: [ID3 Dev] GEOB In-Reply-To: <20060204194917.PBAW8735.ibm57aec.bellsouth.net@millnermobile> References: <20060204183944.SHVC4722.gx6.fuse.net@avoca> <20060204194917.PBAW8735.ibm57aec.bellsouth.net@millnermobile> Message-ID: <4938.68.100.121.19.1139082861.squirrel@mail.winamp.com> The GEOB frame is awfully generic. What are players supposed to do with it when it's encountered? This seems like a place where specific-to-one-player kind of stuff is going to be stored. -Ben Allison > Are there any commercial players > (software/hardware) that decode the GEOB frame? > > > > Regards, > > Dominick --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Sat Feb 11 12:49:37 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 11 Feb 2006 15:49:37 -0500 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <20060211203513.14586.qmail@web86905.mail.ukl.yahoo.com> Message-ID: <20060211204934.GSQV4651.gx5.fuse.net@avoca> >eh, sounds bad, maybe in future we use xml ... but frames are too many... Why do you think it's a bad idea? Do you mean there are too many frames in the existing standard or in the idea I discussed? (I only gave an example of six base frames.) >- let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here. What about the mailing list don't you like? >Why WMP can using AMG, iTunes, winamp use CDDB, in terms of music info, why not >using an library too for read/write info "powered by" ID3.org? There are groups out there that are already doing this. The two that spring to mind are MusicBrainz and FreeDB. Besides, the scope of id3.org (as I understand it) is to define and promote the standard for imbedding metadata in a file, not to be the *source* of that data. Mitchell S. Honnert www.UltraID3Lib.com _____ From: Ion Todirel [mailto:iontodirel at yahoo.co.uk] Sent: Saturday, February 11, 2006 3:35 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] 'Extending' ID3 V2.4 eh, sounds bad, maybe in future we use xml ... but frames are too many... anyway, i have two sugestions: - let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here. - in futere let's create a free ID3.org library for standartisation purpose. Why WMP can using AMG, iTunes, winamp use CDDB, in terms of music info, why not using an library too for read/write info "powered by" ID3.org? So who want to use ID3 she will use a ID3 ID3 library. We can develop using COM, .NET and Java, anywone will be happy. Why just providing a list of library but not create one? "Mitchell S. Honnert" wrote: For what it's worth, here's my two cents... While I think the highly complex, specialized nature of the ID3v2 spec can work against its uniform adoption, I'm not a big fan of a wholesale replacement of the frame collection paradigm with XML. But what about a hybrid? What if the next gen version of ID3 limited itself to a few "base" frame types, one of which was a frame flagged to contain XML? So, to throw out some ideas, these "base" frames might be... TextFrame - what's now the "T" frames i.e. Artist, Title, Album NumberFrame - a strongly typed frame to store numbers i.e. Track Number, Year, Beats Per Minutes, Duration (MS) BinaryFrame - generically store pictures or any BLOB's/GEOB's TextCollectionFrame - a list of text values i.e. Genres DictionaryFrame - a collection of text key/value pairs i.e. Involved People. XMLFrame - basically the same as TextFrame but flagged as storing XML. You'd still have tag ID's to identify what's in each of these frames, but all data would fit into one of the handful of base frames. In designing my ID3 library, I used a set of base classes in an OO hierarchy to minimize the amount of duplicate code I'd have. So, when I'm implementing a new frame, I always begin by thinking "Can I just start off by inheriting one of my existing base Frame classes or do I have to start from scratch?" If the new standard had a small number of these "base" frames -- and relied on the XML frame as a catchall for the more complex metadata -- then implementers could write the base encoding/decoding code for these frames very quickly. It would only be if you needed to access the more complex frames (read "rarely used" frames) that you'd have to parse XML or use a DOM. For example, if this style of ID3 format were in place, the addition of a Chapter frame wouldn't have required the creation of a whole new base frame type. Instead of having to focus on the binary format of this new frame, we would just have had to agree on an XML schema. Sure, anyone implementing this new frame would have had to write new code to handle the specific XML format, but -- here's the important part -- it wouldn't require you to revisit the area of your library where binary parsing is done. "You want to implement a ChapterFrame? Fine, inherit the XMLFrame and parse the (Friend) XMLFrame.XML property." Personally, what my goal for a next generation ID3 standard would be is an elegant combination of support for simple, commonly-used metadata and complex, rarely-used metadata. The basic implementation would be so simple and streamlined that it would promote a uniformity of application. But it would also support complex metadata, if that's what you needed. I think using a small set of "base" frames which included one to support XML could meet this goal. Sure, the current IDv2 can support almost any metadata requirement imaginable, but the learning curve is very steep. In theory this shouldn't matter. In designing a metadata tag format, you shouldn't have to account for bad (but popular) implementations that all but render the standard useless. But in reality, you do have to worry about the learning curve of your format and how it will affect implementation and adoption. Creating something with an "Easy to learn, hard to master" learning curve would go a long way to reducing the number of corrupt implementations. I could go one with my pros (and some of the cons) of this idea, but I've already rambled on too much, so I thought I'd throw this out there for now. Mitchell S. Honnert www.UltraID3Lib.com -----Original Message----- From: Paul Taylor [mailto:paul_t100 at fastmail.fm] Sent: Saturday, February 11, 2006 5:11 AM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 Completely agree XML must be the way to go it would be so much easier to enforcer validation,implement a libray and be able to view directly in a human readable form. MusicBrainz (ww.musicbrainz.org) uses XML RDF to store its track data maybe this could be used as the basis of an XML Format. I know there are a number of formats additional to ID3v2, do any of these already use XML ? Paul Grebenc wrote: > >> Another "problem" with XML is that it is so flexible when it comes to >> the text encoding of the actual document. Having to support so many >> text encodings can be a big problem, especially in the embedded space. > > > The specification could dictate that the tag has to use UTF-8. Or, it > would be just as easy to not dictate that and let anyone use their > preference. As it stands, ID3v2 supports Unicode, but I doubt there > are very many embedded devices that will correctly display anything > outside the standard ASCII character set. There are probably enough > desktop applications that support ID3v2 that won't do the right thing > with Unicode, as it is. > > I don't want to argue this point forever. I just want to express > three opinions: > > 1. Parsing XML without a full-blown parser/DOM support does not have > to be hard. > > 2. A new version should target the embedded devices that will be > designed a few years from now as the minimum embedded platform. > Existing devices aren't going to retroactively support any new > version, regardless of how simple it is, so there's no value in > wondering whether a three year old 32MB keychain player can 'handle it'. > > 3. XML has some disadvantages, but the one enormous advantage it has, > considering that half the traffic on this list is moaning about bad > ID3v2 implementations, is the ability it provides to universally > enforce validation. > > Paul > > --------------------------------------------------------------------- > 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 _____ Yahoo! Photos - NEW, now offering a quality print service from just 8p a photo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wheeler at kde.org Sat Feb 11 13:02:10 2006 From: wheeler at kde.org (Scott Wheeler) Date: Sat, 11 Feb 2006 22:02:10 +0100 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <20060211194608.EEOA14894.gx4.fuse.net@avoca> References: <20060211194608.EEOA14894.gx4.fuse.net@avoca> Message-ID: <200602112202.10485.wheeler@kde.org> On Saturday 11 February 2006 20:46, Mitchell S. Honnert wrote: This is largely sane, though I think you could generalize things a little more. > So, to throw out some ideas, these "base" frames might be... > > TextFrame - what's now the "T" frames i.e. Artist, Title, Album Sure. > NumberFrame - a strongly typed frame to store numbers i.e. Track Number, > Year, Beats Per Minutes, Duration (MS) This one's arguable. It's not particularly difficult to convert between text and integers as in the current text frames. > BinaryFrame - generically store pictures or any BLOB's/GEOB's See the note in XML below. > TextCollectionFrame - a list of text values i.e. Genres > > DictionaryFrame - a collection of text key/value pairs i.e. Involved > People. I don't see the major difference between these two, and of course the current text frames are capable of doing lists as well. > XMLFrame - basically the same as TextFrame but flagged as storing XML. A GEOB currently isn't limited to binary data -- it's just something with a mime-type. I don't see a reason not to have text/xml as one of those. In terms of getting things implemented, the closer things are to a subset of the current spec in my opinion the better since that would mean that getting momentum behind a new spec would be much easier. -Scott -- There are 10 types of people in the world: Those who understand binary, and those who don't. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From iontodirel at yahoo.co.uk Sat Feb 11 13:20:30 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Sat, 11 Feb 2006 21:20:30 +0000 (GMT) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <20060211204934.GSQV4651.gx5.fuse.net@avoca> Message-ID: <20060211212031.25706.qmail@web86912.mail.ukl.yahoo.com> "Why do you think it?s a bad idea? Do you mean there are too many frames in the existing standard or in the idea I discussed? (I only gave an example of six base frames.)", too many... and xml. "let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here. What about the mailing list don?t you like?", i think that mailing list is a stupid idea, besides if we have a blog many people will be implicated, more more publicity, what we talking about: ID3,org MUST HAVE A BLOG, who is with me?. We can read coments very easy using an RSS Reader. "using an library too for read/write info "powered by" ID3.org? There are groups out there that are already doing this. The two that spring to mind are MusicBrainz and FreeDB. Besides, the scope of id3.org (as I understand it) is to define and promote the standard for imbedding metadata in a file, not to be the *source* of that data." yep right like i sed: a library for read/write info (metadata : data about data) in files "powered by" ID3.org. So if Apple wont to use ID3 standard will use library created by ID3 group. What this mean: a unified standard not only on papers by implemented too. So will not be problems and incompatibility with tags, written by a different id3 library. "Mitchell S. Honnert" wrote: v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} st1\:*{behavior:url(#default#ieooui) } >eh, sounds bad, maybe in future we use xml ... but frames are too many... Why do you think it?s a bad idea? Do you mean there are too many frames in the existing standard or in the idea I discussed? (I only gave an example of six base frames.) >- let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here. What about the mailing list don?t you like? >Why WMP can using AMG, iTunes, winamp use CDDB, in terms of music info, why not >using an library too for read/write info "powered by" ID3.org? There are groups out there that are already doing this. The two that spring to mind are MusicBrainz and FreeDB. Besides, the scope of id3.org (as I understand it) is to define and promote the standard for imbedding metadata in a file, not to be the *source* of that data. Mitchell S. Honnert www.UltraID3Lib.com --------------------------------- From: Ion Todirel [mailto:iontodirel at yahoo.co.uk] Sent: Saturday, February 11, 2006 3:35 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] 'Extending' ID3 V2.4 eh, sounds bad, maybe in future we use xml ... but frames are too many... anyway, i have two sugestions: - let's create a blog, ID3 Blog, in blogspot or another, were we talk about what we talking here. - in futere let's create a free ID3.org library for standartisation purpose. Why WMP can using AMG, iTunes, winamp use CDDB, in terms of music info, why not using an library too for read/write info "powered by" ID3.org? So who want to use ID3 she will use a ID3 ID3 library. We can develop using COM, .NET and Java, anywone will be happy. Why just providing a list of library but not create one? "Mitchell S. Honnert" wrote: For what it's worth, here's my two cents... While I think the highly complex, specialized nature of the ID3v2 spec can work against its uniform adoption, I'm not a big fan of a wholesale replacement of the frame collection paradigm with XML. But what about a hybrid? What if the next gen version of ID3 limited itself to a few "base" frame types, one of which was a frame flagged to contain XML? So, to throw out some ideas, these "base" frames might be... TextFrame - what's now the "T" frames i.e. Artist, Title, Album NumberFrame - a strongly typed frame to store numbers i.e. Track Number, Year, Beats Per Minutes, Duration (MS) BinaryFrame - generically store pictures or any BLOB's/GEOB's TextCollectionFrame - a list of text values i.e. Genres DictionaryFrame - a collection of text key/value pairs i.e. Involved People. XMLFrame - basically the same as TextFrame but flagged as storing XML. You'd still have tag ID's to identify what's in each of these frames, but all data would fit into one of the handful of base frames. In designing my ID3 library, I used a set of base classes in an OO hierarchy to minimize the amount of duplicate code I'd have. So, when I'm implementing a new frame, I always begin by thinking "Can I just start off by inheriting one of my existing base Frame classes or do I have to start from scratch?" If the new standard had a small number of these "base" frames -- and relied on the XML frame as a catchall for the more complex metadata -- then implementers could write the base encoding/decoding code for these frames very quickly. It would only be if you needed to access the more complex frames (read "rarely used" frames) that you'd have to parse XML or use a DOM. For example, if this style of ID3 format were in place, the addition of a Chapter frame wouldn't have required the creation of a whole new base frame type. Instead of having to focus on the binary format of this new frame, we would just have had to agree on an XML schema. Sure, anyone implementing this new frame would have had to write new code to handle the specific XML format, but -- here's the important part -- it wouldn't require you to revisit the area of your library where binary parsing is done. "You want to implement a ChapterFrame? Fine, inherit the XMLFrame and parse the (Friend) XMLFrame.XML property." Personally, what my goal for a next generation ID3 standard would be is an elegant combination of support for simple, commonly-used metadata and complex, rarely-used metadata. The basic implementation would be so simple and streamlined that it would promote a uniformity of application. But it would also support complex metadata, if that's what you needed. I think using a small set of "base" frames which included one to support XML could meet this goal. Sure, the current IDv2 can support almost any metadata requirement imaginable, but the learning curve is very steep. In theory this shouldn't matter. In designing a metadata tag format, you shouldn't have to account for bad (but popular) implementations that all but render the standard useless. But in reality, you do have to worry about the learning curve of your format and how it will affect implementation and adoption. Creating something with an "Easy to learn, hard to master" learning curve would go a long way to reducing the number of corrupt implementations. I could go one with my pros (and some of the cons) of this idea, but I've already rambled on too much, so I thought I'd throw this out there for now. Mitchell S. Honnert www.UltraID3Lib.com -----Original Message----- From: Paul Taylor [mailto:paul_t100 at fastmail.fm] Sent: Saturday, February 11, 2006 5:11 AM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 Completely agree XML must be the way to go it would be so much easier to enforcer validation,implement a libray and be able to view directly in a human readable form. MusicBrainz (ww.musicbrainz.org) uses XML RDF to store its track data maybe this could be used as the basis of an XML Format. I know there are a number of formats additional to ID3v2, do any of these already use XML ? Paul Grebenc wrote: > >> Another "problem" with XML is that it is so flexible when it comes to >> the text encoding of the actual document. Having to support so many >> text encodings can be a big problem, especially in the embedded space. > > > The specification could dictate that the tag has to use UTF-8. Or, it > would be just as easy to not dictate that and let anyone use their > preference. As it stands, ID3v2 supports Unicode, but I doubt there > are very many embedded devices that will correctly display anything > outside the standard ASCII character set. There are probably enough > desktop applications that support ID3v2 that won't do the right thing > with Unicode, as it is. > > I don't want to argue this point forever. I just want to express > three opinions: > > 1. Parsing XML without a full-blown parser/DOM support does not have > to be hard. > > 2. A new version should target the embedded devices that will be > designed a few years from now as the minimum embedded platform. > Existing devices aren't going to retroactively support any new > version, regardless of how simple it is, so there's no value in > wondering whether a three year old 32MB keychain player can 'handle it'. > > 3. XML has some disadvantages, but the one enormous advantage it has, > considering that half the traffic on this list is moaning about bad > ID3v2 implementations, is the ability it provides to universally > enforce validation. > > Paul > > --------------------------------------------------------------------- > 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 --------------------------------- Yahoo! Photos ? NEW, now offering a quality print service from just 8p a photo. --------------------------------- Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with voicemail -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsorensen at gmail.com Tue Feb 28 05:59:58 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Tue, 28 Feb 2006 08:59:58 -0500 Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> Message-ID: <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> 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 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 From rmandarano at danger.com Tue Feb 21 13:39:30 2006 From: rmandarano at danger.com (Ralph Mandarano) Date: Tue, 21 Feb 2006 13:39:30 -0800 Subject: [ID3 Dev] ID3 tag editor for PC Message-ID: Thanks to all for your responses. I'm installing winamp now (soooo long overdue) and I'll check out some of your other suggestions as well. I'm simply looking for an existing program to edit tags on my mp3's so that I can test how they look on my PC as compared to how they look in my player. -R -----Original Message----- From: Kipp Gremillion [mailto:kipp at gremillion.org] Sent: Tuesday, February 21, 2006 1:31 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] ID3 tag editor for PC A recommendation for an editor already created? If so for simple data I like Winamp as already mentioned here. For extended data I love Tag&Rename. _____ From: Ralph Mandarano [mailto:rmandarano at danger.com] Sent: Tuesday, February 21, 2006 3:23 PM To: id3v2 at id3.org Subject: [ID3 Dev] ID3 tag editor for PC Hello all, I've been skulking on this list since October. I'm currently working on a project that is going to read the id3v1 and 2 tags and I'd like to be able to edit both types on my PC. Does anyone have a good recommend for me? When I check out cNet's download offerings I'm overwhelmed by the choices. Any assistance is greatly appreciated. -Ralph -------------- next part -------------- An HTML attachment was scrubbed... URL: From iontodirel at yahoo.co.uk Fri Feb 10 11:01:44 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Fri, 10 Feb 2006 19:01:44 +0000 (GMT) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <55709.195.91.64.54.1139580591.squirrel@195.91.64.54> Message-ID: <20060210190144.39279.qmail@web86915.mail.ukl.yahoo.com> why use a binary representation of data containing in files why just not use xml? and why storing this data inside the files and not providing a unified database for fast access and that will store all needed information? Michal Vician wrote: > ...In this case specifically, I can certainly imagine an ID3 spec > that would be possible to implement completely, with less code, > without reducing the functionality provided. As far as I'm concerned I don't have any problems with code lenght. But if have you any concrete ideas (I mean something like a sketch of new ID3 version), just post them. Maybe we can move ID3 spec forward. Best regards Miso > On Thursday 09 February 2006 22:16, Michal Vician wrote: >> Can't see the merit of deprecating frames. ID3v2 is proposed so frames >> you >> would like to deprecate doesn't limit/restrict you in any way. There is >> no >> need to deprecate them. So why do they annoy you? > > Three notes: > > - I'm mostly just babbling about what I would like to see for an ID3v2.5 > or > ID3v3, so take this as such. I don't actually expect either of those > versions happen since it's been about 5 years since the last ID3 revision. > I > certainly don't expect a 2.4.1 or something to deprecate frames. > > - For the moment I do just ignore them in my implementation. They're > parsed > as an "unknown frame". > > - It's really about complexity and cleanliness. ID3v2 is too complex for > what it achieves (saying this as a person who has implemented several tag > formats). In theory, an ID3 spec could do basically everything that ID3v2 > does now and be much easier to implement completely. > > Basically a spec is only as good as its implementations. If portions of a > spec are wholesale ignored across many implementations, then it's probably > fair to say that the spec is too complicated. In this case specifically, > I > can certainly imagine an ID3 spec that would be possible to implement > completely, with less code, without reducing the functionality provided. > Adding more frames would just, in my opinion, increase the amount of ID3v2 > that would be ignored by implementors. > > Cheers, > > -Scott -- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------- To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wheeler at kde.org Thu Feb 16 14:02:31 2006 From: wheeler at kde.org (Scott Wheeler) Date: Thu, 16 Feb 2006 23:02:31 +0100 Subject: [ID3 Dev] Determining an offset In-Reply-To: <30CE0C8B4E0D0B41928DE8C587C3F375022EA2F7@csifiapp6105.oa.caiso.com> References: <30CE0C8B4E0D0B41928DE8C587C3F375022EA2F7@csifiapp6105.oa.caiso.com> Message-ID: <200602162302.31925.wheeler@kde.org> On Thursday 16 February 2006 20:13, Morton, Christopher wrote: > Please consider the following code (the language doesn't matter) for a > routine that dumps ID3v2 tag data into Excel. As you do, note the binary > offset numbers. My question is, what might be the offset number where > the "album art" flag (1/0) is located? That's a pressing matter for this > exercise (and that's what it is)-to determine if a given MP3 has 1) been > tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. While I must say that I don't really understand the point of the question, the code you pasted (is that Basic? Wow, been a while...) is an ID3v1 implementation, not ID3v2. ID3v1 is trivially easy since all fields are of fixed length and at the end of the file. Not surprisingly, there are no images in ID3v1 tags. -Scott -- Confidence is the feeling you have before you understand the situation. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From benski at winamp.com Sat Feb 4 12:09:05 2006 From: benski at winamp.com (Ben Allison) Date: Sat, 4 Feb 2006 15:09:05 -0500 (EST) Subject: [ID3 Dev] GEOB In-Reply-To: <20060204200239.PFCM8735.ibm57aec.bellsouth.net@millnermobile> References: <4938.68.100.121.19.1139082861.squirrel@mail.winamp.com> <20060204200239.PFCM8735.ibm57aec.bellsouth.net@millnermobile> Message-ID: <4950.68.100.121.19.1139083745.squirrel@mail.winamp.com> If I run into an multimedia MIME type while playing back an MP3, what am I supposed to do? Play the video instead? I'm just not understanding the use case here. -Ben Allison > I'm thinking that if the GEOB frame was limited to specific MIME types, > specifically audio/video formats (MPEG 4 SP, WMV, MP3, etc...) then as > long > as the player supported the format then it would decode the frame. This > would also eliminate developers' reluctance in adding support for the > frame, > because they wouldn't have to worry about unwanted executables/exploits. > This would also eliminate the "specific-to-one player" scenario. > > Regards, > Dominick --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dmillner at bellsouth.net Fri Feb 10 11:33:12 2006 From: dmillner at bellsouth.net (Dominick Millner) Date: Fri, 10 Feb 2006 14:33:12 -0500 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <000601c62e75$f2e0ade0$0500000a@MARVIN> Message-ID: <20060210193309.HAGZ1818.ibm66aec.bellsouth.net@dmizzle> I think that truncating the frames would be the best course of action. ID3v1 was widely supported due to its ease of implementation and provided it audience with information that users felt were useful. The major modification that I could see is adding a multimedia frame as opposed to a generic GEOB, this would allow bundling of additional media types like audio ,video, flash, etc.... (this would also ease their woes into what could be contained in the GEOB frame) Manufacturers are not going to implement a majority of these tags unless there is an actual added value. Many of these tags require information that is very hard to find and that quite frankly many could do without. The XML/database would only benefit internet enabled devices and also without some basic form of tagging how would you identify the mp3 for additional tagging? Dominick -----Original Message----- From: Andy Kernahan [mailto:andrew.kernahan at btinternet.com] Sent: Friday, February 10, 2006 2:13 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 Guys, the ID3v2.4 spec is 5 1/2 years old and most commercial media players still don't support it. Any talk of creating a new ID3 standard (even though it would be nice) is fruitless. Sorry to be so pessimistic. Andy. ----- Original Message ----- From: "Michal Vician" To: Sent: Friday, February 10, 2006 2:09 PM Subject: [Norton AntiSpam] Re: [ID3 Dev] 'Extending' ID3 V2.4 >> ...In this case specifically, I can certainly imagine an ID3 spec >> that would be possible to implement completely, with less code, >> without reducing the functionality provided. > > As far as I'm concerned I don't have any problems with code lenght. > But if have you any concrete ideas (I mean something like a sketch of new > ID3 version), just post them. Maybe we can move ID3 spec forward. > > Best regards > Miso > >> On Thursday 09 February 2006 22:16, Michal Vician wrote: >>> Can't see the merit of deprecating frames. ID3v2 is proposed so frames >>> you >>> would like to deprecate doesn't limit/restrict you in any way. There is >>> no >>> need to deprecate them. So why do they annoy you? >> >> Three notes: >> >> - I'm mostly just babbling about what I would like to see for an ID3v2.5 >> or >> ID3v3, so take this as such. I don't actually expect either of those >> versions happen since it's been about 5 years since the last ID3 >> revision. >> I >> certainly don't expect a 2.4.1 or something to deprecate frames. >> >> - For the moment I do just ignore them in my implementation. They're >> parsed >> as an "unknown frame". >> >> - It's really about complexity and cleanliness. ID3v2 is too complex >> for >> what it achieves (saying this as a person who has implemented several tag >> formats). In theory, an ID3 spec could do basically everything that >> ID3v2 >> does now and be much easier to implement completely. >> >> Basically a spec is only as good as its implementations. If portions of >> a >> spec are wholesale ignored across many implementations, then it's >> probably >> fair to say that the spec is too complicated. In this case specifically, >> I >> can certainly imagine an ID3 spec that would be possible to implement >> completely, with less code, without reducing the functionality provided. >> Adding more frames would just, in my opinion, increase the amount of >> ID3v2 >> that would be ignored by implementors. >> >> Cheers, >> >> -Scott > > > -- > Michal Vician > id3v2 at audiott.com > http://www.audiott.com/ > > > --------------------------------------------------------------------- > 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 From benski at winamp.com Wed Feb 8 09:56:48 2006 From: benski at winamp.com (Ben Allison) Date: Wed, 8 Feb 2006 12:56:48 -0500 Subject: [ID3 Dev] archives? In-Reply-To: <20060208003126.GA12507@ayup.limey.net> References: <200602071041.44778.wheeler@kde.org> <43E8A1A5.6050202@northpb.com> <200602071702.50105.wheeler@kde.org> <20060208003126.GA12507@ayup.limey.net> Message-ID: <43EA30E0.800@winamp.com> > In my mind 2.4 is totally unusable because of the wide variation in > implementation from all the different libraries. Sigh. > > It would be nice if there were a 2.4.1 that clarifies the syncsafeness > so that people can get the support right (ha). > > Also, I would love to see a 2.3.1 which just adds support for UTF-8 to > the valid charsets. 100% AGREED! -Ben Allison --------------------------------------------------------------------- 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 Tue Feb 28 04:15:59 2006 From: bmearns at coe.neu.edu (Brian Mearns) Date: Tue, 28 Feb 2006 07:15:59 -0500 Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <20060228064655.94081.qmail@web86901.mail.ukl.yahoo.com> References: <20060228064655.94081.qmail@web86901.mail.ukl.yahoo.com> Message-ID: <44043EFF.4000001@coe.neu.edu> I think I may have missed something; but the current standard uses the two bytes following the "ID3" identifier to specify the version. Is this a change from that? Ion Todirel wrote: > Thanks for support. ID3 Metadata indentifier (tag > identifier), something like: *ID3v2.x.x*, so you now have not only > a tag identifier, for checking if a file has embedded metadata, but you > also have a tag version stored inside identifier. > > */Michal Vician /* wrote: > > >- structure version (tag version), will be in ID3v2.5 Identifier > * What Identifier? > > > ------------------------------------------------------------------------ > To help you stay safe and secure online, we've developed the all new > *Yahoo! Security Centre* > . > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Sat Feb 25 18:44:27 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 25 Feb 2006 21:44:27 -0500 Subject: [ID3 Dev] Unicode SYLT Message-ID: <20060226024425.JTCI4651.gx5.fuse.net@avoca> I have a question regarding how many Byte Order Markers should be in a frame with Unicode text. According to the ID3v2.3 standard... "Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order." This seems to be pretty straightforward until you try to read a Synchronized Lyrics frame written by Windows Media Player. The standard says that the SYLT frame has (among other fields) a Content Descriptor field and pairs of Lyrics and Timestamp fields. But what's not so clear (at least to me) is if there should be both a BOM at the beginning of the Content Descriptor field and *every instance* of the Lyrics field. The WMP version of the SYLT frame will just place a BOM at the beginning of the Content Descriptor field, but not each instance of the Lyrics field. I can see that this would economize on the frame size, but it still seems to go against the standard. So, in this situation, is Windows Media Player correctly formatting the SYLT frame? Thanks, - Mitchell S. Honnert PS: In my ID3 library, I allow for either scenario, so I'm not losing any lyric text on the read. But I was still curious to see if I was reading the standard correctly or if there were some additional perspectives out there that might shed some light on the situation for me. I'm also wondering if this would warrant placing WMP on the "ID3 Offenders List" that I've been keeping. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From CMorton at caiso.com Thu Feb 16 14:14:14 2006 From: CMorton at caiso.com (Morton, Christopher) Date: Thu, 16 Feb 2006 14:14:14 -0800 Subject: [ID3 Dev] Determining an offset Message-ID: <30CE0C8B4E0D0B41928DE8C587C3F3750291E386@csifiapp6105.oa.caiso.com> Thanks, Scott. I had no idea it was ID3v1. That ends the discussion. The code, incidentally, is WinBatch. Don't knock it 'til you try it. I mean, why struggle with the fine points of astronomical mathematics and curved space when simple addition and a straight line can quickly solve a problem? > Chris -----Original Message----- From: Scott Wheeler [mailto:wheeler at kde.org] Sent: Thursday, February 16, 2006 2:03 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] Determining an offset On Thursday 16 February 2006 20:13, Morton, Christopher wrote: > Please consider the following code (the language doesn't matter) for a > routine that dumps ID3v2 tag data into Excel. As you do, note the binary > offset numbers. My question is, what might be the offset number where > the "album art" flag (1/0) is located? That's a pressing matter for this > exercise (and that's what it is)-to determine if a given MP3 has 1) been > tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. While I must say that I don't really understand the point of the question, the code you pasted (is that Basic? Wow, been a while...) is an ID3v1 implementation, not ID3v2. ID3v1 is trivially easy since all fields are of fixed length and at the end of the file. Not surprisingly, there are no images in ID3v1 tags. -Scott -- Confidence is the feeling you have before you understand the situation. --------------------------------------------------------------------- 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 From rmanson at gracenote.com Mon Feb 27 16:16:32 2006 From: rmanson at gracenote.com (Robert Manson) Date: Mon, 27 Feb 2006 16:16:32 -0800 Subject: [ID3 Dev] ID3v2.5 Message-ID: <27905705A869164CBE58B96BA8547557036592AC@mail.internal.cddb.com> Actually its very common for a user to edit the tags of there MP3 files. If there is no padding then a complete rewrite of file is necessary if the size of the tag has increased or decreased. -----Original Message----- From: Michal Vician [mailto:id3v2 at audiott.com] Sent: Monday, February 27, 2006 3:32 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] ID3v2.5 > 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 From rmanson at gracenote.com Fri Feb 10 15:58:27 2006 From: rmanson at gracenote.com (Robert Manson) Date: Fri, 10 Feb 2006 15:58:27 -0800 Subject: [ID3 Dev] 'Extending' ID3 V2.4 Message-ID: <27905705A869164CBE58B96BA8547557269F1F@mail.internal.cddb.com> Another "problem" with XML is that it is so flexible when it comes to the text encoding of the actual document. Having to support so many text encodings can be a big problem, especially in the embedded space. Some things I would like to see in a new ID3 version: 1. Tags at the end of the file, perhaps directly above an IDv1 tag 2. No binary data, thus avoiding the need for an unsyncronization scheme 3. One UTF* text encoding format, perhaps one that does not require unsyncronization, UTF-7? 4. Simple key-value pairing whereby ID3 recognizes a set of standard keys but allows room for custom keys (ie TXXX). -Rob -----Original Message----- From: Paul Grebenc [mailto:jid3 at blinkenlights.org] Sent: Friday, February 10, 2006 3:24 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 >- This would require implementers to include an XML parsing engine. ... >- XML is hierarchical rather than linear. All tagging formats that ... This is not entirely true. Granted, an XML document is hierarchical, and you can load it into a DOM and pull what you need from it, but you can also read it sequentially, in the same manner in which a V2 tag is read. This would leave it up to the implementation whether it wants to load a DOM or not. In fact, a legitimate XML parsing engine would not even be necessary, so long as tag names were recognizable, and the content within them was known. As far as reading, an XML document has the potential to be as easy to read as an ID3 v2 tag. What XML would offer is the possibility to use a full parser with DOM in tag editing applications. With a formal schema, there would be no need for a 'reference implementation'. If your document validates against the public schema for that version, it is valid. If it doesn't, it is not. Paul --------------------------------------------------------------------- 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 From id3v2 at northpb.com Tue Feb 7 05:33:25 2006 From: id3v2 at northpb.com (Dan O'Neill) Date: Tue, 07 Feb 2006 05:33:25 -0800 Subject: [ID3 Dev] archives? In-Reply-To: <200602071041.44778.wheeler@kde.org> References: <200602071041.44778.wheeler@kde.org> Message-ID: <43E8A1A5.6050202@northpb.com> Scott Wheeler wrote: > I just noticed that the list is apparently alive again; it died a few years > back and apparently when brought back didn't keep the subscribers list. > > Does anyone know if there's a set of archives available? I'd just like to see > if there's anything terribly important that's crossed over the list of late. Hi Scott, Welcome back, glad you found the list again. It was revived about a year ago. There are archives for that time period, I've just not had the motivation or time to put them up in a web interface. Topics over the last year of interest: - Chapter and Table of Contents Frame defined, version 1.0 frame definition released. http://www.id3.org/develop.html - General discussion of tag incompatibilities v2.3 v. v2.4 - General discussion of players and tag writers that don't follow the "standard" - Syncsafe integer definitions in v2.4 - New library implementation for .NET http://www.id3.org/implement.html And other assorted tag formatting/content definition questions. I'll try to make time to put up the archive in the next few weeks. dano --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From lorax1284 at gmail.com Thu Feb 9 10:26:32 2006 From: lorax1284 at gmail.com (Ryan Germann) Date: Thu, 09 Feb 2006 13:26:32 -0500 Subject: [ID3 Dev] "Extending" ID3 V2.4 Message-ID: <43EB8958.4090504@sympatico.ca> Hi; I'm new to this list... are there standard ways to suggest new ID3 frames? Is ID3 extendable in some prescribed way? I see at: http://www.id3.org/develop.html The subsection named: Additional standards So extra frames are being put forward to support Chapters & their TOCs... but if I have my own ideas, what is the procedure for suggesting them? Thanks --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dmillner at bellsouth.net Sat Feb 4 11:49:36 2006 From: dmillner at bellsouth.net (Dominick Millner) Date: Sat, 4 Feb 2006 14:49:36 -0500 Subject: [ID3 Dev] GEOB In-Reply-To: <20060204183944.SHVC4722.gx6.fuse.net@avoca> Message-ID: <20060204194917.PBAW8735.ibm57aec.bellsouth.net@millnermobile> I used Tag Clinic 4.2. I successfully added a wav file to a GEOB frame and it played fine in WMP 10 (albeit no access to the wav file). However, MP3 encapsulated with the video file crashed. It might have been due to an unsupported MIME Type. Are there any commercial players (software/hardware) that decode the GEOB frame? Regards, Dominick _____ From: Mitchell S. Honnert [mailto:mitch at honnert.com] Sent: Saturday, February 04, 2006 1:40 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] GEOB >I tagged an MP3 and added a small video clip in the GEOB frame and received the dreaded "uncompressed header" error in Windows Media Player 10. What did you use to insert the GEOB frame into the tag? WMP is admittedly very finicky about illformatted frames, but perhaps the root problem is the creation of a non-standard GEOB frame. I tested playing an MP3 which I knew contained an ID3v2.3 GEOB frame and it played fine. >With that being said, are these devices capable of reading the data contained in the GEOB frame? >What precautions need to be taken during tagging to ensure this data can be accessed? You can ensure that the GEOB and other less commonly used frames are in the standard format, but it's really up to the developers of the MP3 player software to decode those frames. (You can lead a horse to water, but you can't make him drink.) You can support ID3, but not fully support every single frame referenced in the standard. HTH Mitchell S. Honnert www.UltraID3Lib.com _____ From: Dominick Millner [mailto:dmillner at bellsouth.net] Sent: Saturday, February 04, 2006 1:03 PM To: id3v2 at id3.org Subject: [ID3 Dev] GEOB I've noticed several commercial portable MP3 players claiming support for id3v2.4.0. With that being said, are these devices capable of reading the data contained in the GEOB frame? What precautions need to be taken during tagging to ensure this data can be accessed? I tagged an MP3 and added a small video clip in the GEOB frame and received the dreaded "uncompressed header" error in Windows Media Player 10. I feel this frame could be the future of tagging, however the abuse of this frame (executing malicious code) could stop it before it even starts. Regards, Dominick -------------- next part -------------- An HTML attachment was scrubbed... URL: From jid3 at blinkenlights.org Fri Feb 10 15:23:44 2006 From: jid3 at blinkenlights.org (Paul Grebenc) Date: Fri, 10 Feb 2006 18:23:44 -0500 (EST) Subject: [ID3 Dev] 'Extending' ID3 V2.4 Message-ID: >- This would require implementers to include an XML parsing engine. ... >- XML is hierarchical rather than linear. All tagging formats that ... This is not entirely true. Granted, an XML document is hierarchical, and you can load it into a DOM and pull what you need from it, but you can also read it sequentially, in the same manner in which a V2 tag is read. This would leave it up to the implementation whether it wants to load a DOM or not. In fact, a legitimate XML parsing engine would not even be necessary, so long as tag names were recognizable, and the content within them was known. As far as reading, an XML document has the potential to be as easy to read as an ID3 v2 tag. What XML would offer is the possibility to use a full parser with DOM in tag editing applications. With a formal schema, there would be no need for a 'reference implementation'. If your document validates against the public schema for that version, it is valid. If it doesn't, it is not. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From CMorton at caiso.com Thu Feb 16 13:54:29 2006 From: CMorton at caiso.com (Morton, Christopher) Date: Thu, 16 Feb 2006 13:54:29 -0800 Subject: [ID3 Dev] Determining an offset Message-ID: <30CE0C8B4E0D0B41928DE8C587C3F3750291E384@csifiapp6105.oa.caiso.com> Well, yeah, been there. I'm wanting the no-brainer approach; you folks have been down this road before. If the author of the code I submitted (not me) is able to so-easily find the binary offsets of all the other tag data, then why not the frame offset containing the album art YES/NO indicator? Thanks -----Original Message----- From: Brian Mearns [mailto:bmearns at coe.neu.edu] Sent: Thursday, February 16, 2006 1:35 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] Determining an offset I'm sure others can give a better answer, but the ID3Tag is broken into Frames. Each frame has a frame title that identifies what data is stored in the frame and how to parse it. It has some other header information in the frame, and then the frame data. The Album art frame is one such frame, and there is no set location for it. Frames can be in any order. I don't see any other option than to parse the whole tag and just look for the appropriate frame, and identified by the frame title. That's not to say you have to parse every frame, you just need to parse the first however many bytes (8?) to determine it's size and frame title, and then you can skip over the rest of the frame to the next one. You'll probably want to look at the Informal Standard: http://www.id3.org/id3v2.3.0.html, it will tell you how to determine the frame size for each frame, and what the frame title for the album art frame is. Good luck, I hope that answers your question. -Brian Morton, Christopher wrote: > Hello, > > Please consider the following code (the language doesn't matter) for a > routine that dumps ID3v2 tag data into Excel. As you do, note the binary > offset numbers. My question is, what might be the offset number where > the "album art" flag (1/0) is located? That's a pressing matter for this > exercise (and that's what it is)-to determine if a given MP3 has 1) been > tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. > > >>Chris Morton > > > ;;START CODE > ;; BinaryPeekStr extracts a string from a binary buffer (handle, offset, > maxsize) > ;; BinaryPeek returns the 8-bit value of a byte from a binary buffer > > bb = BinaryAlloc(150) > ThisFile = ItemExtract(FileIndex, List, @TAB) > size = FileSize(ThisFile) > BinaryReadEx(bb, 0, ThisFile, size - 128, 128) > id3 = BinaryPeekStr(bb, 0, 3) > If id3 == "TAG" > > song_title = StrTrim(BinaryPeekStr(bb, 3, 30)) > DDEPoke(channel1, "R%row%C2", song_title) > > artist_name = StrTrim(BinaryPeekStr(bb, 33, 30)) > DDEPoke(channel1, "R%row%C3", artist_name) > > album_name = StrTrim(BinaryPeekStr(bb, 63, 30)) > DDEPoke(channel1, "R%row%C4", album_name) > > album_label = "Not Present" > DDEPoke(channel1, "R%row%C5", album_label) > > album_pub_date = StrTrim(BinaryPeekStr(bb, 93, 4)) > DDEPoke(channel1, "R%row%C6", album_pub_date) > > album_type_desc = "Not Present" > DDEPoke(channel1, "R%row%C7", album_type_desc) > > genre = StrTrim(BinaryPeek(bb, 127)) > DDEPoke(channel1, "R%row%C8", genre) > > EndIf > > > --------------------------------------------------------------------- > 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 From wheeler at kde.org Fri Feb 10 11:25:14 2006 From: wheeler at kde.org (Scott Wheeler) Date: Fri, 10 Feb 2006 20:25:14 +0100 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <000601c62e75$f2e0ade0$0500000a@MARVIN> References: <43EB8958.4090504@sympatico.ca> <55709.195.91.64.54.1139580591.squirrel@195.91.64.54> <000601c62e75$f2e0ade0$0500000a@MARVIN> Message-ID: <200602102025.15763.wheeler@kde.org> On Friday 10 February 2006 20:12, Andy Kernahan wrote: > the ID3v2.4 spec is 5 1/2 years old and most commercial media players still > don't support it. > Any talk of creating a new ID3 standard (even though it would be nice) is > fruitless. I agree actually. I tried to prefix my babbling with such. :-) -Scott -- Peace and humptiness forever. --Digital Underground --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From maillist at steelskies.com Wed Feb 22 01:56:47 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Wed, 22 Feb 2006 09:56:47 +0000 Subject: [ID3 Dev] "ID3 Offenders" Part 2 In-Reply-To: <001901c63732$c57c7bc0$df010105@kendle.com> References: <001901c63732$c57c7bc0$df010105@kendle.com> Message-ID: iTunes doesn't use syncsafe integers when writing v2.4 sizes, which is a pretty major problem... On 21 Feb 2006, at 22:04, Mitchell S. Honnert wrote: > A few weeks ago now, I solicited this list for 'ID3 Offenders", > examples of applications, libraries, or encoders that somehow > didn't comply with the ID3 standard. I got some great feedback and > compiled the entries in a single list. There was some talk at the > time of adding this list to www.id3.org, but I haven't seen an > update. So in the mean time, I posted the list to my ID3 library's > page. For those who weren't on the list at the time or for people > who just want to check out what I have so far, here's a direct link > to the list... > http://home.fuse.net/honnert/hundred/UltraID3Lib/offenders/ > > If you have anything to add or correct, I'm thinking the most > appropriate thing to do is to reply back to this list. (Disregard > the link to my forum on the page.) I can update my list and if we > ever want to create a similar page on www.id3.org, we can use it as > a starting point. My personal goal is to shame some of these > developers into compliance, so obviously this would have more of an > impact if the list were on www.id3.org, but I'll keep my list going > if that isn't the right venue. > > One small note: I've been testing some of the betas of the next > version of WinAmp and it looks like they're cleaning up some of the > ID3 issues. Woohoo! > > - Mitchell S. Honnert > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2114 bytes Desc: not available URL: From fiji at ayup.limey.net Tue Feb 7 16:33:04 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 7 Feb 2006 19:33:04 -0500 Subject: [ID3 Dev] archives? In-Reply-To: <43E8D6DC.1090404@northpb.com> References: <200602071041.44778.wheeler@kde.org> <43E8A1A5.6050202@northpb.com> <200602071702.50105.wheeler@kde.org> <43E8D6DC.1090404@northpb.com> Message-ID: <20060208003304.GB12507@ayup.limey.net> On Tue, Feb 07, 2006 at 09:20:28AM -0800, Dan O'Neill wrote: > Scott Wheeler wrote: > > Hey - I know someone from Apple is on this list. Can you help get > iTune's tags fixed? Just to clarify, I suspect it is a quicktime library error and not exactly iTunes' fault. Nonetheless, it is an Apple issue. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dmillner at bellsouth.net Sat Feb 4 12:02:58 2006 From: dmillner at bellsouth.net (Dominick Millner) Date: Sat, 4 Feb 2006 15:02:58 -0500 Subject: [ID3 Dev] GEOB In-Reply-To: <4938.68.100.121.19.1139082861.squirrel@mail.winamp.com> Message-ID: <20060204200239.PFCM8735.ibm57aec.bellsouth.net@millnermobile> I'm thinking that if the GEOB frame was limited to specific MIME types, specifically audio/video formats (MPEG 4 SP, WMV, MP3, etc...) then as long as the player supported the format then it would decode the frame. This would also eliminate developers' reluctance in adding support for the frame, because they wouldn't have to worry about unwanted executables/exploits. This would also eliminate the "specific-to-one player" scenario. Regards, Dominick -----Original Message----- From: Ben Allison [mailto:benski at winamp.com] Sent: Saturday, February 04, 2006 2:54 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] GEOB The GEOB frame is awfully generic. What are players supposed to do with it when it's encountered? This seems like a place where specific-to-one-player kind of stuff is going to be stored. -Ben Allison > Are there any commercial players > (software/hardware) that decode the GEOB frame? > > > > Regards, > > Dominick --------------------------------------------------------------------- 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 From id3v2 at audiott.com Thu Feb 9 13:16:26 2006 From: id3v2 at audiott.com (Michal Vician) Date: Thu, 9 Feb 2006 22:16:26 +0100 (CET) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <200602092005.49739.wheeler@kde.org> References: <43EB8958.4090504@sympatico.ca> <200602092005.49739.wheeler@kde.org> Message-ID: <52134.195.91.64.54.1139519786.squirrel@195.91.64.54> > As an implementer of ID3v2 I would prefer to see more frames deprecated > rather than additional added. In my experience the majority of the frames > spec is ignored anyway if not by library developers then by application > developers. Can't see the merit of deprecating frames. ID3v2 is proposed so frames you would like to deprecate doesn't limit/restrict you in any way. There is no need to deprecate them. So why do they annoy you? Regards Miso > On Thursday 09 February 2006 19:26, Ryan Germann wrote: >> Hi; I'm new to this list... are there standard ways to suggest new ID3 >> frames? Is ID3 extendable in some prescribed way? >> >> I see at: >> >> http://www.id3.org/develop.html >> >> The subsection named: >> >> Additional standards >> >> So extra frames are being put forward to support Chapters & their >> TOCs... but if I have my own ideas, what is the procedure for suggesting >> them? > > I would say for most cases a user defined text frame is sufficient: > > http://www.id3.org/id3v2.4.0-frames.txt - Section 4.2.6 > > As an implementer of ID3v2 I would prefer to see more frames deprecated > rather > than additional added. In my experience the majority of the frames spec > is > ignored anyway if not by library developers then by application > developers. > > Anyone ever seen an application that handles "Synched tempo codes" frame? > How > about "Group identification registration"? I'd put most of the defined > frames into the unused category. > > I think most of the usefulness of ID3v2 could be reduced to text > identification frames and GEOB ("generic encapsulated object") frames with > some agreement on some standardized frames. > > There's a certain amount of elegance to the Vorbis comments for instance > which > are simple key-value pairs. TagLib's implementation of Vorbis comments is > about 250 lines of code in 2 source files, as compared to the (incomplete) > ID3v2 implementation which is about 2500 in 26 files. And really the only > thing that I miss in Vorbis is the ability to store binary data (which > GEOB, > since it includes mime-types would be quite suitable for) and padding. > > But that's mostly just ranting. I think the simple answer to your > question is > that either a TXXX or a GEOB frame will probably do that trick. I may be > off > on the current trends in the ID3v2 world, having been away from the list > for > a while, but I don't seriously expect significant changes to the standards > in > the near future. > > -Scott -- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Tue Feb 7 08:02:49 2006 From: wheeler at kde.org (Scott Wheeler) Date: Tue, 7 Feb 2006 17:02:49 +0100 Subject: [ID3 Dev] archives? In-Reply-To: <43E8A1A5.6050202@northpb.com> References: <200602071041.44778.wheeler@kde.org> <43E8A1A5.6050202@northpb.com> Message-ID: <200602071702.50105.wheeler@kde.org> On Tuesday 07 February 2006 14:33, Dan O'Neill wrote: [...snip...] > - General discussion of players and tag writers that don't > follow the "standard" > > - Syncsafe integer definitions in v2.4 Seeing those two together today is kind of funny since I noticed just yesterday that in Apple's recent switch to ID3v2.4 they ignore the sync-safe integers portion of the spec resulting in all frame sizes over 128 bytes being misrepresented. > - New library implementation for .NET > http://www.id3.org/implement.html I don't really care if it's mentioned on the page or not, but potentially also of interest is TagLib (http://developer.kde.org/~wheeler/taglib.html) as it's used by a couple dozen applications, has several language bindings and a significant portion of 2.4 implemented (there are several frame types that aren't parsed by it, mostly because they're rare and in my opinion largely uninteresting). Anyway -- glad to see that the list is back up and going. Cheers, -Scott -- The fact that an opinion has been widely held is no evidence whatever that it is not utterly absurd. --Bertrand Russell --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dmillner at bellsouth.net Sat Feb 4 12:21:40 2006 From: dmillner at bellsouth.net (Dominick Millner) Date: Sat, 4 Feb 2006 15:21:40 -0500 Subject: [ID3 Dev] GEOB In-Reply-To: <4950.68.100.121.19.1139083745.squirrel@mail.winamp.com> Message-ID: <20060204202121.PKQI8735.ibm57aec.bellsouth.net@millnermobile> Give users the option to play it. Player reads the headers and then catalogs all files in GEOB frames. Users would have the option of playing these additional files through a menu system. Bundling of additional audio and video content would be fantastic. Regards, Dominick -----Original Message----- From: Ben Allison [mailto:benski at winamp.com] Sent: Saturday, February 04, 2006 3:09 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] GEOB If I run into an multimedia MIME type while playing back an MP3, what am I supposed to do? Play the video instead? I'm just not understanding the use case here. -Ben Allison > I'm thinking that if the GEOB frame was limited to specific MIME types, > specifically audio/video formats (MPEG 4 SP, WMV, MP3, etc...) then as > long > as the player supported the format then it would decode the frame. This > would also eliminate developers' reluctance in adding support for the > frame, > because they wouldn't have to worry about unwanted executables/exploits. > This would also eliminate the "specific-to-one player" scenario. > > Regards, > Dominick --------------------------------------------------------------------- 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 From Silas at Sonoroussound.com Tue Feb 21 13:27:43 2006 From: Silas at Sonoroussound.com (Silas Pradetto) Date: Tue, 21 Feb 2006 16:27:43 -0500 Subject: [ID3 Dev] ID3 tag editor for PC In-Reply-To: Message-ID: <000301c6372d$a7e38680$9706a8c0@silas> Model your editor after winamp's look at winamp.com, if you're looking for code, I don't have any. _____ From: Ralph Mandarano [mailto:rmandarano at danger.com] Sent: Tuesday, February 21, 2006 4:23 PM To: id3v2 at id3.org Subject: [ID3 Dev] ID3 tag editor for PC Hello all, I've been skulking on this list since October. I'm currently working on a project that is going to read the id3v1 and 2 tags and I'd like to be able to edit both types on my PC. Does anyone have a good recommend for me? When I check out cNet's download offerings I'm overwhelmed by the choices. Any assistance is greatly appreciated. -Ralph -------------- next part -------------- An HTML attachment was scrubbed... URL: From jid3 at blinkenlights.org Fri Feb 10 11:17:01 2006 From: jid3 at blinkenlights.org (Paul Grebenc) Date: Fri, 10 Feb 2006 14:17:01 -0500 (EST) Subject: [ID3 Dev] 'Extending' ID3 V2.4 Message-ID: >why use a binary representation of data containing in files why just >not use xml? and why storing this data inside the files and not >providing a unified database for fast access and that will store all >needed information? I'd also like to see XML used for a new version. There is the argument that the tag can contain binary data, but it can be base64 encoded. The increase in size is not that dramatic, and in practice, you've got to expect an increase in file size in any case, if you plan to attach a 2MB image to a 3MB MP3 file. In practice, I don't think this would be a problem. As for embedded devices, the world is advancing, and it will soon be (if it isn't already in cases) easier to deal with XML and unencoding base64'ed images, than it is to write code specific to a proprietary binary format. (And v2.3.0 already exists, just as v1.1 does, for legacy devices.) I fully agree that there are too many tag types in v2. Too many of them are too esoteric, and/or badly designed (RVAD: Why is the number of bytes per adjustment variable, when 2^16 levels of adjustment are far, far more than enough. And this in a tag you'll probably never see in the wild.). Using XML would also allow for such niceties as the provision of standard schemas and transformations, for validating tags and upgrading to newer versions. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From iontodirel at yahoo.co.uk Mon Feb 27 22:46:55 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Tue, 28 Feb 2006 06:46:55 +0000 (GMT) Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <16156.195.91.64.54.1141082860.squirrel@195.91.64.54> Message-ID: <20060228064655.94081.qmail@web86901.mail.ukl.yahoo.com> Thanks for support. ID3 Metadata indentifier (tag identifier), something like: ID3v2.x.x, so you now have not only a tag identifier, for checking if a file has embedded metadata, but you also have a tag version stored inside identifier. Michal Vician wrote: >- structure version (tag version), will be in ID3v2.5 Identifier * What Identifier? --------------------------------- To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From CMorton at caiso.com Thu Feb 16 11:13:53 2006 From: CMorton at caiso.com (Morton, Christopher) Date: Thu, 16 Feb 2006 11:13:53 -0800 Subject: [ID3 Dev] Determining an offset Message-ID: <30CE0C8B4E0D0B41928DE8C587C3F375022EA2F7@csifiapp6105.oa.caiso.com> Hello, Please consider the following code (the language doesn't matter) for a routine that dumps ID3v2 tag data into Excel. As you do, note the binary offset numbers. My question is, what might be the offset number where the "album art" flag (1/0) is located? That's a pressing matter for this exercise (and that's what it is)-to determine if a given MP3 has 1) been tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. > Chris Morton ;;START CODE ;; BinaryPeekStr extracts a string from a binary buffer (handle, offset, maxsize) ;; BinaryPeek returns the 8-bit value of a byte from a binary buffer bb = BinaryAlloc(150) ThisFile = ItemExtract(FileIndex, List, @TAB) size = FileSize(ThisFile) BinaryReadEx(bb, 0, ThisFile, size - 128, 128) id3 = BinaryPeekStr(bb, 0, 3) If id3 == "TAG" song_title = StrTrim(BinaryPeekStr(bb, 3, 30)) DDEPoke(channel1, "R%row%C2", song_title) artist_name = StrTrim(BinaryPeekStr(bb, 33, 30)) DDEPoke(channel1, "R%row%C3", artist_name) album_name = StrTrim(BinaryPeekStr(bb, 63, 30)) DDEPoke(channel1, "R%row%C4", album_name) album_label = "Not Present" DDEPoke(channel1, "R%row%C5", album_label) album_pub_date = StrTrim(BinaryPeekStr(bb, 93, 4)) DDEPoke(channel1, "R%row%C6", album_pub_date) album_type_desc = "Not Present" DDEPoke(channel1, "R%row%C7", album_type_desc) genre = StrTrim(BinaryPeek(bb, 127)) DDEPoke(channel1, "R%row%C8", genre) EndIf --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at audiott.com Mon Feb 27 15:31:47 2006 From: id3v2 at audiott.com (Michal Vician) Date: Tue, 28 Feb 2006 00:31:47 +0100 (CET) Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> Message-ID: <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> > 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 From id3v2 at audiott.com Tue Feb 28 06:58:55 2006 From: id3v2 at audiott.com (Michal Vician) Date: Tue, 28 Feb 2006 15:58:55 +0100 (CET) Subject: [ID3 Dev] ID3v2.5 Message-ID: <31294.195.91.64.52.1141138735.squirrel@195.91.64.52> Thank you for explaining. Now I agree that padding is essential too. ----------------------------- Original message --------------------------- Predmet: Re: [ID3 Dev] ID3v2.5 Od: "Tom Sorensen" D?tum: Tue, Febru?r 28, 2006 3:41 pm Komu: id3v2 at id3.org -------------------------------------------------------------------------- There's that, there's issues of finding the tag (if a tag is variable length, then it's a lot easier to find it at the start than somewhere in the tail; not that it's a huge issue anyway). Note that you cannot put it after the ID3v1 tag -- that violates the ID3v1 standard (which states that the tag is the last 128 bytes). It must occur before that tag. And while I didn't mention this, realize that dropping synchsafe integers will cause issues. Any older hardware that isn't aware of ID3v2 tags may treat the tag as audio data, creating static for the end user. There's a *lot* of devices out there (particularly in-dash CD/MP3 players and portable CD/MP3 players) that this is applicable to. Worst case, it could crash the device since the data is very much not audio data. Newer devices at least recognize ID3v2 tags at the start of the file and skip the entire tag body. They're unlikely to skip most end tags other than ID3v1 (such as APEv2, ID3v2.4 footer, etc) though -- again, unless they are coded to recognize them. Most aren't. Tom On 2/28/06, Jonathan del Strother wrote: > > On 28 Feb 2006, at 14:24, Michal Vician wrote: > > >> 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***. > > > > Well, wouldn't it be better to save id3v2 tag to the end to the file (rigth after the ID3v1)? I'm pretty new to this mailing list (only half a > > year) and I really can't imagine why is ID3v2 tag stored at the very beginning of file. Can anybody explain, please? > > > I believe this is purely a benefit for streaming mp3s, where you don't necessarily have the end of the file by the time you start playing. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From tsorensen at gmail.com Tue Feb 21 13:30:50 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Tue, 21 Feb 2006 16:30:50 -0500 Subject: [ID3 Dev] ID3 tag editor for PC In-Reply-To: References: Message-ID: <4da424620602211330he27d569u15166ccedc512024@mail.gmail.com> Three free options, one pay option: EasyTag -- The 1.99.xx development branch is now compiled for Windows natively. http://easytag.sourceforge.net/ MP3Tag -- http://www.mp3tag.de/en/ The Godfather -- http://www.softpedia.com/get/Multimedia/Audio/Tag-Editors/The-GodFather.shtml Tag&Rename -- http://www.softpointer.com/ (not free) I've used all of them (well, only used the 1.1x of EasyTag) and they're all quite good. On 2/21/06, Ralph Mandarano wrote: > > > > Hello all, > > > > I've been skulking on this list since October. I'm currently working on a > project that is going to read the id3v1 and 2 tags and I'd like to be able > to edit both types on my PC. Does anyone have a good recommend for me? > When I check out cNet's download offerings I'm overwhelmed by the choices. > > > > Any assistance is greatly appreciated. > > > > -Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Tue Feb 21 14:04:22 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Tue, 21 Feb 2006 17:04:22 -0500 Subject: [ID3 Dev] "ID3 Offenders" Part 2 References: Message-ID: <001901c63732$c57c7bc0$df010105@kendle.com> A few weeks ago now, I solicited this list for 'ID3 Offenders", examples of applications, libraries, or encoders that somehow didn't comply with the ID3 standard. I got some great feedback and compiled the entries in a single list. There was some talk at the time of adding this list to www.id3.org, but I haven't seen an update. So in the mean time, I posted the list to my ID3 library's page. For those who weren't on the list at the time or for people who just want to check out what I have so far, here's a direct link to the list... http://home.fuse.net/honnert/hundred/UltraID3Lib/offenders/ If you have anything to add or correct, I'm thinking the most appropriate thing to do is to reply back to this list. (Disregard the link to my forum on the page.) I can update my list and if we ever want to create a similar page on www.id3.org, we can use it as a starting point. My personal goal is to shame some of these developers into compliance, so obviously this would have more of an impact if the list were on www.id3.org, but I'll keep my list going if that isn't the right venue. One small note: I've been testing some of the betas of the next version of WinAmp and it looks like they're cleaning up some of the ID3 issues. Woohoo! - Mitchell S. Honnert -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at audiott.com Sun Feb 12 09:50:12 2006 From: id3v2 at audiott.com (Michal Vician) Date: Sun, 12 Feb 2006 18:50:12 +0100 (CET) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: References: Message-ID: <52791.195.91.64.52.1139766612.squirrel@195.91.64.52> > The specification could dictate that the tag has to use UTF-8. Or, it > would be just as easy to not dictate that and let anyone use their > preference. As it stands, ID3v2 supports Unicode, but I doubt there are > very many embedded devices that will correctly display anything outside > the standard ASCII character set. There are probably enough desktop > applications that support ID3v2 that won't do the right thing with > Unicode, as it is. I would rather if spec "dictates" that tag has to use UNICODE and UTF-8 only. Yes, you are right saying that there are many devices that won't correctly display it, but as you can see these devices and also many applications break more things in standard - they even corrupt frames,... - see http://home.fuse.net/honnert/hundred/?UltraID3Lib. In my opinion if an application can't parse UNICODE text, it's only the problem of it's author and should solve it as soon as possible. Regards. Miso --- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From iontodirel at yahoo.co.uk Sat Feb 11 12:14:33 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Sat, 11 Feb 2006 20:14:33 +0000 (GMT) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <27905705A869164CBE58B96BA8547557269F1F@mail.internal.cddb.com> Message-ID: <20060211201433.75623.qmail@web86902.mail.ukl.yahoo.com> ..... ... What i wont to say is that we can use encoding, different with the entire xml encoding to atribute level. We put the standard Unicode, for XML document, but some atributes we can interpret as ASCII or other encoding. Robert Manson wrote: Another "problem" with XML is that it is so flexible when it comes to the text encoding of the actual document. Having to support so many text encodings can be a big problem, especially in the embedded space. Some things I would like to see in a new ID3 version: 1. Tags at the end of the file, perhaps directly above an IDv1 tag 2. No binary data, thus avoiding the need for an unsyncronization scheme 3. One UTF* text encoding format, perhaps one that does not require unsyncronization, UTF-7? 4. Simple key-value pairing whereby ID3 recognizes a set of standard keys but allows room for custom keys (ie TXXX). -Rob -----Original Message----- From: Paul Grebenc [mailto:jid3 at blinkenlights.org] Sent: Friday, February 10, 2006 3:24 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 >- This would require implementers to include an XML parsing engine. ... >- XML is hierarchical rather than linear. All tagging formats that ... This is not entirely true. Granted, an XML document is hierarchical, and you can load it into a DOM and pull what you need from it, but you can also read it sequentially, in the same manner in which a V2 tag is read. This would leave it up to the implementation whether it wants to load a DOM or not. In fact, a legitimate XML parsing engine would not even be necessary, so long as tag names were recognizable, and the content within them was known. As far as reading, an XML document has the potential to be as easy to read as an ID3 v2 tag. What XML would offer is the possibility to use a full parser with DOM in tag editing applications. With a formal schema, there would be no need for a 'reference implementation'. If your document validates against the public schema for that version, it is valid. If it doesn't, it is not. Paul --------------------------------------------------------------------- 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 --------------------------------- Yahoo! Photos ? NEW, now offering a quality print service from just 8p a photo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at audiott.com Mon Feb 6 04:18:07 2006 From: id3v2 at audiott.com (Michal Vician) Date: Mon, 6 Feb 2006 13:18:07 +0100 (CET) Subject: [ID3 Dev] WinAPM and ID3 tags? Message-ID: <15269.195.91.64.52.1139228287.squirrel@195.91.64.52> Last time I was wondering what encoding do WinAMP use to write ID3v1. I founded out that it depends on machine, because Winamp uses default system encoding. However, I was wondering that it also writes ID3v2 in exactly the same way! The "encoding" byte of frame indicates that frame text should be encoded in ISO-8859-1 (%0), but WinAMP encoded and wrote it in my system's default encoding, which seems to be something like "Windows 1251". Is it possible or do I have hallucination? --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From py.thoulon at gmail.com Tue Feb 21 13:56:09 2006 From: py.thoulon at gmail.com (Pyt) Date: Tue, 21 Feb 2006 22:56:09 +0100 Subject: [ID3 Dev] ID3 tag editor for PC In-Reply-To: References: Message-ID: I use and am happy with ID3-TagIt (free): http://www.id3-tagit.de Pyt. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmanson at gracenote.com Mon Feb 27 15:15:52 2006 From: rmanson at gracenote.com (Robert Manson) Date: Mon, 27 Feb 2006 15:15:52 -0800 Subject: [ID3 Dev] ID3v2.5 Message-ID: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> 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. _____ From: Ion Todirel [mailto:iontodirel at yahoo.co.uk] Sent: Monday, February 27, 2006 6:58 AM To: id3v2 at id3.org Subject: [ID3 Dev] ID3v2.5 D:\Music\Albums\Electronica\Goa Trance\The History Of Goa Trance\09. The Muses Rapt - Spiritual Healing.mp3 : ------------------------------------------------------------------------ ----------------------- content metadata ------------------------------------------------------------------------ ----------------------- audio content ------------------------------------------------------------------------ ----------------------- content metadata: ------------------------------------------------------------------------ ----------------------- ID3v2.5 Identifier | Full Metadata Size | Text Frames Encoding -> --------------------------- ------------------------------- ----------------------------- Changes (from ID3v2.4): - no extended header - no padding - no footer - encoding is apply to all metadata (all frames) - all metadata are syncronized or codified in such format that this will not alter mp3 frames, including ID3v2.5 Metadata Identifier - there is only text and objects (binary) frames, put in it what you wont and name it how you wont. For text frames will be apply metadata encoding, for binary not. - structure version (tag version), will be in ID3v2.5 Identifier. - encoding is applying only on frames, text frames! - no tag restrictions - no syncsafe integers, no! - ------------------------------------------------------------------------ ------------------- -> Frames ... ------------------------------------------------------------------------ ----------------------- ID3v2.5 Frame: Full Frame Size Frame Name (at end is a null terminated char, so frame name is not fixed) IsBinary Content Thats all, from my perspective. Simplicity is a good thing, is you think that thi is a good idea or not please comment. Anyway i thinking about sizes... and native frames. _____ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre . -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at audiott.com Fri Feb 10 06:09:51 2006 From: id3v2 at audiott.com (Michal Vician) Date: Fri, 10 Feb 2006 15:09:51 +0100 (CET) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <200602092238.34817.wheeler@kde.org> References: <43EB8958.4090504@sympatico.ca> <200602092005.49739.wheeler@kde.org> <52134.195.91.64.54.1139519786.squirrel@195.91.64.54> <200602092238.34817.wheeler@kde.org> Message-ID: <55709.195.91.64.54.1139580591.squirrel@195.91.64.54> > ...In this case specifically, I can certainly imagine an ID3 spec > that would be possible to implement completely, with less code, > without reducing the functionality provided. As far as I'm concerned I don't have any problems with code lenght. But if have you any concrete ideas (I mean something like a sketch of new ID3 version), just post them. Maybe we can move ID3 spec forward. Best regards Miso > On Thursday 09 February 2006 22:16, Michal Vician wrote: >> Can't see the merit of deprecating frames. ID3v2 is proposed so frames >> you >> would like to deprecate doesn't limit/restrict you in any way. There is >> no >> need to deprecate them. So why do they annoy you? > > Three notes: > > - I'm mostly just babbling about what I would like to see for an ID3v2.5 > or > ID3v3, so take this as such. I don't actually expect either of those > versions happen since it's been about 5 years since the last ID3 revision. > I > certainly don't expect a 2.4.1 or something to deprecate frames. > > - For the moment I do just ignore them in my implementation. They're > parsed > as an "unknown frame". > > - It's really about complexity and cleanliness. ID3v2 is too complex for > what it achieves (saying this as a person who has implemented several tag > formats). In theory, an ID3 spec could do basically everything that ID3v2 > does now and be much easier to implement completely. > > Basically a spec is only as good as its implementations. If portions of a > spec are wholesale ignored across many implementations, then it's probably > fair to say that the spec is too complicated. In this case specifically, > I > can certainly imagine an ID3 spec that would be possible to implement > completely, with less code, without reducing the functionality provided. > Adding more frames would just, in my opinion, increase the amount of ID3v2 > that would be ignored by implementors. > > Cheers, > > -Scott -- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Tue Feb 7 09:20:28 2006 From: id3v2 at northpb.com (Dan O'Neill) Date: Tue, 07 Feb 2006 09:20:28 -0800 Subject: [ID3 Dev] archives? In-Reply-To: <200602071702.50105.wheeler@kde.org> References: <200602071041.44778.wheeler@kde.org> <43E8A1A5.6050202@northpb.com> <200602071702.50105.wheeler@kde.org> Message-ID: <43E8D6DC.1090404@northpb.com> Scott Wheeler wrote: > On Tuesday 07 February 2006 14:33, Dan O'Neill wrote: > I don't really care if it's mentioned on the page or not, but potentially also > of interest is TagLib (http://developer.kde.org/~wheeler/taglib.html) as it's > used by a couple dozen applications, has several language bindings and a > significant portion of 2.4 implemented (there are several frame types that > aren't parsed by it, mostly because they're rare and in my opinion largely > uninteresting). Hey, looks great. It's now at the top of the C/C++ list of Tag libraries due to it's more recent development status over ID3lib. Thanks for the info on the Apple tag issues - I really need to get my bad tag page up. Hey - I know someone from Apple is on this list. Can you help get iTune's tags fixed? Dan --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Fri Feb 10 14:32:23 2006 From: id3v2 at northpb.com (Dan O'Neill) Date: Fri, 10 Feb 2006 14:32:23 -0800 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <20060210214231.2567.qmail@web86909.mail.ukl.yahoo.com> References: <20060210214231.2567.qmail@web86909.mail.ukl.yahoo.com> Message-ID: <43ED1477.40902@northpb.com> Ion Todirel wrote: > If a new good standard will arive, belive me if it will be good enought > it will be accepted by world. Maybe not using xml, but binnary > representation and frames aproach need to be changed with something else. > > For that guys that work on designing ID3, think again when releasing a > new standard. Just to clarify, the members of this list *are* the people working on ID3 tag standards. I'm really just a facilitator. Chris Newell, a member of this list, is the person who thought it would be a good idea to add Chapter and Table of Content frames. He wrote the drafts, passed them around for comment and I drew the frame pictures and posted things for review and comment. Within a few months we had something that most people agreed upon. If one of us were to put forth an XML based tag draft, I'm sure that it would move forward. As for convincing hardware mfg's, users with 8 yrs of tagged content, etc... to switch, well, that's why we have people on this list from Apple, Yahoo and other consumer facing companies. Anyone want to start a draft set of requirements for XML tags? - Backwards compatibility w/existing tags - Adoptable - Must have a reference implementation for writing and reading - ? Dan --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dmillner at bellsouth.net Sat Feb 4 10:03:28 2006 From: dmillner at bellsouth.net (Dominick Millner) Date: Sat, 4 Feb 2006 13:03:28 -0500 Subject: [ID3 Dev] GEOB Message-ID: <20060204180309.SOXD2815.ibm62aec.bellsouth.net@millnermobile> I've noticed several commercial portable MP3 players claiming support for id3v2.4.0. With that being said, are these devices capable of reading the data contained in the GEOB frame? What precautions need to be taken during tagging to ensure this data can be accessed? I tagged an MP3 and added a small video clip in the GEOB frame and received the dreaded "uncompressed header" error in Windows Media Player 10. I feel this frame could be the future of tagging, however the abuse of this frame (executing malicious code) could stop it before it even starts. Regards, Dominick -------------- next part -------------- An HTML attachment was scrubbed... URL: From wheeler at kde.org Thu Feb 9 11:05:48 2006 From: wheeler at kde.org (Scott Wheeler) Date: Thu, 9 Feb 2006 20:05:48 +0100 Subject: [ID3 Dev] "Extending" ID3 V2.4 In-Reply-To: <43EB8958.4090504@sympatico.ca> References: <43EB8958.4090504@sympatico.ca> Message-ID: <200602092005.49739.wheeler@kde.org> On Thursday 09 February 2006 19:26, Ryan Germann wrote: > Hi; I'm new to this list... are there standard ways to suggest new ID3 > frames? Is ID3 extendable in some prescribed way? > > I see at: > > http://www.id3.org/develop.html > > The subsection named: > > Additional standards > > So extra frames are being put forward to support Chapters & their > TOCs... but if I have my own ideas, what is the procedure for suggesting > them? I would say for most cases a user defined text frame is sufficient: http://www.id3.org/id3v2.4.0-frames.txt - Section 4.2.6 As an implementer of ID3v2 I would prefer to see more frames deprecated rather than additional added. In my experience the majority of the frames spec is ignored anyway if not by library developers then by application developers. Anyone ever seen an application that handles "Synched tempo codes" frame? How about "Group identification registration"? I'd put most of the defined frames into the unused category. I think most of the usefulness of ID3v2 could be reduced to text identification frames and GEOB ("generic encapsulated object") frames with some agreement on some standardized frames. There's a certain amount of elegance to the Vorbis comments for instance which are simple key-value pairs. TagLib's implementation of Vorbis comments is about 250 lines of code in 2 source files, as compared to the (incomplete) ID3v2 implementation which is about 2500 in 26 files. And really the only thing that I miss in Vorbis is the ability to store binary data (which GEOB, since it includes mime-types would be quite suitable for) and padding. But that's mostly just ranting. I think the simple answer to your question is that either a TXXX or a GEOB frame will probably do that trick. I may be off on the current trends in the ID3v2 world, having been away from the list for a while, but I don't seriously expect significant changes to the standards in the near future. -Scott -- Many people would sooner die than think; in fact, they do so. --Bertrand Russell --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Sat Feb 11 11:46:10 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 11 Feb 2006 14:46:10 -0500 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <43EDB83E.3050207@fastmail.fm> Message-ID: <20060211194608.EEOA14894.gx4.fuse.net@avoca> For what it's worth, here's my two cents... While I think the highly complex, specialized nature of the ID3v2 spec can work against its uniform adoption, I'm not a big fan of a wholesale replacement of the frame collection paradigm with XML. But what about a hybrid? What if the next gen version of ID3 limited itself to a few "base" frame types, one of which was a frame flagged to contain XML? So, to throw out some ideas, these "base" frames might be... TextFrame - what's now the "T" frames i.e. Artist, Title, Album NumberFrame - a strongly typed frame to store numbers i.e. Track Number, Year, Beats Per Minutes, Duration (MS) BinaryFrame - generically store pictures or any BLOB's/GEOB's TextCollectionFrame - a list of text values i.e. Genres DictionaryFrame - a collection of text key/value pairs i.e. Involved People. XMLFrame - basically the same as TextFrame but flagged as storing XML. You'd still have tag ID's to identify what's in each of these frames, but all data would fit into one of the handful of base frames. In designing my ID3 library, I used a set of base classes in an OO hierarchy to minimize the amount of duplicate code I'd have. So, when I'm implementing a new frame, I always begin by thinking "Can I just start off by inheriting one of my existing base Frame classes or do I have to start from scratch?" If the new standard had a small number of these "base" frames -- and relied on the XML frame as a catchall for the more complex metadata -- then implementers could write the base encoding/decoding code for these frames very quickly. It would only be if you needed to access the more complex frames (read "rarely used" frames) that you'd have to parse XML or use a DOM. For example, if this style of ID3 format were in place, the addition of a Chapter frame wouldn't have required the creation of a whole new base frame type. Instead of having to focus on the binary format of this new frame, we would just have had to agree on an XML schema. Sure, anyone implementing this new frame would have had to write new code to handle the specific XML format, but -- here's the important part -- it wouldn't require you to revisit the area of your library where binary parsing is done. "You want to implement a ChapterFrame? Fine, inherit the XMLFrame and parse the (Friend) XMLFrame.XML property." Personally, what my goal for a next generation ID3 standard would be is an elegant combination of support for simple, commonly-used metadata and complex, rarely-used metadata. The basic implementation would be so simple and streamlined that it would promote a uniformity of application. But it would also support complex metadata, if that's what you needed. I think using a small set of "base" frames which included one to support XML could meet this goal. Sure, the current IDv2 can support almost any metadata requirement imaginable, but the learning curve is very steep. In theory this shouldn't matter. In designing a metadata tag format, you shouldn't have to account for bad (but popular) implementations that all but render the standard useless. But in reality, you do have to worry about the learning curve of your format and how it will affect implementation and adoption. Creating something with an "Easy to learn, hard to master" learning curve would go a long way to reducing the number of corrupt implementations. I could go one with my pros (and some of the cons) of this idea, but I've already rambled on too much, so I thought I'd throw this out there for now. Mitchell S. Honnert www.UltraID3Lib.com -----Original Message----- From: Paul Taylor [mailto:paul_t100 at fastmail.fm] Sent: Saturday, February 11, 2006 5:11 AM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 Completely agree XML must be the way to go it would be so much easier to enforcer validation,implement a libray and be able to view directly in a human readable form. MusicBrainz (ww.musicbrainz.org) uses XML RDF to store its track data maybe this could be used as the basis of an XML Format. I know there are a number of formats additional to ID3v2, do any of these already use XML ? Paul Grebenc wrote: > >> Another "problem" with XML is that it is so flexible when it comes to >> the text encoding of the actual document. Having to support so many >> text encodings can be a big problem, especially in the embedded space. > > > The specification could dictate that the tag has to use UTF-8. Or, it > would be just as easy to not dictate that and let anyone use their > preference. As it stands, ID3v2 supports Unicode, but I doubt there > are very many embedded devices that will correctly display anything > outside the standard ASCII character set. There are probably enough > desktop applications that support ID3v2 that won't do the right thing > with Unicode, as it is. > > I don't want to argue this point forever. I just want to express > three opinions: > > 1. Parsing XML without a full-blown parser/DOM support does not have > to be hard. > > 2. A new version should target the embedded devices that will be > designed a few years from now as the minimum embedded platform. > Existing devices aren't going to retroactively support any new > version, regardless of how simple it is, so there's no value in > wondering whether a three year old 32MB keychain player can 'handle it'. > > 3. XML has some disadvantages, but the one enormous advantage it has, > considering that half the traffic on this list is moaning about bad > ID3v2 implementations, is the ability it provides to universally > enforce validation. > > Paul > > --------------------------------------------------------------------- > 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 From tsorensen at gmail.com Fri Feb 17 05:20:43 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Fri, 17 Feb 2006 08:20:43 -0500 Subject: [ID3 Dev] Determining an offset In-Reply-To: <30CE0C8B4E0D0B41928DE8C587C3F3750291E386@csifiapp6105.oa.caiso.com> References: <30CE0C8B4E0D0B41928DE8C587C3F3750291E386@csifiapp6105.oa.caiso.com> Message-ID: <4da424620602170520p55968818j82b323545ea9ff13@mail.gmail.com> Except that, in this case, it can't. You can't use the ID3V1 tag (if there is one) to get the data you want. You have to parse the ID3V2 tag. And as long as you're doing that, I'd use it for all the data -- ID3V1 is pretty limited, with relatively short strings for artist/title/album and limited genre info. On 2/16/06, Morton, Christopher wrote: > Thanks, Scott. I had no idea it was ID3v1. That ends the discussion. > > The code, incidentally, is WinBatch. Don't knock it 'til you try it. I > mean, why struggle with the fine points of astronomical mathematics and > curved space when simple addition and a straight line can quickly solve > a problem? > > > Chris > > -----Original Message----- > From: Scott Wheeler [mailto:wheeler at kde.org] > Sent: Thursday, February 16, 2006 2:03 PM > To: id3v2 at id3.org > Subject: Re: [ID3 Dev] Determining an offset > > On Thursday 16 February 2006 20:13, Morton, Christopher wrote: > > Please consider the following code (the language doesn't matter) for a > > routine that dumps ID3v2 tag data into Excel. As you do, note the > binary > > offset numbers. My question is, what might be the offset number where > > the "album art" flag (1/0) is located? That's a pressing matter for > this > > exercise (and that's what it is)-to determine if a given MP3 has 1) > been > > tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. > > While I must say that I don't really understand the point of the > question, the > code you pasted (is that Basic? Wow, been a while...) is an ID3v1 > implementation, not ID3v2. ID3v1 is trivially easy since all fields are > of > fixed length and at the end of the file. Not surprisingly, there are no > > images in ID3v1 tags. > > -Scott > > -- > Confidence is the feeling you have before you understand the situation. > > --------------------------------------------------------------------- > 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 From rmandarano at danger.com Tue Feb 21 13:22:37 2006 From: rmandarano at danger.com (Ralph Mandarano) Date: Tue, 21 Feb 2006 13:22:37 -0800 Subject: [ID3 Dev] ID3 tag editor for PC Message-ID: Hello all, I've been skulking on this list since October. I'm currently working on a project that is going to read the id3v1 and 2 tags and I'd like to be able to edit both types on my PC. Does anyone have a good recommend for me? When I check out cNet's download offerings I'm overwhelmed by the choices. Any assistance is greatly appreciated. -Ralph -------------- next part -------------- An HTML attachment was scrubbed... URL: From iontodirel at yahoo.co.uk Sat Feb 11 12:05:16 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Sat, 11 Feb 2006 20:05:16 +0000 (GMT) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <200602102356.50000.wheeler@kde.org> Message-ID: <20060211200516.40759.qmail@web86903.mail.ukl.yahoo.com> I don't think that dependency is a problem, why? Because many (very) people are using .NET and J2EE platforms (the most), here you have xml support. Others problems we can solve. Scott Wheeler wrote: On Friday 10 February 2006 23:32, Dan O'Neill wrote: > Anyone want to start a draft set of requirements for XML tags? > - Backwards compatibility w/existing tags > - Adoptable > - Must have a reference implementation for writing and reading > - ? I didn't actually send the responce I typed to the XML tags bit because I didn't take it seriously, but well, since it seems that you're on that track: There are many problems with using XML as a generalized tagging format. The largest three are (I'm not anti-XML; it certainly has many useful applications, but this is in my opinion clearly not one of them.): - This would require implementers to include an XML parsing engine. For all of the complaints here about the complexity of ID3v2, XML is much harder to parse (but of course there are existing parsers, but then you face more external dependencies). - XML is hierarchical rather than linear. All tagging formats that I know of can be parsed linearly treating the tag as a bitstream. Maintaining a DOM tree consumes not-insignificant amounts of memory and processing. While this would just be an annoyance on the desktop, currently my EUR 60 CD player can read ID3v2 and I assure you that it does not have an abundance of RAM. Also the overhead in processing speed becomes significant even on the desktop when you consider working with tens of thousands of files. - XML is larger. This isn't a problem in terms of storage; you can write pretty huge tags before they're significant relative to the audio content -- but again, thinking deeper and of implementations is important. If you're indexing an MP3 collection you're likely trying to minimize disk access. If the average tag size went from 2 kb to 10 kb (I'd assume larger padding with XML tags), disk reads being the major bottleneck in music collection indexing, you're probably effectively making indexing 5x slower (Ok, probably a bit less than that since disk buffers are probably working on pages larger than a kilobyte, but you get the idea.). Cheers, -Scott -- If the answer is "more lawyers" then the question shouldn't have been asked. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------- Yahoo! Photos ? NEW, now offering a quality print service from just 8p a photo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmanson at gracenote.com Thu Feb 16 14:00:51 2006 From: rmanson at gracenote.com (Robert Manson) Date: Thu, 16 Feb 2006 14:00:51 -0800 Subject: [ID3 Dev] Determining an offset Message-ID: <27905705A869164CBE58B96BA8547557269F25@mail.internal.cddb.com> Your code seems to assume that certain frames will be at a certain offset. Frames are not guaranteed to be in any particular so thus this implementation is bogus. I suggest using an existing id3 library to parse the tags, generate your output, and then import it into your spreadsheet. As for the "offset containing the album art YES/NO indicator" this doesn't exist, however checking for the presence or absence of one or more APIC frames would be a good start. Please read the documentation on the id3.org website before posting. Rob -----Original Message----- From: Morton, Christopher [mailto:CMorton at caiso.com] Sent: Thursday, February 16, 2006 1:54 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] Determining an offset Well, yeah, been there. I'm wanting the no-brainer approach; you folks have been down this road before. If the author of the code I submitted (not me) is able to so-easily find the binary offsets of all the other tag data, then why not the frame offset containing the album art YES/NO indicator? Thanks -----Original Message----- From: Brian Mearns [mailto:bmearns at coe.neu.edu] Sent: Thursday, February 16, 2006 1:35 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] Determining an offset I'm sure others can give a better answer, but the ID3Tag is broken into Frames. Each frame has a frame title that identifies what data is stored in the frame and how to parse it. It has some other header information in the frame, and then the frame data. The Album art frame is one such frame, and there is no set location for it. Frames can be in any order. I don't see any other option than to parse the whole tag and just look for the appropriate frame, and identified by the frame title. That's not to say you have to parse every frame, you just need to parse the first however many bytes (8?) to determine it's size and frame title, and then you can skip over the rest of the frame to the next one. You'll probably want to look at the Informal Standard: http://www.id3.org/id3v2.3.0.html, it will tell you how to determine the frame size for each frame, and what the frame title for the album art frame is. Good luck, I hope that answers your question. -Brian Morton, Christopher wrote: > Hello, > > Please consider the following code (the language doesn't matter) for a > routine that dumps ID3v2 tag data into Excel. As you do, note the binary > offset numbers. My question is, what might be the offset number where > the "album art" flag (1/0) is located? That's a pressing matter for this > exercise (and that's what it is)-to determine if a given MP3 has 1) been > tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. > > >>Chris Morton > > > ;;START CODE > ;; BinaryPeekStr extracts a string from a binary buffer (handle, offset, > maxsize) > ;; BinaryPeek returns the 8-bit value of a byte from a binary buffer > > bb = BinaryAlloc(150) > ThisFile = ItemExtract(FileIndex, List, @TAB) > size = FileSize(ThisFile) > BinaryReadEx(bb, 0, ThisFile, size - 128, 128) > id3 = BinaryPeekStr(bb, 0, 3) > If id3 == "TAG" > > song_title = StrTrim(BinaryPeekStr(bb, 3, 30)) > DDEPoke(channel1, "R%row%C2", song_title) > > artist_name = StrTrim(BinaryPeekStr(bb, 33, 30)) > DDEPoke(channel1, "R%row%C3", artist_name) > > album_name = StrTrim(BinaryPeekStr(bb, 63, 30)) > DDEPoke(channel1, "R%row%C4", album_name) > > album_label = "Not Present" > DDEPoke(channel1, "R%row%C5", album_label) > > album_pub_date = StrTrim(BinaryPeekStr(bb, 93, 4)) > DDEPoke(channel1, "R%row%C6", album_pub_date) > > album_type_desc = "Not Present" > DDEPoke(channel1, "R%row%C7", album_type_desc) > > genre = StrTrim(BinaryPeek(bb, 127)) > DDEPoke(channel1, "R%row%C8", genre) > > EndIf > > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Tue Feb 28 07:17:45 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Tue, 28 Feb 2006 10:17:45 -0500 Subject: [ID3 Dev] ID3v2.5 References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> Message-ID: <001201c63c7a$214b7db0$df010105@kendle.com> >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" To: 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 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 From maillist at steelskies.com Tue Feb 28 06:31:25 2006 From: maillist at steelskies.com (Jonathan del Strother) Date: Tue, 28 Feb 2006 14:31:25 +0000 Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <59516.195.91.64.52.1141136694.squirrel@195.91.64.52> References: <59516.195.91.64.52.1141136694.squirrel@195.91.64.52> Message-ID: On 28 Feb 2006, at 14:24, Michal Vician wrote: >> 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***. > > Well, wouldn't it be better to save id3v2 tag to the end to the file > (rigth after the ID3v1)? I'm pretty new to this mailing list (only > half a > year) and I really can't imagine why is ID3v2 tag stored at the very > beginning of file. Can anybody explain, please? I believe this is purely a benefit for streaming mp3s, where you don't necessarily have the end of the file by the time you start playing. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2114 bytes Desc: not available URL: From CMorton at caiso.com Fri Feb 17 07:34:24 2006 From: CMorton at caiso.com (Morton, Christopher) Date: Fri, 17 Feb 2006 07:34:24 -0800 Subject: [ID3 Dev] Determining an offset Message-ID: <30CE0C8B4E0D0B41928DE8C587C3F3750291E396@csifiapp6105.oa.caiso.com> Right, I get it. Thanks, though. I was simply trying to reuse some pre-existing code, but I see I'm going to have to dig deeper and experiment more. > Chris -----Original Message----- From: Tom Sorensen [mailto:tsorensen at gmail.com] Sent: Friday, February 17, 2006 5:21 AM To: id3v2 at id3.org Subject: Re: [ID3 Dev] Determining an offset Except that, in this case, it can't. You can't use the ID3V1 tag (if there is one) to get the data you want. You have to parse the ID3V2 tag. And as long as you're doing that, I'd use it for all the data -- ID3V1 is pretty limited, with relatively short strings for artist/title/album and limited genre info. On 2/16/06, Morton, Christopher wrote: > Thanks, Scott. I had no idea it was ID3v1. That ends the discussion. > > The code, incidentally, is WinBatch. Don't knock it 'til you try it. I > mean, why struggle with the fine points of astronomical mathematics and > curved space when simple addition and a straight line can quickly solve > a problem? > > > Chris > > -----Original Message----- > From: Scott Wheeler [mailto:wheeler at kde.org] > Sent: Thursday, February 16, 2006 2:03 PM > To: id3v2 at id3.org > Subject: Re: [ID3 Dev] Determining an offset > > On Thursday 16 February 2006 20:13, Morton, Christopher wrote: > > Please consider the following code (the language doesn't matter) for a > > routine that dumps ID3v2 tag data into Excel. As you do, note the > binary > > offset numbers. My question is, what might be the offset number where > > the "album art" flag (1/0) is located? That's a pressing matter for > this > > exercise (and that's what it is)-to determine if a given MP3 has 1) > been > > tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. > > While I must say that I don't really understand the point of the > question, the > code you pasted (is that Basic? Wow, been a while...) is an ID3v1 > implementation, not ID3v2. ID3v1 is trivially easy since all fields are > of > fixed length and at the end of the file. Not surprisingly, there are no > > images in ID3v1 tags. > > -Scott > > -- > Confidence is the feeling you have before you understand the situation. > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Wed Feb 22 13:23:01 2006 From: wheeler at kde.org (Scott Wheeler) Date: Wed, 22 Feb 2006 22:23:01 +0100 Subject: [ID3 Dev] "ID3 Offenders" Part 2 In-Reply-To: <001901c63732$c57c7bc0$df010105@kendle.com> References: <001901c63732$c57c7bc0$df010105@kendle.com> Message-ID: <200602222223.02219.wheeler@kde.org> On Tuesday 21 February 2006 23:04, Mitchell S. Honnert wrote: > A few weeks ago now, I solicited this list for 'ID3 Offenders", examples of > applications, libraries, or encoders that somehow didn't comply with the > ID3 standard. I got some great feedback and compiled the entries in a > single list. There was some talk at the time of adding this list to > www.id3.org, but I haven't seen an update. So in the mean time, I posted > the list to my ID3 library's page. For those who weren't on the list at > the time or for people who just want to check out what I have so far, > here's a direct link to the list... > http://home.fuse.net/honnert/hundred/UltraID3Lib/offenders/ According to the bug report below, apparently MusicMatch will create empty tags (i.e. tags without a single frame): http://bugs.kde.org/show_bug.cgi?id=121935 As many severely corrupted tags as I deal with in bug reports I really wish I knew where they were being created a lot of the time. Also just one list etiquette note -- many people use threaded mail readers. If you're starting a new topic please don't hit reply, but instead send a new mail. -Scott -- The world is full of magical things patiently waiting for our wits to grow sharper. --Bertrand Russell --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at audiott.com Mon Feb 27 15:27:40 2006 From: id3v2 at audiott.com (Michal Vician) Date: Tue, 28 Feb 2006 00:27:40 +0100 (CET) Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <20060227145801.45529.qmail@web86902.mail.ukl.yahoo.com> References: <20060226024425.JTCI4651.gx5.fuse.net@avoca> <20060227145801.45529.qmail@web86902.mail.ukl.yahoo.com> Message-ID: <16156.195.91.64.54.1141082860.squirrel@195.91.64.54> Nice attempt :-) Some things sounds really good and I think the new tag version should be done this way - quote: "Simplicity is a good thing...". ------------ My comments: >- no extended header >- no padding >- no footer * agreed >- encoding is apply to all metadata (all frames) * I don't think this is good idea. I think that encoding should be declared for each frame separately. >- all metadata are syncronized or codified in such format that this will > not alter mp3 frames, including ID3v2.5 Metadata Identifier * Agreed. But there sould be preserved the way of synchonizing v2.4. I mean, it should be possible to synchronize each frame and header separately (don't do the same mistake as in v2.3)... >- there is only text and objects (binary) frames, put in it what you wont > and name it how you wont. For text frames will be apply metadata encoding, > for binary not. * OK >- structure version (tag version), will be in ID3v2.5 Identifier * What Identifier? >- encoding is applying only on frames, text frames! >- no tag restrictions >- no syncsafe integers, no! * agreed > ID3v2.5 Frame: > > - Full Frame Size > - Frame Name (at end is a null terminated char, so frame name is not > fixed) > - IsBinary > - Content * amazing :-) > Thats all, from my perspective. Simplicity is a good thing, is you think > that thi is a good idea or not please comment. Anyway i thinking about > sizes... and native frames. Yes. I think that the idea is really good. I hope others think the same. However, there is much to discuss about. I also think that simplicity is the way :-) Best regards Miso > D:\Music\Albums\Electronica\Goa Trance\The History Of Goa Trance\09. The > Muses Rapt - Spiritual Healing.mp3 : > > ----------------------------------------------------------------------------------------------- > content metadata > ----------------------------------------------------------------------------------------------- > audio content > ----------------------------------------------------------------------------------------------- > > content metadata: > > ----------------------------------------------------------------------------------------------- > ID3v2.5 Identifier | Full Metadata Size | Text Frames Encoding > -> > --------------------------- ------------------------------- > ----------------------------- > > Changes (from ID3v2.4): > > - no extended header > - no padding > - no footer > - encoding is apply to all metadata (all frames) > - all metadata are syncronized or codified in such format that this > will not alter > mp3 frames, including ID3v2.5 Metadata Identifier > - there is only text and objects (binary) frames, put in it what you > wont and name it > how you wont. For text frames will be apply metadata encoding, for > binary not. > - structure version (tag version), will be in ID3v2.5 Identifier. > - encoding is applying only on frames, text frames! > - no tag restrictions > - no syncsafe integers, no! > - > > > ------------------------------------------------------------------------------------------- > -> Frames ... > ----------------------------------------------------------------------------------------------- > > ID3v2.5 Frame: > > Full Frame Size > Frame Name (at end is a null terminated char, so frame name is not > fixed) > IsBinary > Content > > > Thats all, from my perspective. Simplicity is a good thing, is you think > that thi is a good idea or not please comment. Anyway i thinking about > sizes... and native frames. > > > --------------------------------- > To help you stay safe and secure online, we've developed the all new > Yahoo! Security Centre. --- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jid3 at blinkenlights.org Fri Feb 10 11:26:49 2006 From: jid3 at blinkenlights.org (Paul Grebenc) Date: Fri, 10 Feb 2006 14:26:49 -0500 (EST) Subject: [ID3 Dev] 'Extending' ID3 V2.4 Message-ID: >the ID3v2.4 spec is 5 1/2 years old and most commercial media players >still don't support it. Any talk of creating a new ID3 standard (even >though it would be nice) is fruitless. I do agree that attempting to popularize v2.4.0 is a fruitless task. Practically the only reason anyone switches to v2.3.0 is to get strings longer than 30 characters. The esoteric frames are virtually unknown to anyone who hasn't implemented a library. However, ID3 is a recognizable brand, so if a new version based on XML were released, it might be seen as worth implementing by some of the major players. No guarantee of that, of course. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From paul_t100 at fastmail.fm Sat Feb 11 02:11:10 2006 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sat, 11 Feb 2006 10:11:10 +0000 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: References: Message-ID: <43EDB83E.3050207@fastmail.fm> Completely agree XML must be the way to go it would be so much easier to enforcer validation,implement a libray and be able to view directly in a human readable form. MusicBrainz (ww.musicbrainz.org) uses XML RDF to store its track data maybe this could be used as the basis of an XML Format. I know there are a number of formats additional to ID3v2, do any of these already use XML ? Paul Grebenc wrote: > >> Another "problem" with XML is that it is so flexible when it comes to >> the text encoding of the actual document. Having to support so many >> text encodings can be a big problem, especially in the embedded space. > > > The specification could dictate that the tag has to use UTF-8. Or, it > would be just as easy to not dictate that and let anyone use their > preference. As it stands, ID3v2 supports Unicode, but I doubt there > are very many embedded devices that will correctly display anything > outside the standard ASCII character set. There are probably enough > desktop applications that support ID3v2 that won't do the right thing > with Unicode, as it is. > > I don't want to argue this point forever. I just want to express > three opinions: > > 1. Parsing XML without a full-blown parser/DOM support does not have > to be hard. > > 2. A new version should target the embedded devices that will be > designed a few years from now as the minimum embedded platform. > Existing devices aren't going to retroactively support any new > version, regardless of how simple it is, so there's no value in > wondering whether a three year old 32MB keychain player can 'handle it'. > > 3. XML has some disadvantages, but the one enormous advantage it has, > considering that half the traffic on this list is moaning about bad > ID3v2 implementations, is the ability it provides to universally > enforce validation. > > Paul > > --------------------------------------------------------------------- > 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 From iontodirel at yahoo.co.uk Mon Feb 27 06:58:01 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Mon, 27 Feb 2006 14:58:01 +0000 (GMT) Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <20060226024425.JTCI4651.gx5.fuse.net@avoca> Message-ID: <20060227145801.45529.qmail@web86902.mail.ukl.yahoo.com> D:\Music\Albums\Electronica\Goa Trance\The History Of Goa Trance\09. The Muses Rapt - Spiritual Healing.mp3 : ----------------------------------------------------------------------------------------------- content metadata ----------------------------------------------------------------------------------------------- audio content ----------------------------------------------------------------------------------------------- content metadata: ----------------------------------------------------------------------------------------------- ID3v2.5 Identifier | Full Metadata Size | Text Frames Encoding -> --------------------------- ------------------------------- ----------------------------- Changes (from ID3v2.4): - no extended header - no padding - no footer - encoding is apply to all metadata (all frames) - all metadata are syncronized or codified in such format that this will not alter mp3 frames, including ID3v2.5 Metadata Identifier - there is only text and objects (binary) frames, put in it what you wont and name it how you wont. For text frames will be apply metadata encoding, for binary not. - structure version (tag version), will be in ID3v2.5 Identifier. - encoding is applying only on frames, text frames! - no tag restrictions - no syncsafe integers, no! - ------------------------------------------------------------------------------------------- -> Frames ... ----------------------------------------------------------------------------------------------- ID3v2.5 Frame: Full Frame Size Frame Name (at end is a null terminated char, so frame name is not fixed) IsBinary Content Thats all, from my perspective. Simplicity is a good thing, is you think that thi is a good idea or not please comment. Anyway i thinking about sizes... and native frames. --------------------------------- To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benski at winamp.com Mon Feb 6 07:43:06 2006 From: benski at winamp.com (Ben Allison) Date: Mon, 6 Feb 2006 10:43:06 -0500 (EST) Subject: [ID3 Dev] WinAPM and ID3 tags? In-Reply-To: <15269.195.91.64.52.1139228287.squirrel@195.91.64.52> References: <15269.195.91.64.52.1139228287.squirrel@195.91.64.52> Message-ID: <2271.68.100.121.19.1139240586.squirrel@mail.winamp.com> Winamp 5.2 (currently in beta) will write its tags in UTF-16. Older versions write, as you said, in the system default encoding. "Encoding type 0" tags are also read as the system default encoding. In the first public beta of Winamp 5.2, it read ASCII tags as ISO-8859-1 only (the correct way!). After an avalanche of complaints , I had to go back to the old, bad, behavior. Such is the reality of software :( -Ben Allison > Last time I was wondering what encoding do WinAMP use to write ID3v1. I > founded out that it depends on machine, because Winamp uses default system > encoding. However, I was wondering that it also writes ID3v2 in exactly > the same way! The "encoding" byte of frame indicates that frame text > should be encoded in ISO-8859-1 (%0), but WinAMP encoded and wrote it in > my system's default encoding, which seems to be something like "Windows > 1251". > Is it possible or do I have hallucination? --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Sat Feb 4 10:39:47 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 4 Feb 2006 13:39:47 -0500 Subject: [ID3 Dev] GEOB In-Reply-To: <20060204180309.SOXD2815.ibm62aec.bellsouth.net@millnermobile> Message-ID: <20060204183944.SHVC4722.gx6.fuse.net@avoca> >I tagged an MP3 and added a small video clip in the GEOB frame and received the dreaded "uncompressed header" error in Windows Media Player 10. What did you use to insert the GEOB frame into the tag? WMP is admittedly very finicky about illformatted frames, but perhaps the root problem is the creation of a non-standard GEOB frame. I tested playing an MP3 which I knew contained an ID3v2.3 GEOB frame and it played fine. >With that being said, are these devices capable of reading the data contained in the GEOB frame? >What precautions need to be taken during tagging to ensure this data can be accessed? You can ensure that the GEOB and other less commonly used frames are in the standard format, but it's really up to the developers of the MP3 player software to decode those frames. (You can lead a horse to water, but you can't make him drink.) You can support ID3, but not fully support every single frame referenced in the standard. HTH Mitchell S. Honnert www.UltraID3Lib.com _____ From: Dominick Millner [mailto:dmillner at bellsouth.net] Sent: Saturday, February 04, 2006 1:03 PM To: id3v2 at id3.org Subject: [ID3 Dev] GEOB I've noticed several commercial portable MP3 players claiming support for id3v2.4.0. With that being said, are these devices capable of reading the data contained in the GEOB frame? What precautions need to be taken during tagging to ensure this data can be accessed? I tagged an MP3 and added a small video clip in the GEOB frame and received the dreaded "uncompressed header" error in Windows Media Player 10. I feel this frame could be the future of tagging, however the abuse of this frame (executing malicious code) could stop it before it even starts. Regards, Dominick -------------- next part -------------- An HTML attachment was scrubbed... URL: From wheeler at kde.org Fri Feb 10 14:56:49 2006 From: wheeler at kde.org (Scott Wheeler) Date: Fri, 10 Feb 2006 23:56:49 +0100 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <43ED1477.40902@northpb.com> References: <20060210214231.2567.qmail@web86909.mail.ukl.yahoo.com> <43ED1477.40902@northpb.com> Message-ID: <200602102356.50000.wheeler@kde.org> On Friday 10 February 2006 23:32, Dan O'Neill wrote: > Anyone want to start a draft set of requirements for XML tags? > ? - Backwards compatibility w/existing tags > ? - Adoptable > ? - Must have a reference implementation for writing and reading > ? - ? I didn't actually send the responce I typed to the XML tags bit because I didn't take it seriously, but well, since it seems that you're on that track: There are many problems with using XML as a generalized tagging format. The largest three are (I'm not anti-XML; it certainly has many useful applications, but this is in my opinion clearly not one of them.): - This would require implementers to include an XML parsing engine. For all of the complaints here about the complexity of ID3v2, XML is much harder to parse (but of course there are existing parsers, but then you face more external dependencies). - XML is hierarchical rather than linear. All tagging formats that I know of can be parsed linearly treating the tag as a bitstream. Maintaining a DOM tree consumes not-insignificant amounts of memory and processing. While this would just be an annoyance on the desktop, currently my EUR 60 CD player can read ID3v2 and I assure you that it does not have an abundance of RAM. Also the overhead in processing speed becomes significant even on the desktop when you consider working with tens of thousands of files. - XML is larger. This isn't a problem in terms of storage; you can write pretty huge tags before they're significant relative to the audio content -- but again, thinking deeper and of implementations is important. If you're indexing an MP3 collection you're likely trying to minimize disk access. If the average tag size went from 2 kb to 10 kb (I'd assume larger padding with XML tags), disk reads being the major bottleneck in music collection indexing, you're probably effectively making indexing 5x slower (Ok, probably a bit less than that since disk buffers are probably working on pages larger than a kilobyte, but you get the idea.). Cheers, -Scott -- If the answer is "more lawyers" then the question shouldn't have been asked. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From wheeler at kde.org Tue Feb 7 01:41:44 2006 From: wheeler at kde.org (Scott Wheeler) Date: Tue, 7 Feb 2006 10:41:44 +0100 Subject: [ID3 Dev] archives? Message-ID: <200602071041.44778.wheeler@kde.org> I just noticed that the list is apparently alive again; it died a few years back and apparently when brought back didn't keep the subscribers list. Does anyone know if there's a set of archives available? I'd just like to see if there's anything terribly important that's crossed over the list of late. Cheers, -Scott --------------------------------------------------------------------- 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 Feb 28 07:40:48 2006 From: benski at winamp.com (Ben Allison) Date: Tue, 28 Feb 2006 10:40:48 -0500 (EST) Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> Message-ID: <3323.68.100.121.19.1141141248.squirrel@mail.winamp.com> I've already voiced by support for this, but I'll do it again :) Can we add a proper frame for "Album Artist" at the same time? I don't think TPE2 is the appropriate place for this information, especially for certain genres like jazz, show tunes, and opera where TPE2 has a need to be used as it is designed. > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From andrew.kernahan at btinternet.com Fri Feb 10 11:12:34 2006 From: andrew.kernahan at btinternet.com (Andy Kernahan) Date: Fri, 10 Feb 2006 19:12:34 -0000 Subject: [ID3 Dev] 'Extending' ID3 V2.4 References: <43EB8958.4090504@sympatico.ca> <200602092005.49739.wheeler@kde.org> <52134.195.91.64.54.1139519786.squirrel@195.91.64.54> <200602092238.34817.wheeler@kde.org> <55709.195.91.64.54.1139580591.squirrel@195.91.64.54> Message-ID: <000601c62e75$f2e0ade0$0500000a@MARVIN> Guys, the ID3v2.4 spec is 5 1/2 years old and most commercial media players still don't support it. Any talk of creating a new ID3 standard (even though it would be nice) is fruitless. Sorry to be so pessimistic. Andy. ----- Original Message ----- From: "Michal Vician" To: Sent: Friday, February 10, 2006 2:09 PM Subject: [Norton AntiSpam] Re: [ID3 Dev] 'Extending' ID3 V2.4 >> ...In this case specifically, I can certainly imagine an ID3 spec >> that would be possible to implement completely, with less code, >> without reducing the functionality provided. > > As far as I'm concerned I don't have any problems with code lenght. > But if have you any concrete ideas (I mean something like a sketch of new > ID3 version), just post them. Maybe we can move ID3 spec forward. > > Best regards > Miso > >> On Thursday 09 February 2006 22:16, Michal Vician wrote: >>> Can't see the merit of deprecating frames. ID3v2 is proposed so frames >>> you >>> would like to deprecate doesn't limit/restrict you in any way. There is >>> no >>> need to deprecate them. So why do they annoy you? >> >> Three notes: >> >> - I'm mostly just babbling about what I would like to see for an ID3v2.5 >> or >> ID3v3, so take this as such. I don't actually expect either of those >> versions happen since it's been about 5 years since the last ID3 >> revision. >> I >> certainly don't expect a 2.4.1 or something to deprecate frames. >> >> - For the moment I do just ignore them in my implementation. They're >> parsed >> as an "unknown frame". >> >> - It's really about complexity and cleanliness. ID3v2 is too complex >> for >> what it achieves (saying this as a person who has implemented several tag >> formats). In theory, an ID3 spec could do basically everything that >> ID3v2 >> does now and be much easier to implement completely. >> >> Basically a spec is only as good as its implementations. If portions of >> a >> spec are wholesale ignored across many implementations, then it's >> probably >> fair to say that the spec is too complicated. In this case specifically, >> I >> can certainly imagine an ID3 spec that would be possible to implement >> completely, with less code, without reducing the functionality provided. >> Adding more frames would just, in my opinion, increase the amount of >> ID3v2 >> that would be ignored by implementors. >> >> Cheers, >> >> -Scott > > > -- > Michal Vician > id3v2 at audiott.com > http://www.audiott.com/ > > > --------------------------------------------------------------------- > 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 From benski at winamp.com Tue Feb 28 07:33:12 2006 From: benski at winamp.com (Ben Allison) Date: Tue, 28 Feb 2006 10:33:12 -0500 (EST) Subject: [ID3 Dev] ID3v2.5 In-Reply-To: <001201c63c7a$214b7db0$df010105@kendle.com> References: <27905705A869164CBE58B96BA8547557036592AA@mail.internal.cddb.com> <27267.195.91.64.54.1141083107.squirrel@195.91.64.54> <4da424620602280559l4ff9ad3cqdff152333d38628a@mail.gmail.com> <001201c63c7a$214b7db0$df010105@kendle.com> Message-ID: <3254.68.100.121.19.1141140792.squirrel@mail.winamp.com> It's a shame that HFS+ resource forks, and NTFS alternate streams can't be kept with the file when it leaves the filesystem. These sorts of solutions are the most ideal for metadata. > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Sat Feb 11 13:56:42 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 11 Feb 2006 16:56:42 -0500 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <200602112202.10485.wheeler@kde.org> Message-ID: <20060211215640.ZWHM4722.gx6.fuse.net@avoca> >This is largely sane, though I think you could generalize things >a little more. Largely sane? That's the nicest thing anyone's said to me all week. ;-) Sure, I could see there being quite a bit of discussion around what base frames would be needed. The goal would be to find the sweet spot between not having so many that it overly complicates the base frame code and having enough to handle the majority of commonly-used frames. Maybe an application of the 80/20 rule where the base frames handled 80% of the overall frames? >> NumberFrame - a strongly typed frame to store numbers i.e. Track Number, >> Year, Beats Per Minutes, Duration (MS) >This one's arguable. It's not particularly difficult to convert >between text and integers as in the current text frames. It's not a matter of the trouble to do the conversion as much as a matter of the *validation* during the conversion process. For example, if we store the Year in a NumberFrame which stores its value in a fixed number of bytes, then I wouldn't have to check to see if the value was a valid number when decoding the frame. The value would, by definition of it being in a NumberFrame, be numeric. In practical terms, this would mean I wouldn't have to check for cases where people have set the Year value to "Year" or other nonsensical text values. One could argue that some of the "numeric text" fields could legitimately have non-numeric values -- anyone else seen values like "19XX"? -- but I would argue that values like Track Number, Track Count, Year, Beats Per Minutes and Duration (MS) should be restricted to numeric values only. >> TextCollectionFrame - a list of text values i.e. Genres >> >> DictionaryFrame - a collection of text key/value pairs i.e. Involved >> People. >I don't see the major difference between these two, I was thinking along the lines that the TextCollectionFrame would store a unique collection of text values, where the DictionaryFrame would store a collection of key/value pairs. So, a TextCollectionFrame could store multiple Genre values ("Rock", "Instrumental") and the DictionaryFrame could store Involved People List values (Involvement Type, Involved Person). >and of course the current text frames are capable of doing lists as well. Ah, the current text frames are *capable* of storing a list of text values, but there are competing implementations. Genre is the example that comes to mind. The ID3v2.3 standard indicates that you can have multiple genres in a single frame, but it references delimiting the values with parentheses. But there are implementations out there (ID3-TagIT) that ignore the standard and use a null-char-delimited list for multiple Genres. So, where I'm going with this is that having a base frame dedicated to a unique list of values would unify the implementation of the Genre frame and any other frames that could be implemented using a unique collection of text values. >A GEOB currently isn't limited to binary data -- it's just something with a >mime-type. I don't see a reason not to have text/xml as one of those. Fair enough. I can see that. One thing on the side of having a specialized picture frame, however, is that it is one of the most commonly used frames, so there might be some benefit to having some picture-specific properties. >In terms of getting things implemented, the closer things are to a subset >of the current spec in my opinion the better since that would mean that >getting momentum behind a new spec would be much easier. Agreed. Again, I think we're still in the "it's academic" stage here, but it's interesting to at least toss around the idea of what it would take to make a new standard viable. Mitchell S. Honnert www.UltraID3Lib.com -----Original Message----- From: Scott Wheeler [mailto:wheeler at kde.org] Sent: Saturday, February 11, 2006 4:02 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] 'Extending' ID3 V2.4 On Saturday 11 February 2006 20:46, Mitchell S. Honnert wrote: This is largely sane, though I think you could generalize things a little more. > So, to throw out some ideas, these "base" frames might be... > > TextFrame - what's now the "T" frames i.e. Artist, Title, Album Sure. > NumberFrame - a strongly typed frame to store numbers i.e. Track Number, > Year, Beats Per Minutes, Duration (MS) This one's arguable. It's not particularly difficult to convert between text and integers as in the current text frames. > BinaryFrame - generically store pictures or any BLOB's/GEOB's See the note in XML below. > TextCollectionFrame - a list of text values i.e. Genres > > DictionaryFrame - a collection of text key/value pairs i.e. Involved > People. I don't see the major difference between these two, and of course the current text frames are capable of doing lists as well. > XMLFrame - basically the same as TextFrame but flagged as storing XML. A GEOB currently isn't limited to binary data -- it's just something with a mime-type. I don't see a reason not to have text/xml as one of those. In terms of getting things implemented, the closer things are to a subset of the current spec in my opinion the better since that would mean that getting momentum behind a new spec would be much easier. -Scott -- There are 10 types of people in the world: Those who understand binary, and those who don't. --------------------------------------------------------------------- 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 From bmearns at coe.neu.edu Thu Feb 16 13:35:20 2006 From: bmearns at coe.neu.edu (Brian Mearns) Date: Thu, 16 Feb 2006 16:35:20 -0500 Subject: [ID3 Dev] Determining an offset In-Reply-To: <30CE0C8B4E0D0B41928DE8C587C3F375022EA2F7@csifiapp6105.oa.caiso.com> References: <30CE0C8B4E0D0B41928DE8C587C3F375022EA2F7@csifiapp6105.oa.caiso.com> Message-ID: <43F4F018.9050806@coe.neu.edu> I'm sure others can give a better answer, but the ID3Tag is broken into Frames. Each frame has a frame title that identifies what data is stored in the frame and how to parse it. It has some other header information in the frame, and then the frame data. The Album art frame is one such frame, and there is no set location for it. Frames can be in any order. I don't see any other option than to parse the whole tag and just look for the appropriate frame, and identified by the frame title. That's not to say you have to parse every frame, you just need to parse the first however many bytes (8?) to determine it's size and frame title, and then you can skip over the rest of the frame to the next one. You'll probably want to look at the Informal Standard: http://www.id3.org/id3v2.3.0.html, it will tell you how to determine the frame size for each frame, and what the frame title for the album art frame is. Good luck, I hope that answers your question. -Brian Morton, Christopher wrote: > Hello, > > Please consider the following code (the language doesn't matter) for a > routine that dumps ID3v2 tag data into Excel. As you do, note the binary > offset numbers. My question is, what might be the offset number where > the "album art" flag (1/0) is located? That's a pressing matter for this > exercise (and that's what it is)-to determine if a given MP3 has 1) been > tagged and 2) if the metadata includes (YES/NO) the album JPG. Thanks. > > >>Chris Morton > > > ;;START CODE > ;; BinaryPeekStr extracts a string from a binary buffer (handle, offset, > maxsize) > ;; BinaryPeek returns the 8-bit value of a byte from a binary buffer > > bb = BinaryAlloc(150) > ThisFile = ItemExtract(FileIndex, List, @TAB) > size = FileSize(ThisFile) > BinaryReadEx(bb, 0, ThisFile, size - 128, 128) > id3 = BinaryPeekStr(bb, 0, 3) > If id3 == "TAG" > > song_title = StrTrim(BinaryPeekStr(bb, 3, 30)) > DDEPoke(channel1, "R%row%C2", song_title) > > artist_name = StrTrim(BinaryPeekStr(bb, 33, 30)) > DDEPoke(channel1, "R%row%C3", artist_name) > > album_name = StrTrim(BinaryPeekStr(bb, 63, 30)) > DDEPoke(channel1, "R%row%C4", album_name) > > album_label = "Not Present" > DDEPoke(channel1, "R%row%C5", album_label) > > album_pub_date = StrTrim(BinaryPeekStr(bb, 93, 4)) > DDEPoke(channel1, "R%row%C6", album_pub_date) > > album_type_desc = "Not Present" > DDEPoke(channel1, "R%row%C7", album_type_desc) > > genre = StrTrim(BinaryPeek(bb, 127)) > DDEPoke(channel1, "R%row%C8", genre) > > EndIf > > > --------------------------------------------------------------------- > 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 From fiji at ayup.limey.net Fri Feb 10 16:20:49 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 10 Feb 2006 19:20:49 -0500 Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: <27905705A869164CBE58B96BA8547557269F1F@mail.internal.cddb.com> References: <27905705A869164CBE58B96BA8547557269F1F@mail.internal.cddb.com> Message-ID: <20060211002049.GA24196@ayup.limey.net> On Fri, Feb 10, 2006 at 03:58:27PM -0800, Robert Manson wrote: > Another "problem" with XML is that it is so flexible when it comes to > the text encoding of the actual document. Having to support so many > text encodings can be a big problem, especially in the embedded space. Supporting full XML parsing unless the DTD were very strict (possibly with strict ordering of frames, and also possibly including offsets in the format) might be prohibitive in some of the players. As a note... I would guess the vast majority of mp3 players can read/write 2.4 (because Apple does and that dominates the market). Hoewver, Apple's implementation is bust for frames larger than 128 bytes. Sigh. And they also use some proprietary frames. Sigh. And they are not flagged as such. Sigh. > Some things I would like to see in a new ID3 version: > > 1. Tags at the end of the file, perhaps directly above an IDv1 tag 2.4 can do that. > 2. No binary data, thus avoiding the need for an unsyncronization > scheme > 3. One UTF* text encoding format, perhaps one that does not require > unsyncronization, UTF-7? UGH! UTF-7 is pretty wretched to work with. > 4. Simple key-value pairing whereby ID3 recognizes a set of standard > keys but allows room for custom keys (ie TXXX). -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From kipp at gremillion.org Tue Feb 21 13:31:29 2006 From: kipp at gremillion.org (Kipp Gremillion) Date: Tue, 21 Feb 2006 15:31:29 -0600 Subject: [ID3 Dev] ID3 tag editor for PC In-Reply-To: Message-ID: <000601c6372e$2e222210$6400a8c0@thedjbooth> A recommendation for an editor already created? If so for simple data I like Winamp as already mentioned here. For extended data I love Tag&Rename. _____ From: Ralph Mandarano [mailto:rmandarano at danger.com] Sent: Tuesday, February 21, 2006 3:23 PM To: id3v2 at id3.org Subject: [ID3 Dev] ID3 tag editor for PC Hello all, I've been skulking on this list since October. I'm currently working on a project that is going to read the id3v1 and 2 tags and I'd like to be able to edit both types on my PC. Does anyone have a good recommend for me? When I check out cNet's download offerings I'm overwhelmed by the choices. Any assistance is greatly appreciated. -Ralph -------------- next part -------------- An HTML attachment was scrubbed... URL: From iontodirel at yahoo.co.uk Fri Feb 10 13:42:31 2006 From: iontodirel at yahoo.co.uk (Ion Todirel) Date: Fri, 10 Feb 2006 21:42:31 +0000 (GMT) Subject: [ID3 Dev] 'Extending' ID3 V2.4 In-Reply-To: Message-ID: <20060210214231.2567.qmail@web86909.mail.ukl.yahoo.com> If a new good standard will arive, belive me if it will be good enought it will be accepted by world. Maybe not using xml, but binnary representation and frames aproach need to be changed with something else. For that guys that work on designing ID3, think again when releasing a new standard. Paul Grebenc wrote: >why use a binary representation of data containing in files why just >not use xml? and why storing this data inside the files and not >providing a unified database for fast access and that will store all >needed information? I'd also like to see XML used for a new version. There is the argument that the tag can contain binary data, but it can be base64 encoded. The increase in size is not that dramatic, and in practice, you've got to expect an increase in file size in any case, if you plan to attach a 2MB image to a 3MB MP3 file. In practice, I don't think this would be a problem. As for embedded devices, the world is advancing, and it will soon be (if it isn't already in cases) easier to deal with XML and unencoding base64'ed images, than it is to write code specific to a proprietary binary format. (And v2.3.0 already exists, just as v1.1 does, for legacy devices.) I fully agree that there are too many tag types in v2. Too many of them are too esoteric, and/or badly designed (RVAD: Why is the number of bytes per adjustment variable, when 2^16 levels of adjustment are far, far more than enough. And this in a tag you'll probably never see in the wild.). Using XML would also allow for such niceties as the provision of standard schemas and transformations, for validating tags and upgrading to newer versions. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------- Yahoo! Cars NEW - sell your car and browse thousands of new and used cars online search now --------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: