On 2013-01-10 14:20, Oliver <oliver joos freenet ch> wrote:
I encountered a problem with APIC tags (images within ID3 headers). My Nokia N81 (Symbian S60 3rd) doesn't show *SOME* images, although they have reasonable size, format and type (I use 320x320, jpg, Frontcover). The Linux tag editor "mp3diags" (1.0.07.052) shows errors for exactly these failing APIC tags.
Can you say what the error is, or give a link to a sample file? Just the ID3 header should be fine, but the whole file is OK if you do not know how to split it.
I found that the problem is caused by the encoding of the description text in these APIC tags! By default EasyTAG uses the filename of the image as description, encoded in UTF16. If this text contains non-ASCII characters (e.g. German ä ö ü) then errors occur. If the text is re-encoded to ISO-8859-1 then the Nokia N81 and mp3diags have no problems even with the special characters.
Like most text used in frames in the ID3v2 specification, the description of an APIC tag has a defined encoding. EasyTAG handles this in the same way for such text fields, and the destination character encoding can be set in the preferences (for me EasyTAG defaults to ID3v2.4 and UTF-8 encoding). I suspect that there is a problem with the description field because the source string is from a filename, which on Linux is generally in a locale-defined encoding.
Do you know what encoding is used for the filename of the image that you are adding, and whether it matches the encoding of your locale?
I propose that by default the description text should be empty, and/or that the text encoding should be ISO-8859-1 if possible. The latter would be consistent since EasyTAG already does this for other ID3 texts: it encodes ID3 tags with ISO-8859-1 if possible, even if I choose UTF16 for tag text encoding. I don't know if this is a bug or a feature, but it has been ok for all my use-cases so far.
There is some logic to use ISO-8859-1 for fields that require it, such as the URL field, but generic string fields (including the image description) can use several encodings. If EasyTAG is converting all the strings to an encoding that is different to that which you have set in the preferences, then it is likely a bug.
One possibility is that EasyTAG has determined your locale encoding incorrectly. You can check this in the log at startup, which should say "Currently using locale '%s' (and eventually '%s')" where the first %s should be your locale (including the encoding) and the second should be what EasyTAG has determined the locale encoding to be. A peculiarity is that for Western European locales, EasyTAG will determine the locale encoding to be ISO-8859-1 before ignoring it and using the encoding in the preferences!
Thanks for your report. -- http://amigadave.com/
Attachment:
pgpBe6srItKrR.pgp
Description: PGP signature