| Summary: | MP3 tags in CP1251 don't display correctly | ||
|---|---|---|---|
| Product: | [Applications] amarok | Reporter: | Andy Igoshin <ai> |
| Component: | general | Assignee: | Amarok Bugs <amarok-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version First Reported In: | 1.2.1 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Andy Igoshin
2005-03-09 11:43:46 UTC
zillionth duplicate. Also I reckon your id3v1 tags are encoded wrongly or something. If not gimme a patch as I am fed up trying to fix this stuff. the same for amarok 1.2.3 mp3 files has a ID3v2 tag ID3v1 -- off Shoutcast metadata -- checked Instead decode using this charset: CP1251 -- the same problem fo amarok 1.2.3. Ok. I tested again. 1. mp3 file with ID3v1 (& ID3v2) tag ID3v1 -- on Shoutcast metadata -- on Instead decode using this charset: CP1251 Working Ok! 2. mp3 file with ID3v2 tag Instead decode using this charset: CP1251 Not displayed correctly. I think, the problem address to taglib. -- taglib do not have a 'setStringHandler' method for ID3v2 tags and interpret them codepage as latin1. Software must use UTF-8 or UTF-16 encoding to store anything but Latin-1 characters in ID3v2 tags, and not abuse the standard by putting CP1251 into fields marked 'Latin-1'. If certain players do not support ID3v2 completely, they should be fixed, not amaroK. tag recoding has been removed from amaroK too many associated problems with it. |