Re: Common music database?

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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]