<div><div>Hi,<br><br>I'm not so sure about the first issue, but the remainder I may be able to help explain.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I am not sure if all strings in TextIdentification frames should be<br>null terminated, because TagLib doesn't do so. I checked with some<br>other Win32 tag editing programs. They do use null terminated strings.</blockquote>
<div><br>String are only null terminated when explicitly stated in the specifications. Otherwise they are only <span style="font-weight: bold;">null separated</span>. 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
<span style="font-weight: bold;">bad behavior</span> and doing so could cause files to be misread by other readers.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3. Since the TDRC is a string of recording time, shouldn't it be<br>allowed to contain more than a numerical value? some other id3 editor<br>may insert like 7/1/2006... and this won't work with TagLib</blockquote><div><br>
All dates must be stored in the following formats:<br><pre> yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and<br> yyyy-MM-ddTHH:mm:ss</pre></div>Any deviation of this is <span style="font-weight: bold;">bad behavior
</span>. 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.<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
4. One last note: is it possible that TagLib can preserve the<br>original, unmodified, not converted field data especially for<br>TextIdentification frames and have a member function to access these<br>raw texts? The reason is for non-English tags, most of them are "not
<br>correctly encoded" in Unicode, but rather in their own local charsets.<br>Therefore, when TagLib convert all texts into UTF16 the information<br>may already be distorted. This is also why Winamp allows user to<br>
select the default non-standard charset (BMP also does this). Well,<br>obviously these special tags are something not complaint with the<br>standard. Unfortunately they are wild spreded. It would be too much to<br>ask TagLib to support these, but if TagLib could simply save a raw
<br>copy of the text when parsing, that would be wonderful.</blockquote><div><br>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.
</div></div><br>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.<br><br>
- Brian<br>