https://bugs.kde.org/show_bug.cgi?id=524798
Urs Fleisch <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REPORTED |RESOLVED Resolution|--- |NOT A BUG --- Comment #8 from Urs Fleisch <[email protected]> --- I analyzed the problem, and it is now clear. First I saw that the file has an ID3v2.4 tag, so it must be parsed by TagLib (id3lib does not support ID3v2.4). So I read the file with TagLib's tagreader example and it showed wrong characters with all versions but the current master branch (which is used by the Kid3 development snapshot which you tried). So it must be a problem with TagLib or your file. Bisecting the problem, I found the commit "Validate enumerations decoded from file bytes before casting to them (#1420)" to be the one fixing the problem. Looking at the changes there and your file, one can see that the encoding in your file as a wrong code 'B', but it should be 0 for Latin 1. The mentioned commit falls back to 0 (Latin1) when an invalid encoding is found. This is a likely fallback for ID3v2, but it could still be wrong because there are also files with Unicode characters. So I would suggest that you use the latest development snapshot of Kid3 and its "Rewrite Tags" action (file list context menu) to fix the tags. By the way: I use "MP3 Diags" to verify if my MP3 files are correct. In the case of your example file, it shows "<error decoding frame>" for all frames. Here the details: --- TagLib v1.13.1 (last v1.x) $ examples/tagreader 113_-_Sure_Thing.mp3 ******************** "113_-_Sure_Thing.mp3" ******************** -- TAG (basic) -- title - "ueTig" artist - "en ie" album - "en ie" year - "0" comment - "" track - "0" genre - "ok" -- TAG (properties) -- ALBUM - "en ie" ARTIST - "en ie" DATE - "06" GENRE - "ok" TITLE - "ueTig" TRACKNUMBER - "1" -- AUDIO -- bitrate - 320 sample rate - 44100 channels - 2 length - 2:39 --- TagLib v2.0...v2.3.1 (all released v2.x until now) $ examples/tagreader 113_-_Sure_Thing.mp3 ******************** "113_-_Sure_Thing.mp3" ******************** -- TAG (basic) -- title - "卵牥⁔桩湧" artist - "䱥慮渠剩浥" album - "䱥慮渠剩浥" year - "0" comment - "" track - "0" genre - "副捫" -- TAG (properties) -- ALBUM - "䱥慮渠剩浥" ARTIST - "䱥慮渠剩浥" DATE - "㈰㈶" GENRE - "副捫" TITLE - "卵牥⁔桩湧" TRACKNUMBER - "ㄱ" -- AUDIO -- bitrate - 320 sample rate - 44100 channels - 2 length - 2:39 --- TagLib master since ee0ab489 ("Validate enumerations decoded from file bytes before casting to them (#1420)", 2026-08-16) $ examples/tagreader 113_-_Sure_Thing.mp3 ******************** "113_-_Sure_Thing.mp3" ******************** -- TAG (basic) -- title - "Sure Thing" artist - "Leann Rimes" album - "Leann Rimes" year - "2026" comment - "" track - "113" genre - "Rock" -- TAG (properties) -- ALBUM - "Leann Rimes" ARTIST - "Leann Rimes" DATE - "2026" GENRE - "Rock" TITLE - "Sure Thing" TRACKNUMBER - "113" -- AUDIO -- bitrate - 320 sample rate - 44100 channels - 2 length - 2:39 The relevant code is inline String::Type textEncodingFromByte(char c) { switch(static_cast<unsigned char>(c)) { case String::Latin1: case String::UTF16: case String::UTF16BE: case String::UTF8: case String::UTF16LE: return static_cast<String::Type>(static_cast<unsigned char>(c)); default: return String::Latin1; } } Your example file contains 66 'B' (0x42) as the text encoding byte, which is invalid (valid values are 0 to 4). Since the "Validate enumerations" fix, such invalid values are transformed to 0 (Latin1). Until then, the wrong encoding type was passed to TagLib's String constructor which falls back to UTF16, which results in these Chinese characters. You can easily verify these findings. $ xxd 113_-_Sure_Thing.mp3 | head -8 00000000: 4944 3304 0000 0000 0834 5452 434b 0000 ID3......4TRCK.. 00000010: 0004 0000 4231 3133 5450 4531 0000 000c ....B113TPE1.... 00000020: 0000 424c 6561 6e6e 2052 696d 6573 5443 ..BLeann RimesTC 00000030: 4f4e 0000 0005 0000 4252 6f63 6b54 4954 ON......BRockTIT 00000040: 3200 0000 0b00 0042 5375 7265 2054 6869 2......BSure Thi 00000050: 6e67 5441 4c42 0000 000c 0000 424c 6561 ngTALB......BLea 00000060: 6e6e 2052 696d 6573 5444 5243 0000 0005 nn RimesTDRC.... 00000070: 0000 4232 3032 3600 0000 0000 0000 0000 ..B2026......... The tag is ID3v2.4 ("ID3\x04") (therefore always handled by TagLib). The first frame is ID="TRCK", Size=0x00000004, Flags=0000, Encoding=0x42 (invalid!), Information="113". -- You are receiving this mail because: You are watching all bug changes.
