One of the good things about Firefly compared to WMC is that it has actually useful Composer browsing capabilities. But, like the whole Album Artist vs. Artist (compilation/soundtrack) issue, the Composer tags as filled in by WMP (or others) from the online databases makes it very difficult to actually browse, well, by Composer. These tags are cluttered with multiple artist names, typically their "real names" vs. their band or stage name.

Yes, it's nice to know that "Richard Hall" composed all track on Moby's "Play", but I don't ever plan on browsing composers looking for my Moby albums... I'm only concerned about Composer browsing for classical genres, where it has obvious usefulness. It is my preferred method for browsing these genres...

I started by disabling the "auto-update tags from the internet", but that still means I have to hand-edit all of the non-classical files to delete the composer tags. Not only does that take a lot of time and upkeep, but it does delete information, which may be useful?

So my suggestion is, could you restrict the inclusion of Composers into the database to only those music files that were in a specific list of genres? Yes, again, another config file thingy. But I think we could come up with a decent list of genres to use as a default?

Does anyone have a better suggestion that doesn't involve editing the tags?

Jeff

I agree that might be useful for some. Not an issue for me... I deal with the clutter and "search" is my friend. All my tracks contain the songwriter/composer for the music, as designed. (The issue I now have is that Firefly doesn't deal with multiple names yet.)

This is, of course, another "fix a limitation of the client UI by hacking the back-end" solution.

But I can see an optional "limit composer parsing to genre" function being added...

This seems like a great application for scripting hooks. If we had a hook that is called when a file is to be added to the DB that hook could modify the data to be added to the database and insert the modified data.

Example scripts could:
- remove composers on tracks that are not in the classical genre
- change "Frank Sinatra" to "Sinatra, Frank" based on a list of solo artist names the script has
- not add tracks under a certain length (prune out intro tracks)
All these would modify the database, but leave your original mp3 files alone.

I realise scripting is some way off, but it's worth talking about the features that could be implemented and the hooks required to implement them. Hopefully Ron has the motivation (and energy) to add scripting hooks throughout the Firefly code.

If you are familiar with C programming you could add the code in yourself (in the mp3 tag parsing code) and build a customized version of firefly for yourself. The code is really quite easy to hack (imho).

Mitch wrote:

This seems like a great application for scripting hooks. If we had a hook that is called when a file is to be added to the DB that hook could modify the data to be added to the database and insert the modified data.

Yup, every time I get a request from someone to hack up tags for some purpose, I think again of the need to do this.

I was thinking of a plugin for that.

If you are familiar with C programming you could add the code in yourself (in the mp3 tag parsing code) and build a customized version of firefly for yourself. The code is really quite easy to hack (imho).

Ya, but that's not approachable for most folks, plus it doesn't work for sharing. Someone can't easily distribute a solution for Composer versus AlbumArtist without distributing a whole binary package.

Would be nicer if it could be distributed as a simple text script.