Database truncates tag info?

[polygonal]

I have a ipod 5G and the most recent build of Rockbox. My music files are all mp3s tagged with id3v2.3 (I think) and they usually have pretty long names / album names, etc. since classical music usually need a lots of information...

I'm quite new - initialized the database after getting Rockbox on my ipod. It seems that the initialization process randomly truncates some piece of tag, for example, I'm presented with the following albums

Beethoven: Piano Concertos Nos.1-5 (
Beethoven: Piano Concertos Nos.1-5 (A
Beethoven: Piano Concertos Nos.1-5 (Ai
...
Beethoven: Piano Concertos Nos.1-5 (Aimard)

I checked my mp3 file using other tag reader, and their tag are correct. Is it the expected behavior? Is there any fix available?

Thanks

[Llorean]

There is a limited space available for tags (all total tags on one song). Once you reach the end of that space, anything after will be cut off, it sounds like your very long tags are causing this to happen. Are there any album art, comments, or other tags not supported by Rockbox that you can remove (or re-order so that they're after the 'useful' ones)?

[polygonal]

Now I see the problem - I do have VERY long tags including album art and substantial texts. But i can't think of any tagger program out there that let me rearrange the order of tag... and writing one myself will be involve more time than I'm willing to give.

Is there a published limit as to after what length the tag will be truncated? I might try to remove the album art from tag, but if it won't help, I don't want to try it to begin with.

Also, where is the official list of what tag is supported? According to the manual, comment is not supported, but the "show id3 info" in the context menu shows partial comment (sometimes only the "title" of the comment).

Thanks for the help

[Llorean]

I honestly don't know what the limit is, nor whether removing unsupported tags will help or if it's only the length of supported tags that matters. Sorry.

[Lear]

The limit is on the length of the actually read parts. So, album art and similar stuff makes no difference. The total size allocated for the text is 300 bytes (utf-8 encoded), and that is used for the following tags: artist, album, title, track number, date, composer, album artist, comment, genre and any replaygain values.

[polygonal]

That's sad news... I'll see what I can fix...

Do you know what tag is truncated first if the limit is exceeded? Does it depend on the order of tags in the file itself?

Thanks

[Lear]

Yes, it depends on the order in the file.

[linuxstb]

Yes, it depends on the order in the file.

Some of the metadata parsers (at least vorbis comments, APE and ASF (WMA)) also make use of the 384 bytes id3v1 buffer (in addition to the 300 byte id3v2 buffer) when parsing the metadata from the file.  So for those formats the limit is 684 bytes.  I don't know about the id3v2 code though.

I also don't know the database code, but if that has its own 300-byte limit, then its behaviour won't be to truncate tags in the order they are in the file, but rather the order the database processses them.  Although they will first be truncated to 684 bytes based on the order in the file...

But if there is a 300 byte limit in the database, maybe it should be extended to 684 bytes.

[Lear]

From a quick look at the tagcache code, the limit I can see is 520 bytes for some processing, perhaps for a single field. So the tagcache code shouldn't be the main problem here.

But that ID3V1 buffer size made me wonder a little: Why was that buffer size multiplied by 3 when unicode support was added, but not the ID3V2 buffer? It could've made sense to increase the latter a bit, though maybe not all the way to 900 bytes.

[dip]

I have exactly the same problem. For classical music with very long tag entries some of the tags in the database are truncated although they are correct in the original file. Unfortunately, removing or changing some of the tag entries is not an option for these cases.

Since this seems to be a problem due to a hard coded size of a buffer in rockbox, coud be anybody so kind to point me to the place in the source code where the corresponding limit must be amended that I can compile me a version of rockbox with increased buffer size.

[dip]

Maybe it's not a problem of the database since the tags are also truncated in the track info page (accessible by pressing and holding Select from the WPS screen to get the Context Menu and then selecting "Show Track Info").

So it seems to be a more general problem with reading long tags. Does anybody know where to look for this limit in the source code?

[Lear]

No, the tagcache isn't the main problem, as already mentioned (show track info and the tagcache use the same code to read the tags). It should be enough to increase the ID3V2_BUF_SIZE value in apps/metadata.h. 600 to 900 is reasonable, I think, at least for targets with more than 2 MB of RAM.

[dip]

Thanks a lot for pointing to the code. I will try that and report if it solves the problem.

Edit:
I changed the value to 900 and now no tag is truncated anymore! Great!

Maybe this value should be set in metadata.h to different sizes depending on the target? You mentioned that for targets with more than 2 MB of RAM a value of 600 to 900 should be reasonable. I have an ipod video with 64 MB so isn't it a shame that I (and several people before me) ran into this problem?