Rockbox

Tasklist

FS#7698 - ID3 "Comment" field not correctly displayed (and read?)

Attached to Project: Rockbox
Opened by Alexander Levin (fml2) - Sunday, 02 September 2007, 20:37 GMT
Last edited by Magnus Holmgren (learman) - Monday, 03 September 2007, 16:15 GMT
Task Type Bugs
Category ID3 / meta data
Status Closed
Assigned To Magnus Holmgren (learman)
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The comment field in the attached file should be "ÄÖÜäöüß" (German umlauts; the problem also occurs when e.g. cyrillic letters are used). But in "Show ID3 Info" screen it is shown as in the attached image. The font used is nimbus-14, it contains the appropriate glyphs (so it's because of the bad font).

I don't know whether this is a problem with ID3 reading or just displaying.

Observed in r14585.
   bad_comment.mp3 (64.1 KiB)
   bad_comment.bmp (10.1 KiB)
This task depends upon

Closed by  Magnus Holmgren (learman)
Monday, 03 September 2007, 16:15 GMT
Reason for closing:  Fixed
Additional comments about closing:  UTF-16 comments weren't read correctly.
Comment by Jonas Häggqvist (rasher) - Sunday, 02 September 2007, 21:11 GMT
The comment field, rather surprisingly I think, has a BOM. I suppose Rockbox could strip those from comment fields. I don't know if your tag is technically broken or not. It's also UTF-16.

ff fe c4 00 d6 00 dc 00 e4 00 f6 00 fc 00 df 00
Comment by Alexander Levin (fml2) - Monday, 03 September 2007, 07:05 GMT
In the original report, it should read "so it's _not_ because of the bad font" of course.
Comment by Alexander Levin (fml2) - Monday, 03 September 2007, 07:34 GMT
I don't know anything about the ID3 standards but the tag is correctly displayed in Windows Explorer (file properties), Media Monkey, and Mp3Tag.
Comment by Alexander Levin (fml2) - Monday, 03 September 2007, 10:44 GMT
Another thought: the presence of the BOM is a sign that the field is UTF-16 encoded (not UTF-8) since UTF-8 doesn't need any byte order. So the correct handling of this should be done in RB. Maybe also for other fields (I don't know if the code is the same for all fields).

Loading...