Bug on non-ASCII Custom (Comment descriptors)

[Macarena]

using MM3.0.2.1129g

If Custom contains non-ASCII character(s) the field is saved incorrectly into the file.

These Custom fields are saved as Comments with Comment Descriptors containing something like "Songs-DB_Custom4". According these descriptors, MM knows which field to assign when rereading the ID3 tags. Now, when the Custom (I played around with Custom4 and Custom3) contains a non-ASCII character, this descriptor is messed up and probably placed elsewhere. If the track is reloaded into a new library (or as a new song) by MM, the descriptor is not read correctly and the contain of the Comment field is displayed in the Comment field (note: wrong -- should be displayed in Custom[12345], because it was saved as Custom[12345]).

I checked on the contain of the Comment Descriptor field in ID3TagIt program, too. It contains Songs-DB_Custom or non-displayable characters -- I just copied one such a descriptor here: "匀漀渀最猀ⴀ䐀䈀开䌀甀猀琀漀洀㐀".

I've found this when writing paths into comment fields, e.g. "Q:\music\DJ\DJ - Žít jako kaskadér.mp3".

[jiri]

Thanks for the report, you are right, there is a bug. It will be fixed in the next release.

Jiri

[Macarena]

Thanks for the report, you are right, there is a bug. It will be fixed in the next release.

Jiri

Thanks for fixing. It was a long time ago, but anyway, I think it's nice to do it -- saying 'thank you' ) The bug was fixed, but the old descriptors remained and they would cause/caused a synchronizing problem when the media was reread and the MM library was recreated.

The solution for this was to clean the comment tags in ID3TagIt program and then synchronize tags in MM. Deleting ID tags in MM would cause a lost of AlbumArts, unrecoverable.