[mythtv] MythMusic: MetaLibrarian RFC

[David]

Colin Guthrie wrote:

> 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.

I'd say 'cached' in an indexed on-disk format.

> 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.


Is it worth breaking the functional areas down?
* Enhanced Metadata storage/access
* standardised schema
* read/write(-thru) to native mp3/flac/ogg tags, lyrics, art
* permanent music track identity (MD5 of first n blocks of music data -
something similar already exists I think)
* other unique keys supported (eg filename) although these may change
over time

* Services
* search/filter
* sort (by x/y/z etc)
* stored/static lists (m3u/playlists) (stored using the permanent key,
possibly presented using filename key...)
* dynamic lists/views (heirarchies/random/mood/suggested)
* notification (change/new)
* stream/serve files? (probably not initially but if you want to do RPC
type things then why not provide the raw data aswell?)

* Management
* ui/api to create lists
* ui/api to create dynamic lists
* image grabbers for albums etc
* lyric grabbers ...
* FreeDB access?
* file management (ie rename/move mp3s)

What other solutions are there?
* Amarok
* madman
* xmms
* taglib

Taglib is particularly interesting as it aims to be a low-level API in
the same sense as MetaLibrarian.
It is well placed to provide a simple upgrade route if you can offer the
abstraction required by eg Amarok.
(I wondered about slicing Amarok's DB system off - it already supports
both mysql and sqlite so I expect some abstraction there.
It may also be a suitable candidate for working the metalibrarian
abstraction layer idea. Finally it may also provide a nice gui for
later... It is written in Qt so it may be a place to grab lots of good
code from even if there's no immediate Amarok/Myth marriage :) )

Although Isaac wasn't keen on depending on Taglib last october I don't
think the time has come to rule it out just yet - especially given the
stated aims of MetaLibrarian.

David