Hi David! Sorry for the long delay. I finally found time to rearrange this problem using the brandnew EasyTAG 2.1.8 and a Live-CD of Mate 14.1 (based on Ubuntu 12.10). I have created test files with different APIC description texts: 1. APIC_v2.3_ASCII.mp3 APIC desc. with ASCII chars only 2. APIC_v2.3_ISO-8859-1.mp3 APIC desc. with 'äöü' (within ISO-8859-1) 3. APIC_v2.3_NoDesc.mp3 No APIC text description at all 4. APIC_v2.3_UTF-16.mp3 APIC desc. with '←→' (Unicode only) 5. APIC_v2.4_UTF-8.mp3 APIC desc. with '←→' (Unicode only) The files are here: http://homepage.hispeed.ch/joos/oliver/APIC-Test.zip Number 1-4 were written by EasyTAG configured to ID3v2.3/UTF-16. Number 5 was written as ID3v2.4/UTF-8 (EasyTAG default settings). I attached a screenshot of a diagnosis of these files using MP3 Diags: 1-3 are ok, 4+5 have issues. And (no surprise) my Nokia Symbian S60 phone shows the APIC image for file 1-3, but shows no image for 4+5! So I still think that EasyTAG should add no (= empty) APIC text descriptions by default. An optimal fix could re-encode Unicode APIC descriptions to ISO-8859-1/TRANSLIT, at least for ID3v2.3 headers. (Players that are fully v2.4-capable might be fine with Unicode APIC descriptions) I sneaked at the source: id3v24_tag.c:1010 looks interesting. But until now I did not dare to fix it myself. I guess an EasyTAG expert is more efficient in fixing this and won't add regressions either. I'd like to correct my previous remarks (below) about EasyTAG falling back to ISO-8859-1 if possible, even if configured to UTF-16. Meanwhile this seems ok to me! For details see my answers below. With regards! +++ Oliver On 2013-01-10 21:48, David King <amigadave amigadave com> wrote:
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.
See attached screenshot, file #6, note #1
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?
Filename encoding does not seem to matter. As expected EasyTAG 2.1.8 re-encodes filenames according to its settings and UTF-16 may fallback to ISO-8859-1 if possible.
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.
What I meant here, is that UTF-16 may fallback to ISO-8859-1. And I'd like to justify: I do not consider this as a bug anymore!
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.
I don't think so. My usual locale is 'de_CH.UTF-8'. For my current tests I left it at the default locale of Mint 14.1, where EasyTAG starts with: "Currently using locale 'en_US.UTF-8' (and eventually 'ISO-8859-1')"
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!
I know. Earlier I tried to solve encoding problems by patching EasyTAG to use ID3v2.3/UTF-16 always, even for ASCII-only text tags! But I found that the fallback to ISO-8859-1 is not a problem (at least for my locale and my mp3 players/tools) +++ Oliver
Attachment:
EasyTag-Tests_with_MP3_Diags.png
Description: PNG image
