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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
