Hi Oliver On 2013-03-13 15:08, Oliver <oliver joos freenet ch> wrote:
I checked the test files with hexdump against specs on id3.org. All fields look correct and correctly encoded as UTF-16 or ISO-8859-1, but:
Good to know, thanks.
IMO the actual bug is in mp3 players/tools like Symbian phones, causing them to fail upon APIC descriptions with UTF-16 characters! MP3 Diags knows such nasty facts and reports them.
It would be useful if MP3 Diags gave a precise diagnosis of the problem, as looking into this took quite a lot of time. Of course, I know the ID3 string encoding code in EasyTAG a lot better now, so it not wasted time. :-)
I would suggest reporting the bug to the phone manufacturer, but I suspect that it will not be fixed, so it may not be worth your time.
EasyTAG is absolutely correct according to ID3 specs! Nevertheless its results fail eventually. That's why I would not fix it by re-encoding UTF-16 APIC descriptions, but only change the default text from <filename> to empty.
That only avoids the problem until a character is entered in the description which triggers writing that field as UTF-16. It seems that a better way to solve this problem is to offer an override for the encoding of the APIC description, and potentially other fields if other readers and players do not follow the ID3 specification. I do not want to add such a feature to EasyTAG unless it could be made generic enough that it would be useful when writing tags for other buggy players, as otherwise it feels like a hack. Having said that, I do not know the prevalence nor specifics of buggy ID3 implementations, so this probably needs some research.
-- http://amigadave.com/
Attachment:
pgpBZWcKiaBd1.pgp
Description: PGP signature