[F] Problem, need a little help.

bug-fixed

#1

I've been using MP3Tag alongside my player (MediaMonkey, refered to as "MM" from here out) for a while now and I've really fell in love with MP3Tag, so I've found myself doing most of my tagging tasks there, instead of in MM, I'm even able to write to the "Custom Fields" that MM uses by writing to "COMMENT SONGS-DB_CUSTOM#" with # corresponding to 1 of the 3 custom fields.

All was fine and dandy, until I upgraded to MP3Tag 2.38, I can write to this field, but MM no longer picks it up when importing the songs to the Database. I did some investigating and found that the old 2.37a version of MP3Tag would write this field in the file as "COMM engSongs-DB_Custom1", but 2.38 writes it in all caps, "COMM engSONGS-DB_CUSTOM1" and this is the only difference I found. At first, I thought that something as little as this, wouldn't affect anything, but I did an experiment on a hunch.

Took an MP3 that I knows working fine, made two copies of it. Tagged them both with MP3Tag 2.38, exact same tags, except a number on the end of the Title to differentiate them. Opened up Copy 2 in a text editor and found where MP3Tag had written the Custom 1 field, changed the all caps formating to the previous formating from version 2.37a and saved.

Then, loaded up MediaMonkey, scanned both files into the database and as my hunch wanted me to think, that was the key. Copy 1 showed up with the Custom 1 field blank, while Copy 2, the field was populated with the same information from the tag, just as it should have.

Any idea what's up? Was it changed to write the fields in all Caps like that for a reason? Any way to fix this? This may not be a bug with MP3Tag, maybe this has to do with MM not reading capped fields when it should, but it worked fine in MP3Tag version 2.37a and nothing with MM has changed since, so... Any help on this would be greatly appreciated.


#2

Well, this is not desired and it should get fixed.

Is it correct that this only happens when you create the new field in Mp3tag, but the case stays if the field already exists?

You can use an action to fix the case afterwards:
Action #1:
Action type: Guess values
Source format: *%COMMENT Songs-DB_Custom1%
Guessing pattern: %COMMENT Songs-DB_Custom1%

Action #2:
Action type: Guess values
Source format: %COMMENT Songs-DB_Custom1%
Guessing pattern: *%COMMENT Songs-DB_Custom1%

Or if you have the field in the tag panel you can edit usrfields.ini to influence the spelling.


#3

Your fix does appear to work. As for if it leaves the format the same if the field is already present before editing, it would appear that it does, though I only checked that a time or two, so it's not like I ran it through the ringer.


#4

Just to add some info here, if you added such a field to the columns and you enter the information there, you must also pay attention to the spelling there.

Example:
Name: Custom3
Value: %COMMENT SONGS-DB_CUSTOM3%
Field: %COMMENT Songs-DB_Custom3% <- here the spelling is important as it takes precedence over other settings!


#5

This problem has been fixed with the latest Development Build.

Thanks for reporting!