[mythtv] MythMusic: MetaLibrarian RFC

[Colin Guthrie]

Simon Kenyon wrote:
> ok, so i've re-read your proposal
> i'll play it back in my words and see if you agree (or ignore me, should you 
> see fit)

Hehe :)

> metalibrarian is a library
> it reads and write metadata
> this metadata can be attributes of "content" - name of artist, etc
> it can also be attributes of the use of this content - last played, playlist 
> membership, etc
> this metadata can be stored in the files where possible (ID3) or separate 
> (playlist)
> 
> the library can be an RPC into a server or it can be a wholly self-contained 
> API with no server
> 
> would it be fair to say that it is an ID3 tag library extended with methods to 
> read/write data outside the basic ID3 tags. the server aspect of it adds 
> flexibility but as the files have to available on the filesystem, the 
> extended metadata could be stored alongside the media it describes
> 
> if the library was based on or used an extension of an existing API then it 
> could be a drop in replacement for that used in mythmusic.
> 
> did i get it now?

More or less that is a good summary.

I'll assume that when you say "ID3" you mean a generic metatag (e.g. 
vorbis comment etc.) too.

I'd also add that the data would be stored (or in the case of ID3 
related information perhaps "mirrored" is a more accurate term) in such 
a way as to provide very efficient access and searching (e.g. in a 
database in much the same way as MythMusic/Amarok/Domo etc. do), so when 
you say "the extended metadata could be stored alongside the media it 
describes" this is technically true but would be inefficient in terms of 
querying etc.

Also, as the majority of music programs offer some form of hierarchical 
view to browsing a music collection, one of the main features I'd like 
to add into metalibrarian is the ability to setup a preferred stucture 
for this heirarchy (Myth offers some capability to configure this 
heirarchy just now and it works fairly well for the majority; Amarok 
also offers some degree of configuration). But everyone has their own 
tastes and one of the biggest complaints I hear is poor support for 
classical music tags. So I'd like to make a really flexible hierarchy 
config system that could use complex "if's" on the tags at each level e.g.
level1 = if tagnotempty(composer) "composer (artist)" else "artist"
level2 = "album"
etc.
(this syntax etc. it not even slightly thought out at this stage, but 
hopefully you catch my drift).

This script can be pre-cached in the database and supplied very quickly 
to any application that wants a hierarchical view of the music collection.

You could store several of these hierarchical configurations; call them 
"views" for the sake of argument. A really nice feature would be a Gnome 
VFS (virtual file system) plugin that allowed you to traverse these 
different view hierarchies as if they were normal files/folders (I think 
this is how VFS stuff works tho' I may have misinterpreted this!!).


I think when you say:

 > if the library was based on or used an extension of an existing API
 > then it could be a drop in replacement for that used in mythmusic.

is a not quite correct. I think functionality wise it could be a drop in 
replacement for the database that drives MythMusic (mainly due to me 
having a fair bit of experience of MM's setup), but I doubt it would 
have a similar API to the functions/classes in Myth as it stands currently.

WHen I was talking about existing APIs etc. I was really just wondering 
if DAAP (or similar) could for the basis for exchanging the data, but I 
think Thor cleared this up for me in that it probably wouldn't be the 
best base (tho' this would not rule out creating a DAAP daemon that used 
the MetaLibrarian to make the music/metadata available to all DAAP clients).


Col.

-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
|   myth at colin.guthr.ie  |
| http://colin.guthr.ie/ |
+------------------------+