Re: Common music database?

["Milosz Derezynski" <internalerror gmail com>]

Yes i must agree that the amount of what could be "common" is really
rather limited. We must really watch out to not jump onto some kind of
overhyped unification trend, or something. 

What i see as a (or possibly just "the") major goal would be to
eliminate redundancy: You don't want to have player A store 3MB of
music metadata, and have player B store the _exact same_ 3MB of data
(among possibly other data related to the files it knows about), and
same for player C.

Each of those players offers unique features though which might be tied
to custom/specific additions to the "metadata", or to rephrase it: File
metadata is something different for each player. A simple example would
be that player A might consider only what e.g. (now in really practical
terms) Taglib gives him as metadata, and all the rest is additional
information in some sense or another, while player B reads the metadata
off Taglib, adds file mtime to it, additional stuff like the HAL volume
and device UDI that belongs to that file (we do that actually), and
calls *that* "metadata".

I think we must find the "lowest common denominator" of what we can
call metadata, then we could make use of Tracker to store that, and
each app could store the things it needs for it's own features or just
it's own mechanics in some kind of own database, or if Tracker allows
for separate "databases", separate this out from the shared data.

(What's also not a real option is to make every player "pollute" the
Tracker database globally with it's own information which might be
useless for most/all/any other player(s)).

What we need is a spec of what can be considered metadata for audio files, and what isn't. 

Also interesting could be a class model. What i mean is that you have
e.g. a base class "File", which has, for example, the mtime of that
file, and the HAL device and volume UDI it belongs to (or that belongs
to it). Then you have an extended class "File::Audio" (nevermind the
C++ notation), which has audio file metadata. (Jamie: does Tracker
support something like that?).

On 3/31/06, James Doc Livingston <doclivingston gmail com> wrote:

On Fri, 2006-03-31 at 15:01 +0200, Milosz Derezynski wrote:
> For example in BMP experimental (the `bmpx' repository in our SVN), we
> use, as i've already said, a relation type library and hence there's
> no much use for us for an SQL or SQL based, or otherwise query based
> external system apart from the _raw storage_.
>
> Tracker again isn't just raw storage, it's somewhat more, and i dare
> to say that any player that would want to make full use of Tracker as
> the (shared) metadata/database backend would have to either sacrifice
> a lot of own features it supports, or have really a lot of very
> whacked and very weird code (as bindings always tend to have a lot of
> blood and bonesplitter in them).

This begs the question "What do we want a common music database /for/?".

As I see it, the primary goal is to share the "per-user metadata" like
ratings, play counts, tags/categories et al. Which lets users change
music players and not loose all their information.


With that in mind, Tracker could provide the raw storage for the common
database. When an app starts up, it could say "give me all the tracks
and metadata" and watch for later changes. When the any of the data
changes in the app, it would push it out to Tracker.

If an app wants to use Tracker as it's entire database layer, great -
but I don't see any of the existing apps doing that in the near future.


I'm not sure where everyone else stands on how much stuff should be
common in the "common database", but that's my 2c.


Cheers,

James "Doc" Livingston
--
The only "intuitive" interface is the nipple. After that, it's all
learned. -- Bruce Ediger, in comp.os.linux.misc, on X interfaces

_______________________________________________
gnome-multimedia mailing list
gnome-multimedia gnome org
http://mail.gnome.org/mailman/listinfo/gnome-multimedia