... which scenario is more bloated; give XMPlay native tag editing, a feature that would be invisible to those who do not wish to use it, or force music fans to have two programs for managing and playing their music? Take your pick, it will be bloat either way, but one scenario is more convenient for the end user.
I prefer to keep tag writing out of the player, since playing music is a lot more frequent than editing tags. Additionally, approaching the functionality and format support of MP3Tag or Tag will take a lot of time and bug reports, while the gain of native tag writing is rather limited due to its little use. At least, that's what I think
.
What is the point of freeform tagging if the software that enables us to edit them forces standards when the actual format does not? It makes no sense to me. Thankfully Tag is a gem, but unfortunately a rare one. I try to avoid typos and improper tagging while encoding the file, but it isn't bulletproof.
MP3Tag reads artist, Artist and ARTIST, doesn't it? I think it's not forcing a standard, but rather using a uniform (non-configurable but fully functional) output. If you want more control, you should indeed use Tag, at the cost of usability (or time, if you create your own GUI/script for Tag) and at the risk of syntax mistakes.
I see "tempo control" is accepted as a wish for next release and I'm asking who the hell is one that wants to DJ with XMPlay when there are so much better alternatives. And then, there are requests for native effects? That should be only in a for of plug-in. Player is player, not a tagging tool, not a DJ tool, not a production tool.
It's a request list, not a to-do list. Ian will decide what he implements and whether that is native or via a plugin.
There was some talking here about addressing tracks from within xmplay to external applications either by a command line or by using the shell extension menu. These options would have been useful for sending tracks to a tagger of one's choice.
I'll put it on the list as well
.
