MediaMonkey forum

Gonna be a pain in the ass...

à;GRUMH...

gets split up in the artist nodes with

à and GRUMH...

edit: consolodating for reference

à;GRUMH...
C/A/T
F/A/V
De/Vision
Fr/action
Fixmer/McCarthy
Vibert/Simmonds
M/A/R/R/S
Love/Hate
F/O/A/D
+/-

C:\del *.mp3

Akron/Family
Model/Actress
Search/Rescue

Wow, never heard of them....just googled them

This forum is sick. In a very good way!

Kos

Still problematic names

à;GRUMH...
C/A/T
F/A/V
De/Vision
Fr/action
Fixmer/McCarthy
Vibert/Simmonds


Some might argue that fixmer/mccarthy and vibert/simmonds are simply separate artists, but as far as I am concerned they are a single entity collaboration named as above.

Changing the split multiple-value option (to | symbol) has no apparent effect in ensuring these artists remain a single entity, they are simply displayed as multiple artists with the above pipe symbol instead of in the fashion as a single artist.

That's likely due to the fact that "/" is reserved as the multi-value splitter in the ID3 standard.

After some fiddling, it works for me. I tried with C/A/T, having ; as the separator and it worked right away.
Then I tried with à;GRUMH... which I already had in library. I changed the separator to |, restarted MM and now they were displayed as à|GRUMH...
Tried to change one track to à;GRUMH... but it got split anyway. Then I renamed all à;GRUMH... and à|GRUMH... to XXX after that it worked to rename them to à;GRUMH... So the key seems to rename all occurrences of the artist you want fix?
I did the test on my fresh new test database which only contains 500 tracks.

Mizery_Made wrote:That's likely due to the fact that "/" is reserved as the multi-value splitter in the ID3 standard.

...which is why I'm still hoping that MediaMonkey will implement support for writing id3v2.4 (at least for files already tagged in this format), because unlike 2.3 it does not have this limitation.

Mizery_Made wrote:That's likely due to the fact that "/" is reserved as the multi-value splitter in the ID3 standard.

Really? I didn't even know there was a designated standard multi-value splitter for ID3 yet. I was warming to the idea of the semi-colon, because it is far more rare that you find artist or song names with a semi-colon in them than a slash (add V/VM and 33 1/3 Queen to the list of artist names already posted).

Remember now that even if a / is used within the ID3 tag to split multiple artists, MM's library can use another one. In 3.0 it was a ; in 3.1 this is configurable (must be the same for all tracks though). This means that when MM reads the tag from the file upon adding/rescanning tracks to the library it translates the / to the one used within the library and displays that. When MM writes tags it always uses / regardless of the splitter used within the library.

So it is really two different things. I.e. what is used within the actual tag and what is used within the library.

Bex wrote:Remember now that even if a / is used within the ID3 tag to split multiple artists, MM's library can use another one. In 3.0 it was a ; in 3.1 this is configurable (must be the same for all tracks though). This means that when MM reads the tag from the file upon adding/rescanning tracks to the library it translates the / to the one used within the library and displays that. When MM writes tags it always uses / regardless of the splitter used within the library.

So it is really two different things. I.e. what is used within the actual tag and what is used within the library.

Now I am totally lost. If I look at the raw database, I see both ";" and "/" in the fields.

Hmmmm. Maybe. Look at the files with raw tag dump tomorrow.

Just a couple of not very helpful asides (the second one almost completely off-topic!):

1. I think that if even if you have MM configured to use the pipe | as the separator (like I do - bcos it looks the best. I like the pipe!), if you use a semi-colon in a multi-item field MM will still treat it as a separator (and I guess it will be converted over to a pipe at some point but I'm not sure about that).

2. If you have a back-slash in a field that you are using in your auto-organise path, auto-organise thinks it's a directory level and it messes up the mask (with no warning of course). I'm not sure if this is expected behavior or not so I'm hiding it in here!

Yeah. Got it now.

I selected a track with multiple artist and composer and used Find More From Same->Folder(Explorer)
Selected the track in Explorer and opened it with Notepad++
Selected Plugins->Hex-Editor->View in Hex in Notepad++
Searched (Ctrl+F) for text, and there you are. "/" in the TPE1 tag, "; " in the track Property.

MM3 monkey wrote:2. If you have a back-slash in a field that you are using in your auto-organise path, auto-organise thinks it's a directory level and it messes up the mask (with no warning of course). I'm not sure if this is expected behavior or not so I'm hiding it in here!

yea, that problem with backslashes has been around since 2.x....

backslashes in any metadata should never cause a subfolder creation, only backslashes in the organize masks should.

this track always gets screwed up.

C:\del *.mp3

oh and here is another artist

M/A/R/R/S

and

Love/Hate

and

F/O/A/D

I have seen the same problem in rips. My normal fix is to change "\" to "/" in the cddb metadata.