Comment Field supports only 255 characters

I recentely started using Tag&Rename, which has the neat feature to pull track information from AMG. As standard it automatically copies the album review into the ID3 Comment field. I like the idea of beeing able to read an albums review on my player in the details view. Emplode however cuts the review down to 255 characters when importing the mp3. Could we have more charcters, please?

Emplode however cuts the review down to 255 characters when importing the mp3. Could we have more charcters, please?

Not a good idea. Reasons:

1) They take up space in the database, and consequently, space in the player's RAM when the database is loaded. Much rather have that space used for caching and other useful things.

2) Long comments aren't easily readable on the player's screen anyway.

3) The Allmusic.com reviews usually get it all wrong, anyway.

Why would the comment field be loaded into the database? The only time the player uses it is when detailed info is brought up via holding of the info button.

The player software NEVER uses the induhvidual tag files from the fids directories, except to rebuild a missing/outdated database from. Instead, it uses the single "database" file, which is much more run-time efficient (no disk spinup required after it's read in) for the way the player works. Therefore, EVERYTHING has to be stored in the database file, track details and all. That's just the way it works.

-ml

Nope.

For effectively the reasons cited by the others. Plus this one: The database file format doesn't support string fields longer than 255 characters.

Hi Roger.

The database file format doesn't support string fields longer than 255 characters.

Pascal-type strings?

cu,
sven

Hmm, is the space for the comment field string reserved in the database? I'm asking because I wonder if it makes a difference (RAM wise) if 0 or all 255 characters of the comment fields are used.
If I max out all of the comment fields in every single mp3 on my 60 gig player, would that significantely reduce the players ability to cache?

No, it's not reserved - it's packed (hence the pascal-style strings). Database space gets taken out of cache space, so the bigger the database, the less cache.

ls -l /drive0/var

...will give you an idea of the size of database loaded into RAM at boot time.

Hugo

Hmm, so if the database size is crucial to the player's ability to cache why don't we kill the comment field from the database altogether. The only time when the comments field is beeing used is when the details screen is beeing viewed, so i see no reason for it to be in the ram the whole time.
I understand that the player needs quick access to various song infos for its visuals and info screens, thus the database-in-ram concept, but the comments field ain't one of them. So .... couldn't we just make the details view read the actual ID3 tags from the harddisk? Maybe even all of the ID3v2 tags? The comment field is of particular interest to me, but maybe others have interest in seeing composer, org. artist etc fields in the details view?