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?<BR><BR><B><I>Michal Vician <id3v2@audiott.com></I></B> wrote:  <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">> ...In this case specifically, I can certainly imagine an ID3 spec<BR>> that would be possible to implement completely, with less code,<BR>> without reducing the functionality provided.<BR><BR>As far as I'm concerned I don't have any problems with code lenght.<BR>But if have you any concrete ideas (I mean something like a sketch of new<BR>ID3 version), just post them. Maybe we can move ID3 spec forward.<BR><BR>Best regards<BR>Miso<BR><BR>> On Thursday 09 February 2006 22:16, Michal Vician wrote:<BR>>> Can't see the merit of deprecating frames. ID3v2 is proposed so
 frames<BR>>> you<BR>>> would like to deprecate doesn't limit/restrict you in any way. There is<BR>>> no<BR>>> need to deprecate them. So why do they annoy you?<BR>><BR>> Three notes:<BR>><BR>> - I'm mostly just babbling about what I would like to see for an ID3v2.5<BR>> or<BR>> ID3v3, so take this as such. I don't actually expect either of those<BR>> versions happen since it's been about 5 years since the last ID3 revision.<BR>> I<BR>> certainly don't expect a 2.4.1 or something to deprecate frames.<BR>><BR>> - For the moment I do just ignore them in my implementation. They're<BR>> parsed<BR>> as an "unknown frame".<BR>><BR>> - It's really about complexity and cleanliness. ID3v2 is too complex for<BR>> what it achieves (saying this as a person who has implemented several tag<BR>> formats). In theory, an ID3 spec could do basically everything that ID3v2<BR>> does now and be much easier to implement
 completely.<BR>><BR>> Basically a spec is only as good as its implementations. If portions of a<BR>> spec are wholesale ignored across many implementations, then it's probably<BR>> fair to say that the spec is too complicated. In this case specifically,<BR>> I<BR>> can certainly imagine an ID3 spec that would be possible to implement<BR>> completely, with less code, without reducing the functionality provided.<BR>> Adding more frames would just, in my opinion, increase the amount of ID3v2<BR>> that would be ignored by implementors.<BR>><BR>> Cheers,<BR>><BR>> -Scott<BR><BR><BR>-- <BR>Michal Vician<BR>id3v2@audiott.com<BR>http://www.audiott.com/<BR><BR><BR>---------------------------------------------------------------------<BR>To unsubscribe, e-mail: id3v2-unsubscribe@id3.org<BR>For additional commands, e-mail: id3v2-help@id3.org<BR><BR></BLOCKQUOTE><BR><p>
                <hr size=1><font face="Arial" size="2">To help you stay safe and secure online, we've developed the all new <a href="http://us.rd.yahoo.com/mail/uk/taglines/default/security_centre/*http://uk.security.yahoo.com/"><b>Yahoo! Security Centre</b></a>.</font>