From fiji at ayup.limey.net Tue Dec 5 17:00:24 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Tue, 5 Dec 2006 20:00:24 -0500 Subject: [ID3 Dev] frames with 'Data length indicator' flag In-Reply-To: <457609BD.5090706@orionet.ru> References: <457609BD.5090706@orionet.ru> Message-ID: <20061206010024.GA27140@ayup.limey.net> On Wed, Dec 06, 2006 at 03:07:25AM +0300, Alexey Illarionov wrote: > Hi, > > Is the following frame correct in ID2v2.4? > > TPE1 size flags data length S > 0000000a 54 50 45 31 00 00 00 11 00 01 00 00 00 0d 03 53 > tratovarius > 0000001a 74 72 61 74 6f 76 61 72 69 75 73 It looks correct to me. The data length is the "length of the data if all flags were zeroed" so, size - 4 (the 4 bytes of the data length) which equals the 0x0d (13 decimal) bytes of the string. And size looks correct. There are 0x11 (17 decimal) bytes following the flags. > > It have 'Data length indicator' in frame format flags set. This frame > was written by libid3tag. I have tested some programs with tags with > such frames (winamp, windows media player, amarok, foobar, last > tag&rename..) and i was found only two programs that read such frames > correctly. They are foobar and amarok. I am not surprised... I haven't found much that fully implements the spec. Sadly. > When i rewrite this tag in amarok, it is cut off data length with data > length indicator. After that this frame has been read correctly with > most of the listed programs, even by winamp. Amarok uses taglib to read/write the tags, and that appears to be liberal in what it accepts and then write tags that are generally valid. > I'm not shure about values of the 'frame size' (0x11) and 'data > length' (0x0d). Is they correct? They appear to be. But if you can control whether or not the data length is written, I would try to disable it. -ben --------------------------------------------------------------------- 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 Dec 4 11:05:05 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Mon, 4 Dec 2006 14:05:05 -0500 Subject: [ID3 Dev] Invalid COMM Frame ? In-Reply-To: <4574707F.4080807@fastmail.fm> References: <4574707F.4080807@fastmail.fm> Message-ID: <4da424620612041105i77b389c2j7e13f692c9ea2708@mail.gmail.com> Be liberal in what you accept and conservative in what you write. IOW -- yes, accept it, but fix the thing when/if you write it back out. On 12/4/06, Paul Taylor wrote: > I came across a ID2v2.3 tag with a COMM frame within it, encoded to > UTF-16, but the the short content description field only has a single > null terminator when it should have two (because it is UTF-16). Would > people expect a tagger to accept this frame or ignore it. > > 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 paul_t100 at fastmail.fm Mon Dec 4 11:01:19 2006 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Mon, 04 Dec 2006 19:01:19 +0000 Subject: [ID3 Dev] Invalid COMM Frame ? Message-ID: <4574707F.4080807@fastmail.fm> I came across a ID2v2.3 tag with a COMM frame within it, encoded to UTF-16, but the the short content description field only has a single null terminator when it should have two (because it is UTF-16). Would people expect a tagger to accept this frame or ignore it. Paul --------------------------------------------------------------------- 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 Sun Dec 31 18:30:58 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Sun, 31 Dec 2006 21:30:58 -0500 Subject: [ID3 Dev] $xx (xx ...) In-Reply-To: <688801c72d3e$03bf00e0$6501a8c0@xp1800desk> References: <20061231231825.JJFX6736.gx5.fuse.net@avoca> <20070101003105.GA21841@ayup.limey.net> <688801c72d3e$03bf00e0$6501a8c0@xp1800desk> Message-ID: <20070101023058.GA24706@ayup.limey.net> On Sun, Dec 31, 2006 at 07:44:31PM -0500, Jim wrote: > So there could be multiple events included and simply including everything > in the list (or the rest of the frame) would not work. Ooops. No, you are absolutely correct. The number of records is determined by reading the rest of the frame, but the record size is indicated by the format field. Mea culpa. That'll teach me to reply after doping up on Nyquil. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From littlesavage at orionet.ru Tue Dec 5 16:07:25 2006 From: littlesavage at orionet.ru (Alexey Illarionov) Date: Wed, 06 Dec 2006 03:07:25 +0300 Subject: [ID3 Dev] frames with 'Data length indicator' flag Message-ID: <457609BD.5090706@orionet.ru> Hi, Is the following frame correct in ID2v2.4? TPE1 size flags data length S 0000000a 54 50 45 31 00 00 00 11 00 01 00 00 00 0d 03 53 tratovarius 0000001a 74 72 61 74 6f 76 61 72 69 75 73 It have 'Data length indicator' in frame format flags set. This frame was written by libid3tag. I have tested some programs with tags with such frames (winamp, windows media player, amarok, foobar, last tag&rename..) and i was found only two programs that read such frames correctly. They are foobar and amarok. When i rewrite this tag in amarok, it is cut off data length with data length indicator. After that this frame has been read correctly with most of the listed programs, even by winamp. I'm not shure about values of the 'frame size' (0x11) and 'data length' (0x0d). Is they correct? --------------------------------------------------------------------- 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 Sun Dec 31 16:31:05 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Sun, 31 Dec 2006 19:31:05 -0500 Subject: [ID3 Dev] $xx (xx ...) In-Reply-To: <20061231231825.JJFX6736.gx5.fuse.net@avoca> References: <20061231231825.JJFX6736.gx5.fuse.net@avoca> Message-ID: <20070101003105.GA21841@ayup.limey.net> On Sun, Dec 31, 2006 at 06:18:20PM -0500, Mitchell S. Honnert wrote: > OK. I give up. It's probably that I'm just not seeing it, but I can't find > any definition of this format. > > $xx (xx ...) It means one or more bytes. ... > I'm going to feel pretty silly if I've just overlooked this, but I honestly > can't find it. So, wow are you supposed to know how many bytes are > represented by the "(xx ...)"? It means as many bytes are left in the frame (based on the frame size). All of those notations appear on fields at the end of the frames. However, I don't believe it is explicitly stated anywhere. And it would be good to call it out. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Sun Dec 17 16:33:56 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Sun, 17 Dec 2006 19:33:56 -0500 Subject: [ID3 Dev] Announcing an ID3v2 wiki... In-Reply-To: <4585B7AB.8030104@northpb.com> References: <20061114202159.GA31545@ayup.limey.net> <20061115193745.GA15034@ayup.limey.net> <20061215053711.GA18084@ayup.limey.net> <4585B7AB.8030104@northpb.com> Message-ID: <20061218003356.GA21478@ayup.limey.net> On Sun, Dec 17, 2006 at 01:33:31PM -0800, Dan O'Neill wrote: > Hi Ben - I guess we think alike. I was going to announce this and seek > a few testers, but might as well put our efforts together. Argh. I wish you had said something when I announced my intent to create this a while ago. Anyway, it is better to pool resources so I gladly defer to your wiki. > If anyone on this list wants to be an Editor, just create an account on > this page http://id3.org/id3/UserPreferences and email me your WikiName > and I'll put you in the EditorsGroup. I created BenBennett. Is it possible that we can make the world able to edit? The studies of Wikipedia seem to indicate that first-time people generate the backbone of wikipedia by writing long articles on topics they know. Whereas the hard-core wikipedia people polish and edit the articles. > Ben, sorry that we both were doing things. I hope we can work together. Certainly. I will move over my notes on custom tags. The rest of the content was just marking up the specs into an annotatable form. And adding links, and cross-references. Unfortunately the moinmoin markup appears to be a bit different from the wikimedia one. > The wiki at id3.org will become the default for id3.org once people > have tested it a bit. Sounds good. Although I think the published specs need to be frozen somehow. It would be nice to have an annotated version as long as it is noted as not being authoritative. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jmartin92 at comcast.net Sun Dec 31 16:44:31 2006 From: jmartin92 at comcast.net (Jim) Date: Sun, 31 Dec 2006 19:44:31 -0500 Subject: [ID3 Dev] $xx (xx ...) References: <20061231231825.JJFX6736.gx5.fuse.net@avoca> <20070101003105.GA21841@ayup.limey.net> Message-ID: <688801c72d3e$03bf00e0$6501a8c0@xp1800desk> > It means as many bytes are left in the frame (based on the frame > size). All of those notations appear on fields at the end of the > frames. At least for ETCO as documented for ID3v2.3, I don't believe this is correct. The spec states that there can be a list of events in the frame of the format: Type of event $xx Time stamp $xx (xx ...) So there could be multiple events included and simply including everything in the list (or the rest of the frame) would not work. I could be totally wrong about this though. I've never used any of these frames. ----- Original Message ----- From: "Ben Bennett" To: Sent: Sunday, December 31, 2006 7:31 PM Subject: Re: [ID3 Dev] $xx (xx ...) > On Sun, Dec 31, 2006 at 06:18:20PM -0500, Mitchell S. Honnert wrote: > > OK. I give up. It's probably that I'm just not seeing it, but I can't find > > any definition of this format. > > > > $xx (xx ...) > > It means one or more bytes. > > ... > > > I'm going to feel pretty silly if I've just overlooked this, but I honestly > > can't find it. So, wow are you supposed to know how many bytes are > > represented by the "(xx ...)"? > > It means as many bytes are left in the frame (based on the frame > size). All of those notations appear on fields at the end of the > frames. > > However, I don't believe it is explicitly stated anywhere. And it > would be good to call it out. > > -ben > > --------------------------------------------------------------------- > 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 Mon Dec 25 18:56:06 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Mon, 25 Dec 2006 21:56:06 -0500 Subject: [ID3 Dev] updates to existing ID3v2 standards? In-Reply-To: <20061226020703.GA24009@ayup.limey.net> Message-ID: <20061226025611.HSHS6736.gx5.fuse.net@avoca> >I wholeheartedly agree with the idea of opening 2.4.0 up for >revision (to produce 2.4.1). I probably should have spelled it out more clearly -- oh, irony -- but I was also proposing that the ID3 v2.3 be opened up for revision. In fact, given v2.3's ongoing popularity, it's probably more important to make some clarifications/tweaks to that version. Obviously many of the revisions would apply to both v2.3 and v2.4, but for me the driving factor would be the changes to the v2.3 spec. - Mitchell S. Honnert -----Original Message----- From: Ben Bennett [mailto:fiji at ayup.limey.net] Sent: Monday, December 25, 2006 9:07 PM To: id3v2 at id3.org Subject: Re: [ID3 Dev] updates to existing ID3v2 standards? I wholeheartedly agree with the idea of opening 2.4.0 up for revision (to produce 2.4.1). Another proposal would be to LOUDLY scream that the frame length must be a syncsafe integer, and if you claim 2.4.1 compliance then goddamnit you had better be emmitting syncsafe ints (APPLE!). Of course that is not a change from 2.4.0, but it is hit or miss what people will do. -ben On Mon, Dec 25, 2006 at 08:03:51PM -0500, Mitchell S. Honnert wrote: > [OK, this got to be a lot longer than I had intended, but I found it was > necessary to use this much space to fully explain my request. - MSH] > > > > I'd like to propose that we open up the existing ID3 specifications for > updates in order to make clarifications or to make slight tweaks to existing > sections. I understand that there are risks in changing standards > documentation after they've been published, but based on what I've seen, > more harm is being done by ambiguous and sometimes downright confusing ID3 > documentation than the potential harm of changing the documentation after > the fact. The normal process of publishing new, updated versions of a spec > just doesn't work with ID3. (ID3v2.4 has been out for a long time and > ID3v2.3 is still far more popular.) I think we could make some relatively > small changes that would have a large beneficial impact. By limiting the > updates to the two very specific cases below, I think we could adhere to the > principle that no update would break existing implementations. (A principle > which we've already used recently when adding the accessibility frames.) > > > > 1) Clarifications of an existing specification which don't change the spec > > I've been working with the ID3 specs for years now (in my work on my own ID3 > library) so I'm familiar with many of their quirks and eccentricities of the > documentation. But even other supporters of the ID3 format would have to > admit that some of the specifications can be confusing to a brand new > reader. Sure, there are sources outside the spec (such as the ID3.org FAQ > and this discussion list itself), but why not just update the spec itself to > eliminate the confusion? I think that with some relatively minor edits, we > could make the standard much more clear and user-friendly. Of course we'd > have to come up with a consensus on what certain specs actually meant. But > wouldn't it be better to do that work once rather than leave it to be done > every time a new developer sits down to implement the standard? > > > > 2) Slight alteration of an existing standard in light of de facto standards > used by overwhelming majority of ID3 apps/libs > > Standards are nice and everything, but in the end, their success can be > measured by their compliance. What use is having a standard frame format > that is all but ignored? Wouldn't it be better to acquiesce to the real > implementations out there than to stubbornly hold on to what has become an > irrelevant and ignored section of the standard? Again, I'm not saying to > remove support for any feature; just to tweak a standard so that it would > also comply with existing implementations. I think we could tweak a frame's > specification slightly, thus updating it to support both the existing spec > as well as a de facto standard. I'm not saying to change the spec willy > nilly to match existing implementations. (Just because iTunes or WinAmp > does something a particular way, doesn't make it the best or right way.) > Instead we would add to the spec so that it matches implementations that > don't necessarily conform to how the spec was written, but in hindsight > conforms to how the spec should have been written. > > > > (I'm hoping that the use of the ID3.org Wiki, with its revision history, > will alleviate some of the hesitation to make the kinds of changes I > suggest.) > > > > Because the Genre/Content Type/TCON frame is what got me thinking about this > topic, I'll use it as an example. I consider myself to be a staunch > supporter of the ID3 format, but I have to say that the ID3 v2 > specifications for the TCON frame are just plain awful. Why in the world > would you add the level of complexity to the frame's format by including the > ID3v1 genre numbers, especially since the spec itself admits that the > "category list would be impossible to maintain with accurate and up to date > categories"? To use the example in the TCON spec, what is the point of > having "(4)Eurodisco" (where 4 is the ID3v1 Genre number for "Disco") when > "Eurodisco" by itself would do just fine? > > > > I don't think that the goal of the TCON frame was to create a > subcategorization system whereby you could represent "Disco with a > subcategory of Eurodisco". But this is what is implied by the TCON spec. > According to a literal reading of the TCON frame spec, custom genres are not > allowed, only custom refinements to the standard genres. WinAmp allows you > to type in "Eurodisco" into the Genre field? Sorry, according to the > existing spec, you should have to select "Disco" from a finite list of > values, then type in "Eurodisco" as a modifier so that WinAmp can store > "(4)Eurodisco" in the TCON frame. Why do we have a spec, that as written, > nobody implements? Why would we want to leave developers saying "Well, > surely that's not what they really meant" when we can clarify what was > really meant? > > > > So, how do I think we should update the TCON frame spec? Well, if we > acknowledge that the vast majority of ID3v2 implementations ignore the silly > parenthetical ID3v1 Genre number, then I would reword the frame's spec to > describe a simple null-delimited list of custom genre strings. For backward > compatibility's sake, I would place the "(4)Eurodisco" format gobbledygook > in an "Optional" section. Also, the TCON spec states that multiple genres > are supported, but without some rather subjective interpretations of the > spec, I don't see how it's supposed to be done. (Unless you only use the > numeric sections as delimiters for the "refinements", the spec doesn't make > any sense for multiple genres.) Personally, if we did nothing more than > promote the use of multiple genres by tweaking the TCON spec, I'd consider > it a great success. Oh, and I'd also correct the spelling of "numerig". > > > > The details of changes aren't so important now. I'm sure that there would > be much discussion by the members of this over what would be changed and > how. I admit that I have some strong opinions on how the TCON spec could be > improved, but my goal for this e-mail was to get input on whether updates > like this would even be accepted. > > > > For the record, I don't make this suggestion lightly. I understand the > problems associated with altering an existing specification. But I think > that failing to bring the spec in line with reality is actually causing more > harm than good. Because the specs have remained in the original state, > along with all of their original flaws, developers have for years been left > to their own subjective judgments on how best to implement > ambiguously-worded specs. This has, I believe, led to a fracturing of the > standard. We can't do much about existing implementations, especially those > coded into hardware devices. But we could make it easier for anyone else > trying to implement the standard. I believe that the people on this list > are the wardens of the ID3 standard. And as the wardens, I believe that it > our responsibility to do what we can to minimize further fracturing, even if > it means retrofitting the standard to fit "noncompliant" implementations. > In short, I think we can make compromises on the ID3 standard without > compromising the ID3 standard. > > > > Mitchell S. Honnert > > www.UltraID3Lib.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 fiji at ayup.limey.net Thu Dec 14 21:37:11 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 15 Dec 2006 00:37:11 -0500 Subject: [ID3 Dev] Announcing an ID3v2 wiki... In-Reply-To: <20061115193745.GA15034@ayup.limey.net> References: <20061114202159.GA31545@ayup.limey.net> <20061115193745.GA15034@ayup.limey.net> Message-ID: <20061215053711.GA18084@ayup.limey.net> On Wed, Nov 15, 2006 at 02:37:45PM -0500, Ben Bennett wrote: > > Anyway, if you are serious about this we should set up a wiki > somewhere (I can host it I suppose) and make some sample frames that > we can use for conformance testing. Then maintain a compatability > matrix of the various programs with respect to the sample frames. > > We should also open the 2.4 spec up for comments, but restrict it > solely to clarifications. > > I want to make a separate document that updates the programming > guidelines and discusses how to write "safe" tags. > > Comments? Who is with me? So, I finally got around to starting work on this. I have a wiki set up with some rudimentary content. I will be revising and adding stuff. Please look, comment, and add to it! http://limey.net/id3wiki/ -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Wed Dec 20 23:58:12 2006 From: id3v2 at northpb.com (Dan O'Neill) Date: Wed, 20 Dec 2006 23:58:12 -0800 Subject: [ID3 Dev] Announcing an ID3v2 wiki... In-Reply-To: <20061218003356.GA21478@ayup.limey.net> References: <20061114202159.GA31545@ayup.limey.net> <20061115193745.GA15034@ayup.limey.net> <20061215053711.GA18084@ayup.limey.net> <4585B7AB.8030104@northpb.com> <20061218003356.GA21478@ayup.limey.net> Message-ID: <458A3E94.5030504@northpb.com> Ben Bennett wrote: > On Sun, Dec 17, 2006 at 01:33:31PM -0800, Dan O'Neill wrote: > > I created BenBennett. Is it possible that we can make the world able > to edit? The studies of Wikipedia seem to indicate that first-time > people generate the backbone of wikipedia by writing long articles on > topics they know. Whereas the hard-core wikipedia people polish and > edit the articles. I added BenBennett to the EditorsGroup. The wiki is live as the default for id3.org. At the moment I'm going to defer to adding Editors upon request. There is one page that can be edited by anyone who is logged into their account. http://www.id3.org/Implementations > Sounds good. Although I think the published specs need to be frozen > somehow. It would be nice to have an annotated version as long as it > is noted as not being authoritative. Good suggestion. The existing standards have been frozen to modification only by their respective authors. Legacy URL's have been rewritten and redirected so that external links continue to get people to the right pages. Of course, if you notice bugs or oddities, please send a note to me or this list. Sincerly, dano --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From jmartin92 at comcast.net Sun Dec 31 16:40:18 2006 From: jmartin92 at comcast.net (Jim) Date: Sun, 31 Dec 2006 19:40:18 -0500 Subject: [ID3 Dev] $xx (xx ...) References: <20061231231825.JJFX6736.gx5.fuse.net@avoca> Message-ID: <688201c72d3d$6cc25ac0$6501a8c0@xp1800desk> I believe there is a field for each of these tags that will tell you how many bytes to expect. For example, for ETCO,
Time stamp format $xx Where time stamp format is: $01 Absolute time, 32 bit sized, using MPEG frames as unit $02 Absolute time, 32 bit sized, using milliseconds as unit Abolute time means that every stamp contains the time from the beginning of the file (that was taken from the ID3v2.3 spec) So for both cases you would expect 32 bits (or 4 bytes) for the time stamp. There are similar fields for each of the types of frames you cited. Check the specs again. (SYLT and POSS have the same type of field as ETCO. I think EQUA is only found in ID3v2.3 and has a different field but is documented in the spec.) ----- Original Message ----- From: "Mitchell S. Honnert" To: Sent: Sunday, December 31, 2006 6:18 PM Subject: [ID3 Dev] $xx (xx ...) > OK. I give up. It's probably that I'm just not seeing it, but I can't find > any definition of this format. > > $xx (xx ...) > > I've found this pattern in the following frames... > > Event timing codes ETCO > Synchronised lyrics/text SYLT > Equalisation EQUA > Position synchronisation frame POSS > > ...and it relates to the Time Stamp or the Adjustment numeric field of the > respective tag. > > The format appears to translate to "a number consisting of one or more > bytes". But how are you supposed to know *how many* bytes more than one? > > At first I thought there might be some kind of flag in the frame that would > tell you how many bytes each TimeStamp/Adjustment number used, but I > couldn't find it. Then I thought that perhaps I could deduce the byte count > by using some pattern matching, but I couldn't come up with anything > definition. > > I even reversed engineered the Synchronized Lyrics frame created by Windows > Media Player to see how they did it, but they appear just to have hard-coded > the Time Stamp to four bytes. > > I'm going to feel pretty silly if I've just overlooked this, but I honestly > can't find it. So, wow are you supposed to know how many bytes are > represented by the "(xx ...)"? > > - Mitchell S. Honnert > > PS: This is yet another example of where we could make tweaks to current ID3 > versions (ID3v2.3 and ID3v2.4). Specifically, if most ID3 developers were > forced to interpret "$xx (xx ...)" as "$xx xx xx xx" because of ambiguous or > missing ID3 documentation, then we should just accept that this is the new > standard and document it accordingly. (And even if this is in the > documentation somewhere -- which is entirely possible -- we could at least > tweak the standards to make it more prominent.) > > > > --------------------------------------------------------------------- > 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 Mon Dec 25 17:03:51 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Mon, 25 Dec 2006 20:03:51 -0500 Subject: [ID3 Dev] updates to existing ID3v2 standards? Message-ID: <20061226010356.HMCI6736.gx5.fuse.net@avoca> [OK, this got to be a lot longer than I had intended, but I found it was necessary to use this much space to fully explain my request. - MSH] I'd like to propose that we open up the existing ID3 specifications for updates in order to make clarifications or to make slight tweaks to existing sections. I understand that there are risks in changing standards documentation after they've been published, but based on what I've seen, more harm is being done by ambiguous and sometimes downright confusing ID3 documentation than the potential harm of changing the documentation after the fact. The normal process of publishing new, updated versions of a spec just doesn't work with ID3. (ID3v2.4 has been out for a long time and ID3v2.3 is still far more popular.) I think we could make some relatively small changes that would have a large beneficial impact. By limiting the updates to the two very specific cases below, I think we could adhere to the principle that no update would break existing implementations. (A principle which we've already used recently when adding the accessibility frames.) 1) Clarifications of an existing specification which don't change the spec I've been working with the ID3 specs for years now (in my work on my own ID3 library) so I'm familiar with many of their quirks and eccentricities of the documentation. But even other supporters of the ID3 format would have to admit that some of the specifications can be confusing to a brand new reader. Sure, there are sources outside the spec (such as the ID3.org FAQ and this discussion list itself), but why not just update the spec itself to eliminate the confusion? I think that with some relatively minor edits, we could make the standard much more clear and user-friendly. Of course we'd have to come up with a consensus on what certain specs actually meant. But wouldn't it be better to do that work once rather than leave it to be done every time a new developer sits down to implement the standard? 2) Slight alteration of an existing standard in light of de facto standards used by overwhelming majority of ID3 apps/libs Standards are nice and everything, but in the end, their success can be measured by their compliance. What use is having a standard frame format that is all but ignored? Wouldn't it be better to acquiesce to the real implementations out there than to stubbornly hold on to what has become an irrelevant and ignored section of the standard? Again, I'm not saying to remove support for any feature; just to tweak a standard so that it would also comply with existing implementations. I think we could tweak a frame's specification slightly, thus updating it to support both the existing spec as well as a de facto standard. I'm not saying to change the spec willy nilly to match existing implementations. (Just because iTunes or WinAmp does something a particular way, doesn't make it the best or right way.) Instead we would add to the spec so that it matches implementations that don't necessarily conform to how the spec was written, but in hindsight conforms to how the spec should have been written. (I'm hoping that the use of the ID3.org Wiki, with its revision history, will alleviate some of the hesitation to make the kinds of changes I suggest.) Because the Genre/Content Type/TCON frame is what got me thinking about this topic, I'll use it as an example. I consider myself to be a staunch supporter of the ID3 format, but I have to say that the ID3 v2 specifications for the TCON frame are just plain awful. Why in the world would you add the level of complexity to the frame's format by including the ID3v1 genre numbers, especially since the spec itself admits that the "category list would be impossible to maintain with accurate and up to date categories"? To use the example in the TCON spec, what is the point of having "(4)Eurodisco" (where 4 is the ID3v1 Genre number for "Disco") when "Eurodisco" by itself would do just fine? I don't think that the goal of the TCON frame was to create a subcategorization system whereby you could represent "Disco with a subcategory of Eurodisco". But this is what is implied by the TCON spec. According to a literal reading of the TCON frame spec, custom genres are not allowed, only custom refinements to the standard genres. WinAmp allows you to type in "Eurodisco" into the Genre field? Sorry, according to the existing spec, you should have to select "Disco" from a finite list of values, then type in "Eurodisco" as a modifier so that WinAmp can store "(4)Eurodisco" in the TCON frame. Why do we have a spec, that as written, nobody implements? Why would we want to leave developers saying "Well, surely that's not what they really meant" when we can clarify what was really meant? So, how do I think we should update the TCON frame spec? Well, if we acknowledge that the vast majority of ID3v2 implementations ignore the silly parenthetical ID3v1 Genre number, then I would reword the frame's spec to describe a simple null-delimited list of custom genre strings. For backward compatibility's sake, I would place the "(4)Eurodisco" format gobbledygook in an "Optional" section. Also, the TCON spec states that multiple genres are supported, but without some rather subjective interpretations of the spec, I don't see how it's supposed to be done. (Unless you only use the numeric sections as delimiters for the "refinements", the spec doesn't make any sense for multiple genres.) Personally, if we did nothing more than promote the use of multiple genres by tweaking the TCON spec, I'd consider it a great success. Oh, and I'd also correct the spelling of "numerig". The details of changes aren't so important now. I'm sure that there would be much discussion by the members of this over what would be changed and how. I admit that I have some strong opinions on how the TCON spec could be improved, but my goal for this e-mail was to get input on whether updates like this would even be accepted. For the record, I don't make this suggestion lightly. I understand the problems associated with altering an existing specification. But I think that failing to bring the spec in line with reality is actually causing more harm than good. Because the specs have remained in the original state, along with all of their original flaws, developers have for years been left to their own subjective judgments on how best to implement ambiguously-worded specs. This has, I believe, led to a fracturing of the standard. We can't do much about existing implementations, especially those coded into hardware devices. But we could make it easier for anyone else trying to implement the standard. I believe that the people on this list are the wardens of the ID3 standard. And as the wardens, I believe that it our responsibility to do what we can to minimize further fracturing, even if it means retrofitting the standard to fit "noncompliant" implementations. In short, I think we can make compromises on the ID3 standard without compromising the ID3 standard. Mitchell S. Honnert www.UltraID3Lib.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch at honnert.com Sun Dec 31 15:18:20 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sun, 31 Dec 2006 18:18:20 -0500 Subject: [ID3 Dev] $xx (xx ...) Message-ID: <20061231231825.JJFX6736.gx5.fuse.net@avoca> OK. I give up. It's probably that I'm just not seeing it, but I can't find any definition of this format. $xx (xx ...) I've found this pattern in the following frames... Event timing codes ETCO Synchronised lyrics/text SYLT Equalisation EQUA Position synchronisation frame POSS ...and it relates to the Time Stamp or the Adjustment numeric field of the respective tag. The format appears to translate to "a number consisting of one or more bytes". But how are you supposed to know *how many* bytes more than one? At first I thought there might be some kind of flag in the frame that would tell you how many bytes each TimeStamp/Adjustment number used, but I couldn't find it. Then I thought that perhaps I could deduce the byte count by using some pattern matching, but I couldn't come up with anything definition. I even reversed engineered the Synchronized Lyrics frame created by Windows Media Player to see how they did it, but they appear just to have hard-coded the Time Stamp to four bytes. I'm going to feel pretty silly if I've just overlooked this, but I honestly can't find it. So, wow are you supposed to know how many bytes are represented by the "(xx ...)"? - Mitchell S. Honnert PS: This is yet another example of where we could make tweaks to current ID3 versions (ID3v2.3 and ID3v2.4). Specifically, if most ID3 developers were forced to interpret "$xx (xx ...)" as "$xx xx xx xx" because of ambiguous or missing ID3 documentation, then we should just accept that this is the new standard and document it accordingly. (And even if this is in the documentation somewhere -- which is entirely possible -- we could at least tweak the standards to make it more prominent.) --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From dano at northpb.com Sun Dec 17 13:33:31 2006 From: dano at northpb.com (Dan O'Neill) Date: Sun, 17 Dec 2006 13:33:31 -0800 Subject: [ID3 Dev] Announcing an ID3v2 wiki... In-Reply-To: <20061215053711.GA18084@ayup.limey.net> References: <20061114202159.GA31545@ayup.limey.net> <20061115193745.GA15034@ayup.limey.net> <20061215053711.GA18084@ayup.limey.net> Message-ID: <4585B7AB.8030104@northpb.com> Ben Bennett wrote: > On Wed, Nov 15, 2006 at 02:37:45PM -0500, Ben Bennett wrote: >> Anyway, if you are serious about this we should set up a wiki >> somewhere (I can host it I suppose) and make some sample frames that >> we can use for conformance testing. Then maintain a compatability >> matrix of the various programs with respect to the sample frames. >> >> We should also open the 2.4 spec up for comments, but restrict it >> solely to clarifications. >> >> I want to make a separate document that updates the programming >> guidelines and discusses how to write "safe" tags. >> >> Comments? Who is with me? > > So, I finally got around to starting work on this. I have a wiki set > up with some rudimentary content. I will be revising and adding > stuff. Please look, comment, and add to it! > > http://limey.net/id3wiki/ Hi Ben - I guess we think alike. I was going to announce this and seek a few testers, but might as well put our efforts together. Here's the id3.org wiki, freshly setup over 8hrs yesterday and a few hours a month before - been busy with work you know. http://id3.org/id3/ If anyone on this list wants to be an Editor, just create an account on this page http://id3.org/id3/UserPreferences and email me your WikiName and I'll put you in the EditorsGroup. Ben, sorry that we both were doing things. I hope we can work together. The wiki at id3.org will become the default for id3.org once people have tested it a bit. Sincerely, dano --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Mon Dec 25 19:32:21 2006 From: fiji at ayup.limey.net (Ben Bennett) Date: Mon, 25 Dec 2006 22:32:21 -0500 Subject: [ID3 Dev] updates to existing ID3v2 standards? In-Reply-To: <20061226025611.HSHS6736.gx5.fuse.net@avoca> References: <20061226020703.GA24009@ayup.limey.net> <20061226025611.HSHS6736.gx5.fuse.net@avoca> Message-ID: <20061226033221.GA25918@ayup.limey.net> On Mon, Dec 25, 2006 at 09:56:06PM -0500, Mitchell S. Honnert wrote: > I probably should have spelled it out more clearly -- oh, irony -- but I was > also proposing that the ID3 v2.3 be opened up for revision. In fact, given > v2.3's ongoing popularity, it's probably more important to make some > clarifications/tweaks to that version. Obviously many of the revisions > would apply to both v2.3 and v2.4, but for me the driving factor would be > the changes to the v2.3 spec. That is also a fine idea. I have proposed adding UTF-8 support to 2.3 before on this list. That would be quite useful since UTF-16 is overkill (for Latin based languages) and frankly, I don't trust the players to do the right thing. Although 2.4 support is creaping out there. iTunes has (broken) support for it, Amarok will only write 2.4, and so on... -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org