Option to disable composer tag reformatting

Feature description:

I’m using the composer tag extensively for song credits. Since rock music usually has distinct music and lyrics authors, I’ve adopted an individual format, which is composer1, …, composerN / lyricist1, …, lyricistM. So the music/lyrics separator is the slash. It appears that Symfonium reformats the composer tag, converting slashes to commas, probably in a normalization attempt. It would be good to have an option to disable this behavior, so the composer tag is left as is.

Problem solved:

Composer management will be easier, if the user employs a normalization that differs from Symfonium’s variant of normalization.

Brought benefits:

The content of the composer tag is not standardized, so every user might have chosen an individual way to format this information. The default normalization is reasonable, but detrimental if the user employs more than one separator for a good reason.

Other application solutions:

Most apps I’ve tested leave the composer info untouched, or just strip leading and trailing whitespace.

Additional description and context:

None.

Screenshots / Mockup:

This is how GMMP displays the composer tag. “Joe Payne, Robert John Godfrey / Joe Payne” means that Joe Payne is the primary songwriter (music and lyrics), while Robert John Godfrey contributed to the music. GMMP displays it just like I’ve entered it, while Symfonium will display “Joe Payne, Robert John Godfrey, Joe Payne”, which looks like Joe Payne is a duplicate name.

There’s tag for lyricist and other stuff.

The data is split by well known separator as documented in the FAQ. This is necessary for the many users who enter the data for composer as 1 field with a separator before multi value was more spread.

There’s currently no plan to change that, but there’s a missing distinct on the composer part, so there should not be duplicate.

So it would display “Joe Payne, Robert John Godfrey”.

Without doing that it would mean that you would not have a “Robert John Godfrey” entry in the composer list but a “Robert John Godfrey / Joe Payne” and tons of other combinations that would clutter the composer page.

And without any split at all it would mean that the composer would be : “composer1, …, composerN / lyricist1, …, lyricistM” that would make no sense either.

One could argue that there’s composers parsing for browsing and display composer, but what about multi value, I need to choose a way to generate it since there’s no tag for that.
I value consistency here in the whole app.

OK, I understand. Really, I’d use the lyricist tag, if I could, but again, there’s the problem of finding an appropriate app. The only tagger for Android that deserves this name is Audio Tagger Pro, and it offers a composer tag only. Same for MP3TAG on Windows. On the other hand, most serious players display the composer tag only, if any. So I’m forced to pack everything into the composer tag to stay compatible on all apps and devices.

Actually, I don’t mind if the composer index gets filled with all kinds of composer/lyricist combinations, and no player I’ve tested cares for it as well. Support of this extended metadata is just lousy, hence I need to consider the least common denominator here. So I would be more than happy if the composer tag would be, optionally, just left as is.

Well you don’t mind but others will. I’m sorry but this is a case of a very specific personal need.

You abuse something for your need and want the app that properly use that something to limit itself to support this.

I’m sorry but there’s no plans to add a setting that would on purpose break the composer part of the app.

Well, the fact is that you came up with a real fancy handling of the composer tag, which is a very cool idea, but I’m not aware of any tagger or other player that supports this paradigm. So it’s an exclusive feature for the long-time users of your app. Please understand, I’m not asking for breaking any well-known behavior, I just propose optionally switching off the fancy solution for users who are not accustomed to it and are not likely to adopt it.

This is not a fancy handling of the tag, this is splitting as the artists and it’s the common way.
Since the app support browsing by composers it requires the parsing. Your tags are the exact reason why it’s needed. Else it would not possible to browse by composers.

You want an app that display the raw tag without parsing and without composer browsing.
What you want is that I disable half the composer support that does not make sense from a support point of view.
If I display the composer tag and have a composer library section user would expect that the composers are visible in the composer section. If I use raw data as composers in that section it’s not usable.
That would trigger way too much support of users not understanding why such an option even exists.

As I said you can have multiple composers tag too. And there’s no displayComposer tag.
So what am I supposed to do with those if I do not reformat the tag? Show only the first? Add another complex option so that the user can choose the separator to join all of them? Something else?
At some point there’s the need for consistency and ease of use.

The current solution address 99% of all the needs in a consistent manner across all the app and multi value fields.
What you want is a display composer tag and this does not currently exist, if this tag is created one day then I’ll support it and it will fit your need inside the app.