0 Members and 1 Guest are viewing this topic.
В десктопной версии в начале всех тегов присутствует символ "B" (#42h), в плейлисте тоже.Однако, TagRename, к примеру, считывает теги правильно и, если перезаписать им файл, то и AIMP будет показывать теги правильно.
Я подрезаю тишину в начале и в конце файлов с помощью mp3split-gtk
Просто некоторым проигрывателям нужны теги весрии id3 v1.
Обнаружил, что лишние символы добавляются при перезаписи в kid3 существующих тегов. Если, сначала удалить существующие, потом заново вписать, или восстановить из имени файла. то лишние символы не появляются в aimp
--- 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 thanKid3 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 MeansIn 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 todecode 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 theencoding descriptor byte/BOM when reading ID3v2.3 tags—it will treat the BOMbytes as raw ASCII/Latin-1 text.* In ASCII/Latin-1 or certain Windows codepages (like Windows-1251), bytevalues around `0xFE`/`0xFF` or raw UTF-16 representation can render as weirdglyphs 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 ID3parser) that strictly comply with the ID3v2 specification. Kid3 correctlywrites 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 orspecific configurations of AIMP are known to have bugs where they incorrectlystrip or misinterpret the leading encoding byte/BOM on certain frames (like`TIT2`, `TPE1`, or custom `TXXX` frames), treating the metadata as plainLatin-1 instead of UTF-16.### 3. How to VerifyTo 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-linetool:```bashffprobe -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 thedefault 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 encodingsetting or saving as **ID3v2.4 with UTF-8** will often bypass AIMP's UTF-16 BOMparser bug.---### ConclusionKid3 is adhering to ID3 specifications. The issue stems from **AIMP's ID3parser misreading the UTF-16 BOM/encoding header byte** as part of the stringpayload.
The issue stems from **AIMP's ID3 parser misreading the UTF-16 BOM/encoding header byte** as part of the string payload.
