Tagnavi_custom.config: searching by comment field

[SoulSkorpion]

Sorry to bump this, but:

I notice that in the latest build, the comment field (among others) is now showing up in the ID3 info as "<no info>" and is still not being picked up by tagnavi. This probably is due to the tags being written by iTunes as I have AAC files that exhibit the same behaviour. Should I file a flyspray entry for this? Is this a bug, or a feature request on the basis of "Rockbox doesn't support iTunes tags yet"?

[polygonal]

Sorry to bump this, but:

I notice that in the latest build, the comment field (among others) is now showing up in the ID3 info as "<no info>" and is still not being picked up by tagnavi. This probably is due to the tags being written by iTunes as I have AAC files that exhibit the same behaviour. Should I file a flyspray entry for this? Is this a bug, or a feature request on the basis of "Rockbox doesn't support iTunes tags yet"?

As far as I know, there is no "ituns tags" except a non-standard compliant "Compilation" tag. Rockbox should be ID3v2 compliant, and itunes is actually known to be not. So I don't think there is any bug here since itunes is the trouble maker by being not standard compliant. But it may very well be a codepage problem if you experience weird character problems only for ID3v1. Try changing codepage and see if that solves the problem. As for the empty comment field, are you sure that you actually tagged the file? ID3v1 has limited space for comments, and they might be truncated without you knowing it.

[SoulSkorpion]

Sorry to bump this, but:

I notice that in the latest build, the comment field (among others) is now showing up in the ID3 info as "" and is still not being picked up by tagnavi. This probably is due to the tags being written by iTunes as I have AAC files that exhibit the same behaviour. Should I file a flyspray entry for this? Is this a bug, or a feature request on the basis of "Rockbox doesn't support iTunes tags yet"?

As far as I know, there is no "ituns tags" except a non-standard compliant "Compilation" tag. Rockbox should be ID3v2 compliant, and itunes is actually known to be not. So I don't think there is any bug here since itunes is the trouble maker by being not standard compliant. But it may very well be a codepage problem if you experience weird character problems only for ID3v1. Try changing codepage and see if that solves the problem. As for the empty comment field, are you sure that you actually tagged the file? ID3v1 has limited space for comments, and they might be truncated without you knowing it.

I'm not getting weird characters in these fields any more, I'm now getting "<no info>" (sorry, that didn't show up in my above post because the forum didn't like it for some reason. I've edited my post using a workaround to force it to display correctly).

I'm not using the ID3v1 fields for these files, I'm trying to use the ID3v2 ones. And yes, they are tagged. I haven't actually been consistent about whether these files have ID3v1 tags as well or not; I didn't think it mattered because I've set Rockbox to prioritise ID3v2.

Look, I accept that iTunes is the nonstandard thing here. This is still a pain, since its tagging interface is very good. Also, Winamp has no problem with iTunes tags, can can search by the contents of the comment field. iTunes might be nonstandard, but it's evidently nonstandard in a consistent way if Winamp knows how to handle it. I also understand if it's deemed a bad idea to build nonstandard functionality into Rockbox itself. Could this maybe be implemented as a plugin instead?

Well, if anyone can suggest some kind of automatic tag-cleaner-upperer, I'd be happy to use it to un-iTunes my tags...

[roolku]

Sorry to bump this, but:

I notice that in the latest build, the comment field (among others) is now showing up in the ID3 info as "<no info>" and is still not being picked up by tagnavi. This probably is due to the tags being written by iTunes as I have AAC files that exhibit the same behaviour. Should I file a flyspray entry for this? Is this a bug, or a feature request on the basis of "Rockbox doesn't support iTunes tags yet"?

Could you upload a short example mp3 file somewhere and post the link? Please let me know what info you expect from the comment field.

[SoulSkorpion]

[edit]This forum keeps chewing up my angle brackets. It shows up fine in the preview, but not in my posts. Hang on while I edit my post with the workaround to force thme to be visible...[/edit]

File uploaded here.

This is how the file shows up on my Rockbox when I view the ID3 info:
[Title]
Egypt
[Artist]
Microprose
[Album]
Civilization
[Album Artist]
<no info>
[Work]
<no info>
[Discnum]
<no info>
[Tracknum]
3
[Comment]
<no info>
[Genre]
<no info>
[Year]
<no info>
[Length]
0:43
[Playlist]
3/3
[Bitrate]
128 kbps (VBR)
[Frequency]
44100 Hz
[Track Gain]
<no info>
[Album Gain]
<no info>
[Path]
/MUSIC/misc (games)/Civilization - Egypt - Microprose.mp3


This is how the comment field appears in Windows, when I right-click on it and go to "Properties":

Code: [Select]

 0000014B 0000014B 0000044D 00000452 000076E4 000076E4 00005961 00004FDE 00000F8F 00000F8F

This is how the comment field appears in iTunes, when I highlight it and go to "show info":
<game> <strategy game> <old school> <melodic>
(this is how I'm expecting it to look in Rockbox).

Winamp tells me that apparently this file has both ID3v1 and ID3v2 tags. I've uploaded a screenshot of all the details it displays, here.

I didn't realise this file had ID3v1 tags as well; I'll go back and remove them later. Either way, neither comment field is showing up in Rockbox's ID3 tag viewer, and this file is being returned by by tagnavi search that searches for files that do not have <game> in the comment field.

[polygonal]

Well, the comment frame in your file looks like this

C O M M 00 00 00 32 00 00 00 e n g 00 <game> ...

And as far as I know, the problem seems to come from the null byte (00) after the language indicator (eng). According to the ID3v2 standard, an optional description of the comment should follow the language, and should be terminated by $00 (00). So if a comment has no description (which is what rockbox reads), something like 00 00 FF FE (terminating string for unicode, which is the encoding specified by the frame?) should be used instead of just a null byte. So maybe because of the terminator is not standard, rockbox thinks that there is actually a description for the comment and thus ignores the comment.

I need a good lesson on unicode and the id3v2 standard,  so correct me if I'm wrong, but that seems to be the problem with your file.

[roolku]

File uploaded here.

Your example file has a third comment tag which is empty and which I initially guessed Rockbox happens to use.

However this is not the case. It is the last tag, so it should be ignored and a test with r14559 shows that it is. The "game strategy etc" string is displayed as expected. So I don't understand why it doesn't work for you.

polygonal: where did you get the idea from that the tag uses unicode? It does not in his example files.

[polygonal]

polygonal: where did you get the idea from that the tag uses unicode? It does not in his example files.

I don't know why but I'm under the impression that the last byte in the frame header (i.e. the byte before the language code is used for specifying encoding, and that 00 stands for unicode...

[SoulSkorpion]

File uploaded here.

Your example file has a third comment tag which is empty and which I initially guessed Rockbox happens to use.

However this is not the case. It is the last tag, so it should be ignored and a test with r14559 shows that it is. The "game strategy etc" string is displayed as expected. So I don't understand why it doesn't work for you.

Hm... the last file I uploaded also didn't show that problem for you.

Is there any chance that it's a hardware specific thing?

[edit]Something I find interesting about this is that when I posted this in the first place, these fields were showing up with corrupt entries. The new versions definitely changed something, because they now show up as "<no info>" instead.[/edit]

[polygonal]

I think I found the anwser to your former problem: the terminating sequence 00 00 FE FF is causing the display of the weird ÿ character (I retagged your file with foobar, which placed the terminating sequence, and now that character shows up). But then I have no clue with why your comment isn't showing, since it shows up quite correctly on my ipod. Don't think there is any hardware problem involved in the tag-parsing process though.

[SoulSkorpion]

There's no chance that any model-specific code is having side effects?

The difference in model is the only thing I can think of that would be different between my situation and everyone else's...

Have you guys got Windows? If so, does the file I uploaded also show garbage in the comments if you view the properties of the file?... although I can't think of how the file could possibly have got altered in transit.

[GodEater]

There is no model specific code in the database portion of Rockbox.

[SoulSkorpion]

Well, I guess the only thing I can do now iis to try to clean up the tags with another program, since nobody else can reproduce the bug :/. Does anyone know of good tag-editing software that might be up to the task?

[bascule]

MP3Tag does it for me...

[polygonal]

MP3Tag does it for me...

Agreed enthusiastically.