"Mappable" custom tags

Any ideas about how to improve MediaMonkey? Let us know!

Moderator: Gurus

EchoFoxtrot
Posts: 4
Joined: Wed Dec 26, 2007 2:10 pm
Location: Seattle, WA

"Mappable" custom tags

Post by EchoFoxtrot » Thu Feb 14, 2008 4:09 am

I just posted requesting language tags and a somewhat more general and elegant solution occurred to me:

How about an additional set of "custom" tags that actually map on to some other underlying tags (one per file format)? For example, CustomMap1 would map to "TLAN" for mp3 and "WM\Language" for WMA (I honestly have no idea what it is for .aac).

That would let each of us pull in the tags that are important instead of constantly having to ask for new tags to be supported.

The two non-trivial issues would seem to be:
1) Unifying fields that are similar but not identical across file formats (for example, I have no idea if TLAN and WM\Language are identical or just similar).
2) Switching the mapping of a custom field.

The easy answer for 1 is to define a bunch of pre-sanctioned combinations of fields with built-in code to unify behavior (in other words, MM would say something like "here's 20 extended fields I know about: pick up to 5 for your library"). The cool answer for 1 is a plug-in model for tag normalizers.

Now that I think about it, a plug-in model for tag normalizers might be pretty handy for other fields, too (although it's also "more than enough rope" to do some serious damage).

For number 2, I'd either disallow it or clear the column in the db. Ugly but effective. Reimporting the new field won't be fun either.

Cheers,
Erik

Lowlander
Posts: 46156
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Post by Lowlander » Thu Feb 14, 2008 10:57 am

I would say that native support for these tags would be a better solutions. I personally believe that MediaMonkey as the ultimate music manager should support more tags then it currently does.

If they want to keep things simple there could be an advanced tags switch in the options that would enable these extra fields in the track properties and in normal view they would be hidden for those who only require the basic tags.

I don't know if it's yet possible but another route would be to allow scripts access to all tags stored in the tags so that scripts can be written to support these tags values in the custom fields. I'd still prefer native support as that would mean it's compatible with other software/hardware.
Lowlander (MediaMonkey user since 2003)

EchoFoxtrot
Posts: 4
Joined: Wed Dec 26, 2007 2:10 pm
Location: Seattle, WA

Post by EchoFoxtrot » Fri Feb 15, 2008 11:55 pm

I agree in principle, but there are a _lot_ of tags out there in one form or another and the database would get polluted pretty fast if they added a column for each and every tag known to exist.

That's the motivation for suggesting a limited number of mappable fields -- it keeps the hit on the database manageable but lets each of us specifically select the tags that we need.

At the moment I absolutely need language and would like to have whatever tag it is that WMP calls "Keywords" in the UI.

Lowlander
Posts: 46156
Joined: Sat Sep 06, 2003 5:53 pm
Location: MediaMonkey 5

Post by Lowlander » Sat Feb 16, 2008 5:25 pm

I assume that SQLite is robust enough to handle a couple more fields. Of course including all fields might be a bit to much and many fields will only be used by few, but I think that database wise it shouldn't be a big problem.
Lowlander (MediaMonkey user since 2003)

Post Reply