On Tue, 2005-12-06 at 19:00 -0800, Michaelwagner wrote: > I just took a quick boo at the CPAN code for reading ID3 tags. Searching > for the string "30" gets me the following comment: > > > Fields are TITLE, ARTIST, ALBUM, YEAR, COMMENT, GENRE. All fields have a > > 30 byte limit, except for YEAR, which has a four-byte limit, and GENRE, > > which is one byte in the file. > > Now the comment is in the section for reading V1 tags
The ID3 V1 spec put all of the tag in one 128 byte block. So there were hard limits, and small ones at that, on all the fields. Genre being one byte with only 60 values defined is something that curses us even today. Your hypothesis that the magic 30 number polluted other parts of the later implementations is probably right. But there is no way of knowing. A more fundamental problem is that the ID3 spec is essentially ad-hoc. There is no "approval" process, board, etc. like we are used to seeing for Internet RFCs or CCITT standards or IEEE, etc. It looks, altho it is impossible to know, that the ID3 site is a labor of love by a very small group of people, maybe even one guy. The lack of standards leads to a lack of test cases to validate that an ID3 V2.4 (or any other version) implementation actually works. So lots of code out there mostly works. Or uses a library from CPAN or an equivalent, which itself can't be validated. At this point, its essentially out in the open, with no control. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html _______________________________________________ Discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
