id3 tag general issues

[Brian Kerrick Nickel]

Hi,

I'm not so sure about the first issue, but the remainder I may be able to
help explain.

I am not sure if all strings in TextIdentification frames should be
> null terminated, because TagLib doesn't do so. I checked with some
> other Win32 tag editing programs. They do use null terminated strings.


String are only null terminated when explicitly stated in the
specifications. Otherwise they are only null separated. As all strings are
null separated lists, appending a null terminator at the end would result in
an empty string in the list. eg. "Foobar\0" -> { "Foobar", "" } or "Artist
1\0Artist 2\0" -> { "Artist 1", "Artist 2", "" }. This is bad behavior and
doing so could cause files to be misread by other readers.

3. Since the TDRC is a string of recording time, shouldn't it be
> allowed to contain more than a numerical value? some other id3 editor
> may insert like 7/1/2006... and this won't work with TagLib


All dates must be stored in the following formats:

   yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and
   yyyy-MM-ddTHH:mm:ss

Any deviation of this is bad behavior. It would be hard for TagLib to
correctly identify what is meant by "06/02/08" or any number of possible
combinations, so it is best to just go by the book.

4. One last note: is it possible that TagLib can preserve the
> original, unmodified, not converted field data especially for
> TextIdentification frames and have a member function to access these
> raw texts? The reason is for non-English tags, most of them are "not
> correctly encoded" in Unicode, but rather in their own local charsets.
> Therefore, when TagLib convert all texts into UTF16 the information
> may already be distorted. This is also why Winamp allows user to
> select the default non-standard charset (BMP also does this).  Well,
> obviously these special tags are something not complaint with the
> standard. Unfortunately they are wild spreded. It would be too much to
> ask TagLib to support these, but if TagLib could simply save a raw
> copy of the text when parsing, that would be wonderful.


One thing you could do for this, and all your problems, is create your own
MooweiTextIndentificationFrame which will allow you to read and transform
incorrectly encoded strings and do a copy/paste job with the FrameFactory so
it supports your class.

TagLib really isn't a hack and workaround library, but it leaves doors open
for you if you need it. A custom Id3v2 FrameFactory really is the best route
to take for dealing with non-standard behavior.

- Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/taglib-devel/attachments/20060701/e762b0dc/attachment.html