[Bug 225055] audio/mp3splt: the default encoding for ID3v2 tags should be UTF-16BE, not UTF-16LE

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225055

--- Comment #3 from Anton Yuzhaninov <citrin+pr at citrin.ru> ---
I've looked at my mp3 file written by mp3splt in hd(1) - unfortunately I
haven't found a more usable tool which can show all relevant information.

In a hex dump I can see:
1. mp3splt writes ID3 V2.4.0 tags
2. text frames contain encoding description byte $01 (UTF-16 with BOM) followed
by BOM $feff (big endian) and then followed by text encoded in UTF-16 BE.

So as I can see this ID3 tag confirms ID3 specification. Only issue I can see -
mp3splt always writes TIT2, TPE1, TALB, TCON frames in UTF-16 encoding, even
when the text can be represented as ISO-8859-1 or even ASCII.

Probably your hardware player doesn't support UTF-16/UCS-2 and expects all
strings to be in ISO-8859-1.

For better compatibility with incomplete player implementations we can check if
text can be encoded as ISO-8859-1 and use $00 text description byte
(ISO-8859-1) with text in ISO-8859-1. But I'm not sure where it is better to
implement this auto-detection: in mp3splt or in libid3tag (library used by
mp3splt for writing tags). Unfortunately libid3tag is also not actively
developed - last release was in 2004.

I think -C 8 (utf-8) works for this player only by accident - ASCII text in
UTF-8 and ISO-8859-1 are the same sequence of bytes. Changing default option to
-C 8 is a bad option - there are implementations (players) which support UTF-16
(present V2.2.0), but not UTF-8 (was added only in V2.4.0).

-- 
You are receiving this mail because:
You are the assignee for the bug.