kid3 corrupts the tags. After processing files in kid3, some players, for example, aimp, display the control character “B” in tag versions 2.3 and 2.4. 1. Load the files into the program. 2. Fill in the information about the composition. 3. Apply tags of version 2.3 or 2.4, save. 4. Load the files into aimp. We observe an extra character “B” in all or some fields.
Please provide more information. I need a way to reproduce the issue. Provide me an example file (or the beginning of a file, because ID3v2 tags are usually at the beginning of a file) and instructions how to create a corrupted file. You can additionally also attach a corrupted file. With the currently provided information, I cannot reproduce the issue.
Are you sure that Kid3 is the problem and not AIMP? Here's how Gemini views the matter: It is very likely that AIMP is misinterpreting the ID3v2 metadata rather than Kid3 corrupting it. Here is an analysis of why this occurs and why AIMP is the probable culprit: --- ### 1. What the "B" Character Control Artifact Usually Means In ID3v2 tags (both v2.3 and v2.4), text fields begin with an **Encoding Byte** (a single byte prefix before the actual string data) that tells parsers how to decode the character string: * `0x00`: ISO-8859-1 (Latin-1) * `0x01`: UTF-16 with BOM (Byte Order Mark) * `0x02`: UTF-16BE without BOM * `0x03`: UTF-8 (valid in ID3v2.4) When text is written in **UTF-16 with BOM**, the string starts with two bytes: `0xFE 0xFF` (Big-Endian) or `0xFF 0xFE` (Little-Endian). If a player fails to recognize UTF-16 encoding correctly—or mishandles the encoding descriptor byte/BOM when reading ID3v2.3 tags—it will treat the BOM bytes as raw ASCII/Latin-1 text. * In ASCII/Latin-1 or certain Windows codepages (like Windows-1251), byte values around `0xFE`/`0xFF` or raw UTF-16 representation can render as weird glyphs or **control/garbage characters** (often looking like `B`, `þÿ`, or `ÿþ`). ### 2. ID3v2 Spec Compliance: Kid3 vs. AIMP * **Kid3** uses well-established tag libraries (`TagLib` or its internal ID3 parser) that strictly comply with the ID3v2 specification. Kid3 correctly writes the encoding byte prefix and UTF-16 BOM when saving tags in ID3v2.3 mode (which requires UTF-16 for Unicode). * **AIMP** historically relies on its own custom ID3 parser. Older versions or specific configurations of AIMP are known to have bugs where they incorrectly strip or misinterpret the leading encoding byte/BOM on certain frames (like `TIT2`, `TPE1`, or custom `TXXX` frames), treating the metadata as plain Latin-1 instead of UTF-16. ### 3. How to Verify To confirm whether Kid3 wrote standard tags or if AIMP is at fault: 1. **Check with `ffprobe` / `id3v2` / `TagLib` CLI tools:** Inspect the raw tag structure of a processed file using a third command-line tool: ```bash ffprobe -show_format -print_format json "your_file.mp3" ``` If command-line tools, VLC, or MPV display the text cleanly without any "B" character, Kid3 wrote standard-compliant ID3v2 tags. 2. **Test ID3v2.3 Text Encoding Settings in Kid3:** In Kid3, go to **Settings → Configure Kid3 → Tags → ID3v2** and check the default text encoding: * ID3v2.3 technically only supports ISO-8859-1 and UTF-16. * If AIMP struggles with UTF-16 in ID3v2.3, changing Kid3's write encoding setting or saving as **ID3v2.4 with UTF-8** will often bypass AIMP's UTF-16 BOM parser bug. --- ### Conclusion Kid3 is adhering to ID3 specifications. The issue stems from **AIMP's ID3 parser misreading the UTF-16 BOM/encoding header byte** as part of the string payload.
Created attachment 195560 [details] attachment-2707211-0.html > > Четверг, 27 августа 2026, 19:03 +03:00 от Urs Fleisch <bugzilla_noreply@kde.org > >: > https://bugs.kde.org/show_bug.cgi?id=524798 > > --- Comment #2 from Urs Fleisch <ufleisch@users.sourceforge.net> --- > Are you sure that Kid3 is the problem and not AIMP? > > Here's how Gemini views the matter: > > It is very likely that AIMP is misinterpreting the ID3v2 metadata rather > than > Kid3 corrupting it. > Here is an analysis of why this occurs and why AIMP is the probable > culprit: > > --- > > ### 1. What the "B" Character Control Artifact Usually Means > > In ID3v2 tags (both v2.3 and v2.4), text fields begin with an **Encoding > Byte** > (a single byte prefix before the actual string data) that tells parsers > how to > decode the character string: > > * `0x00`: ISO-8859-1 (Latin-1) > * `0x01`: UTF-16 with BOM (Byte Order Mark) > * `0x02`: UTF-16BE without BOM > * `0x03`: UTF-8 (valid in ID3v2.4) > > When text is written in **UTF-16 with BOM**, the string starts with two > bytes: > `0xFE 0xFF` (Big-Endian) or `0xFF 0xFE` (Little-Endian). > > If a player fails to recognize UTF-16 encoding correctly—or mishandles the > > encoding descriptor byte/BOM when reading ID3v2.3 tags—it will treat the > BOM > bytes as raw ASCII/Latin-1 text. > > * In ASCII/Latin-1 or certain Windows codepages (like Windows-1251), byte > values around `0xFE`/`0xFF` or raw UTF-16 representation can render as > weird > glyphs or **control/garbage characters** (often looking like `B`, `þÿ`, or > > `ÿþ`). > > ### 2. ID3v2 Spec Compliance: Kid3 vs. AIMP > > * **Kid3** uses well-established tag libraries (`TagLib` or its internal > ID3 > parser) that strictly comply with the ID3v2 specification. Kid3 correctly > writes the encoding byte prefix and UTF-16 BOM when saving tags in ID3v2.3 > mode > (which requires UTF-16 for Unicode). > * **AIMP** historically relies on its own custom ID3 parser. Older > versions or > specific configurations of AIMP are known to have bugs where they > incorrectly > strip or misinterpret the leading encoding byte/BOM on certain frames > (like > `TIT2`, `TPE1`, or custom `TXXX` frames), treating the metadata as plain > Latin-1 instead of UTF-16. > > ### 3. How to Verify > > To confirm whether Kid3 wrote standard tags or if AIMP is at fault: > > 1. **Check with `ffprobe` / `id3v2` / `TagLib` CLI tools:** > Inspect the raw tag structure of a processed file using a third > command-line > tool: > ```bash > ffprobe -show_format -print_format json "your_file.mp3" > > ``` > > > If command-line tools, VLC, or MPV display the text cleanly without any > "B" > character, Kid3 wrote standard-compliant ID3v2 tags. > 2. **Test ID3v2.3 Text Encoding Settings in Kid3:** > In Kid3, go to **Settings → Configure Kid3 → Tags → ID3v2** and check the > default text encoding: > * ID3v2.3 technically only supports ISO-8859-1 and UTF-16. > * If AIMP struggles with UTF-16 in ID3v2.3, changing Kid3's write encoding > > setting or saving as **ID3v2.4 with UTF-8** will often bypass AIMP's > UTF-16 BOM > parser bug. > > --- > > ### Conclusion > > Kid3 is adhering to ID3 specifications. The issue stems from **AIMP's ID3 > parser misreading the UTF-16 BOM/encoding header byte** as part of the > string > payload. > > -- > You are receiving this mail because: > You reported the bug. > ffprobe -show_format -print_format json '/home/kartaven ko/Загрузки/113 - Sure Thing.mp3' ffprobe version 7.1.5 Copyright (c) 2007-2026 the FFmpeg developers built with gcc 14.3.0 (GCC) 20250523 (ROSA) configuration: --prefix=/usr --enable-shared --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdi r=/usr/include --disable-stripping --enable-chromaprint --enable-libaom --enable-postproc --enab le-gpl --enable-pthreads --enable-ladspa --enable-libbluray --enable-libtheora --enable-libvorbi s --disable-encoder=vorbis --enable-libvpx --enable-libxcb --enable-libxcb-shm --enable-libxcb-x fixes --enable-libxcb-shape --enable-runtime-cpudetect --enable-libfdk-aac --enable-libdc1394 -- enable-librtmp --enable-libspeex --enable-libfreetype --enable-libgsm --enable-libcelt --enable- version3 --enable-nonfree --enable-opencl --enable-nvdec --enable-nvenc --disable-libopencv --en able-libopenjpeg --enable-libopus --enable-libsoxr --disable-libxavs --enable-libmodplug --enabl e-libmp3lame --enable-libass --enable-gnutls --enable-libcdio --enable-libpulse --enable-libv4l2 --enable-libvpl --enable-frei0r --enable-libopencore-amrnb --enable-libopencore-amrwb --enable- version3 --enable-libx264 --enable-libx265 --enable-libvo-amrwbenc --enable-libxvid --enable-ope ngl --enable-vulkan --disable-libglslang --enable-libshaderc --enable-libsmbclient libavutil 59. 39.100 / 59. 39.100 libavcodec 61. 19.101 / 61. 19.101 libavformat 61. 7.103 / 61. 7.103 libavdevice 61. 3.100 / 61. 3.100 libavfilter 10. 5.100 / 10. 5.100 libswscale 8. 3.100 / 8. 3.100 libswresample 5. 3.100 / 5. 3.100 libpostproc 58. 3.100 / 58. 3.100 { Unknown encoding Last message repeated 5 times Input #0, mp3, from '/home/kartavenko/Загрузки/113 - Sure Thing.mp3': Duration: 00:02:39.71, start: 0.025057, bitrate: 320 kb/s Stream #0:0: Audio: mp3 (mp3float), 44100 Hz, stereo, fltp, 320 kb/s "format": { "filename": "/home/kartavenko/Загрузки/113 - Sure Thing.mp3", "nb_streams": 1, "nb_programs": 0, "nb_stream_groups": 0, "format_name": "mp3", "format_long_name": "MP2/3 (MPEG audio layer 2/3)", "start_time": "0.025057", "duration": "159.712653", "size": "6390636", "bit_rate": "320106", "probe_score": 51 VLC doesn’t launch with such a file from the command line, but the tags are displayed correctly in graphical mode. Also, the tags aren’t displayed in easytag and mp3tag. I’ll add that the problem occurs when overwriting existing tags in kid3. If you first delete the tags and then re‑enter them, the error doesn’t occur, and the tags are displayed correctly in all programs. I noticed the error recently, as I’ve been using kid3 for a long time and haven’t had any problems. -- Hallow! Here 's what it gives out Илья Картавенко Отправлено из Почты Mail ( https://trk.mail.ru/c/zzm979 )
> > Четверг, 27 августа 2026, 15:13 +03:00 от Urs Fleisch <bugzilla_noreply@kde.org > >: > https://bugs.kde.org/show_bug.cgi?id=524798 > > Urs Fleisch <ufleisch@users.sourceforge.net> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > > Status|REPORTED |NEEDSINFO > Resolution|--- |WAITINGFORINFO > > --- Comment #1 from Urs Fleisch <ufleisch@users.sourceforge.net> --- > Please provide more information. I need a way to reproduce the issue. > Provide > me an example file (or the beginning of a file, because ID3v2 tags are > usually > at the beginning of a file) and instructions how to create a corrupted > file. > You can additionally also attach a corrupted file. With the currently > provided > information, I cannot reproduce the issue. > > -- > You are receiving this mail because: > You reported the bug. > -- Илья Картавенко Отправлено из Почты Mail ( https://trk.mail.ru/c/zzm979 )
Created attachment 195564 [details] =?UTF-8?B?a2lkM3Jj?= > > Четверг, 27 августа 2026, 19:03 +03:00 от Urs Fleisch <bugzilla_noreply@kde.org > >: > https://bugs.kde.org/show_bug.cgi?id=524798 > > --- Comment #2 from Urs Fleisch <ufleisch@users.sourceforge.net> --- > Are you sure that Kid3 is the problem and not AIMP? > > Here's how Gemini views the matter: > > It is very likely that AIMP is misinterpreting the ID3v2 metadata rather > than > Kid3 corrupting it. > Here is an analysis of why this occurs and why AIMP is the probable > culprit: > > --- > > ### 1. What the "B" Character Control Artifact Usually Means > > In ID3v2 tags (both v2.3 and v2.4), text fields begin with an **Encoding > Byte** > (a single byte prefix before the actual string data) that tells parsers > how to > decode the character string: > > * `0x00`: ISO-8859-1 (Latin-1) > * `0x01`: UTF-16 with BOM (Byte Order Mark) > * `0x02`: UTF-16BE without BOM > * `0x03`: UTF-8 (valid in ID3v2.4) > > When text is written in **UTF-16 with BOM**, the string starts with two > bytes: > `0xFE 0xFF` (Big-Endian) or `0xFF 0xFE` (Little-Endian). > > If a player fails to recognize UTF-16 encoding correctly—or mishandles the > > encoding descriptor byte/BOM when reading ID3v2.3 tags—it will treat the > BOM > bytes as raw ASCII/Latin-1 text. > > * In ASCII/Latin-1 or certain Windows codepages (like Windows-1251), byte > values around `0xFE`/`0xFF` or raw UTF-16 representation can render as > weird > glyphs or **control/garbage characters** (often looking like `B`, `þÿ`, or > > `ÿþ`). > > ### 2. ID3v2 Spec Compliance: Kid3 vs. AIMP > > * **Kid3** uses well-established tag libraries (`TagLib` or its internal > ID3 > parser) that strictly comply with the ID3v2 specification. Kid3 correctly > writes the encoding byte prefix and UTF-16 BOM when saving tags in ID3v2.3 > mode > (which requires UTF-16 for Unicode). > * **AIMP** historically relies on its own custom ID3 parser. Older > versions or > specific configurations of AIMP are known to have bugs where they > incorrectly > strip or misinterpret the leading encoding byte/BOM on certain frames > (like > `TIT2`, `TPE1`, or custom `TXXX` frames), treating the metadata as plain > Latin-1 instead of UTF-16. > > ### 3. How to Verify > > To confirm whether Kid3 wrote standard tags or if AIMP is at fault: > > 1. **Check with `ffprobe` / `id3v2` / `TagLib` CLI tools:** > Inspect the raw tag structure of a processed file using a third > command-line > tool: > ```bash > ffprobe -show_format -print_format json "your_file.mp3" > > ``` > > > If command-line tools, VLC, or MPV display the text cleanly without any > "B" > character, Kid3 wrote standard-compliant ID3v2 tags. > 2. **Test ID3v2.3 Text Encoding Settings in Kid3:** > In Kid3, go to **Settings → Configure Kid3 → Tags → ID3v2** and check the > default text encoding: > * ID3v2.3 technically only supports ISO-8859-1 and UTF-16. > * If AIMP struggles with UTF-16 in ID3v2.3, changing Kid3's write encoding > > setting or saving as **ID3v2.4 with UTF-8** will often bypass AIMP's > UTF-16 BOM > parser bug. > > --- > > ### Conclusion > > Kid3 is adhering to ID3 specifications. The issue stems from **AIMP's ID3 > parser misreading the UTF-16 BOM/encoding header byte** as part of the > string > payload. > > -- > You are receiving this mail because: > You reported the bug. > https://disk.yandex.ru/d/_P6Z2ouHJje_WQ Here is an example of such a file. I’m using the same settings as in the kid3rc file. I’ll attach it to the email. To reproduce the problem: Apply tags. Menu item: service — number tracks. Apply tag format. Then, on the right side, apply the format from tag 2 to the file name and click save. Check the result in AIMP and other programs. -- Илья Картавенко Отправлено из Почты Mail ( https://trk.mail.ru/c/zzm979 )
Thanks for the additional information. As I do not have ROSA Linux and have never seen this behavior on my system, could you please check the following points: - I have seen from your kid3rc file that you do not have any metadata plugins disabled, so I assume that you are using id3lib for ID3 tags (Id3libMetadata is activated in the plugins tab of the settings and is before TaglibMetadata). If this is true could you please deactivate Id3libMetadata and restart Kid3, so that TaglibMetadata will be used for ID3 tags. Could you check if the bug also occurs with TagLib? - Could you check if the problem is reproducible with the binary Kid3 package from https://prdownloads.sourceforge.net/kid3/kid3-3.10.1-Linux.tgz and using the latest development snapshot https://sourceforge.net/projects/kid3/files/kid3/development/kid3-git20260822-Linux.tgz (which no longer contains Id3libMetadata).
When using the version of the program from the repository of my operating system with the Id3libMetadata plugin disabled, the extra character is still displayed in aimp. However, the tags began to be displayed in easytag, which indicates that they are now being written correctly. When using the program versions you provided, no error occurs. The tags in aimp are displayed correctly. The same mp3 file was used for the tests.
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".
The error occurs regardless of the encoding and the tag version. It also manifests in tags of version 2.3. I didn’t quite understand which kid3 version you recommend for fixing the tags? What steps do I need to take for this? Can I rewrite the existing tags, or do I need to first delete the existing ones and write new ones?
Use the latest development snapshot https://sourceforge.net/projects/kid3/files/kid3/development/kid3-git20260822-Linux.tgz (this is the only version which is using the version TagLib which overwrites invalid encoding bytes with a 0 for Latin-1), but only if the tags are probably Latin-1 and you see the correct values in Kid3. This is possible for frame values in English. But if they are Unicode (e.g. cyrillic text), you should not do that, it would write a wrong Latin-1 encoding and make things worse. In such a case, I would expect that you see the correct text in Tag 2, you could copy it to Tag 1, remove Tag 2 and then copy the values back from Tag 1. This should create a new encoding value. As before, only do this if you see correct text. For this case of Unicode values, do not use the latest Kid3 snapshot, it would assume Latin-1 and therefore display wrong values, use the current version 3.10.1 with the Id3libMetadata plugin disabled.
Thanks, I'll try to do it.
Yes, indeed, in this version of kid3 it is possible to overwrite the tags with the error fixed. In AIMP, the tags are displayed correctly, but for some reason, for example, easytag does not see them, and accordingly, the tags may not be displayed in other programs. How can this problem be solved?
Oh, I got it, a simple re‑save is enough; the tags are displayed as they should.