Source: libid3tag
Version: 0.16.3-1
Severity: important
Tags: patch upstream
X-Debbugs-Cc: conn...@brian-arnold.dev
Dear Maintainer,
* What led up to the situation?
When mp3 files contain multiple "Artists", the secondary and beyond
artists lose the Byte-Order-Mark, and become random chinese characters.
This is due to a truly ANCIENT bug in libid3tag that affects all
applications that use it. (Only seems to apply to tags that use utf-16?)
* What exactly did you do (or not do) that was effective (or
ineffective)?
Read multiple artists from an mp3 with multiple artists, stored in
UTF-16
* What was the outcome of this action?
Standard Latin characters were converted into random chinese characters.
* What outcome did you expect instead?
Regular Latin text should not be converted into random chinese
characters when reading tags with libid3tag
I have already opened a pull request on the upstream repository to
address the issue, just waiting for my pull request to be merged.
See upstream package pull request #19:
https://codeberg.org/tenacityteam/libid3tag/pulls/19
(Could we get this into Trixie before release? It makes libid3tag
completely unusable if using UTF-16. I keep all my music stored in
UTF-16, so I don't have any ASCII, UTF-8, or UTF-24 files to test
against libid3tag)
-- System Information:
Debian Release: 13.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.12.30-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
