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 are watching all bug changes.
