https://bugs.kde.org/show_bug.cgi?id=524798
--- Comment #5 from kart <[email protected]> --- > > Четверг, 27 августа 2026, 19:03 +03:00 от Urs Fleisch > <[email protected] > >: > https://bugs.kde.org/show_bug.cgi?id=524798 > > --- Comment #2 from Urs Fleisch <[email protected]> --- > 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 ) -- You are receiving this mail because: You are watching all bug changes.
