So, in both the metapane and search operations set to look at music tag fields - a forward slash (/) char is shown in Opus as a sem-colon...
Is this a taglib issue, where perhaps either it or Opus itself is rigidly following some "spec"... I'm assuming this is not a random substitution and that perhaps slash chars aren't "allowed" in artist name field. Slash chars in other fields (album name, track titles, etc) are displayed fine...
It is part of the ID3v2.3 specification. A forward slash (/) in certain fields is used to separate multiple items.
For example, "AC/DC" in the artist field of an ID3v2.3 tag means the track is by multiple artists, AC and DC.
Yes, the ID3v2.3 spec designers did not really think this through when choosing which character to use as a separator.
You have to use another character instead, like backslash () or minus (-). (Or an audio format which doesn't use ID3, but that would be quite drastic. 
)
The string is still stored with the / you typed, FWIW, so if you have software which ignores this rule then the / will still show up. Mp3Tag will display the / as is. Opus and dbPowerAmp will both convert into a "; " when displaying the field as a single line. Other tools will turn it into a list of items (I read that Windows Media Player will do that, although haven't verified it).
forum.dbpoweramp.com/showthread. ... tist-field
mediamonkey.com/forum/viewto ... b5#p141054
Some tools intentionally and pragmatically break the spec (because the spec is somewhat ridiculous):
Of course, this all means that what looks right in one program may look wrong or different in another.
I am glad I don't use MP3.
Yeah right, I figured it was a spec adherence thing... and while I'd love for it to change, it's really not a big deal. I'd already verified the actual tag field contents did in fact contain the "/" char I wanted (and yes, I used mp3tag for heavy lifting tag operations). As I continue to push the ball up the field in finally completing ripping my collection (finally on the letter T - YAY), I'll just ignore those few artists that pop up with slashes in the artist name.
For posterity: where this came up was that I've taken to doing a FIND against the current batch of ripped/encoded CD's - looking for oddball chars in tags that I may have missed "fixing up" in my tagging acrobatics. Meaning, I have a few patterns of chars in my audio filename conventions that I prefer to be changed in the tags. Some of them were coming up false positive because of this substitution... Back when I used to use The Godfather, I could set rules on how certain strings were substituted when generating tags derived from the filename. Sadly, mp3tag doesn't have the exact same capability - unless there's some action/macro tricks I could use to do it (right now, it's all manual UI work). Guess it's time to look more at mp3tag forums to see if there's some way the tool can just do it for me automatically.
Thanks...
FWIW: I noticed that when Opus display (for instance) "Arch / Matheos"... it doesn't JUST substitute the "/" char for semi-colon. It's also truncating the space BEFORE the slash... so instead of "Arch ; Matheos", I see "Arch; Matheos" == np space between "Arch" and the semi-colon. Dunno if that's really intended or not, maybe it's just an all bets are off thing in the face of an invalid char according to the spec?
I think that makes sense, otherwise you'd have artists named "Arch " and " Matheos" (instead of "Arch" and "Matheos" ) if you used the spaces before/after the separator, and lots of people will put a space after a separator.
(There's probably some band out there with a space at the start or end of their name, just to mess with tagging software and OCD people. )
Hmmm... I see your point, but that would really only make sense to me if you did something other than continue to just display re-interpreted info in a single string/field... For instance, in the metapane - if an Artist string containing a "/" was parsed and then displayed in multiple separate "Artist" fields in the UI, then sure... I'd expect you to trim leading/trailing spaces and what not. And I think that would be a treatment more in keeping with the intent behind the spec in how a "/" is intended to delimit multiple values, and anyone (like me) wondering at how the info is being displayed would probably intuitively "get it". That obviously isn't a feasible visualization technique in other parts of Opus though (i.e. single line/column per file in the file display in details mode).
Either way, as is - I don't think there's any real advantage or intuitive benefit in re-interpreting such info to still only just display it in a single field/string. But I'm not real passionate about this being changed - as you say any number of apps is going to treat this sort of thing differently - I just don't see why the string should be massaged for no real advantage.
That said... one thing I do think is just ~wrong, is for the find function to return a hit when searching music tags for ";" characters... As you say, the actual data in the field is indeed a "/"... not a ";". However the string is "displayed" in a UI, I don't think it's right for a search operation looking for specific data in a field to "pretend" thats the data actually in the field...
Sorry for the lengthy dissertation... I know there are better things to spend time reading, etc. I've had my say...
Then the user wouldn't be able to search for the same thing that they see, which I think would be more confusing rather than less.
Ah yeah, right... that thing they see thats not really there. Gotcha... 