From: Dave Hooper <dave_at_beermex.com>
Date: Wed, 13 Oct 2004 13:30:32 +0100

I don't like the idea of 'one artist per album'. It means you cannot take
advantage of the fact that compilation albums contains tracks by many
different artists (and that when you browse by ARTIST you want to see all of
the tracks by the artist - not just all of the complete albums by that
artist).

I'm also not too hot on the idea of using individual files - it runs the
risk of having an inconsistent db if say the allfiles db is updated but not
the others (due to software failure of the db update process, or whatever).
Granted, since the whole db is generated offline nonincrementally, then if
we can identify an inconsistent db we can report this (corrupted db files)
and ask the user to rebuild the db. But I think I'd prefer an approach
where everything was in just one file. Since there's no incremental
updating going on, there's nothing to lose.

Combining everything into one file is easy (e.g. we could put a list of tags
at the start, and offsets into the files).
"Artist",<binary offset into file for artist info>
"Album",<binart offset into file for album info>
"Song",<binary offset into file for song title info>

Doing something like this has the added advantage that rockbox doesn't need
to be updated when new tag types are added to the db. Additionally, the db
could be constructed from tags not even present in the ID3 information (but
somehow inferred by whatever creates these dbs, e.g. create a "Most Recently
Played", "Least Recently Played" index?).


Also, I don't think there is much milage in mapping from a subset of
song-index entries to a particular album name - that is only useful if any
given album is likely to have two or more tracks on it that are
alphabetically adjacent to each other in the entire list of songs! (I don't
think this is likely).
How about this:

album-index.id3db:
<album name1>;<number of songs>;<song-index offset1>;<song-index
offset2>;<...>
<album name2>;<number of songs>;<song-index offset1>;<song-index
offset2>;<...>

artist-index.id3db:
<artist name1>;<number of albums>;<number of songs>;<album-index
offset1>;<album-index offset2>;<.....>;<song-index offset1>;<song-index
offset2>;<.....>

Here, we store all of the song indexes for each album. We also store all of
the ALBUM indexes for each artist, but ADDITIONALLY all of the SONG indexes
for songs on which the entire album is not by the same artist. That's a
step that the db creator can figure out. The alternative is of course to
have the entire list of SONG indexes for both the artist-index and the
album-index, but that would bloat the artist-index considerably.

Thoughts?

d

----- Original Message -----
From: "Björn Stenberg" <bjorn_at_haxx.se>
To: "Rockbox development" <rockbox_at_cool.haxx.se>
Sent: Wednesday, October 13, 2004 9:49 AM
Subject: Re: ID3 database browsing


Linus Nielsen Feltzing wrote:
> 1) What do we want in the ID3 browser? I mean, which fields do we
> support? How do we want to search?

The three fields artist, album and song goes a long way. I think we should
start with those (while of course not designing ourselves into a corner
where we can't add others).

> 2) How to design the database to allow for fast searching/browsing with
> as little memory usage as possible? We can waste quite a lot of disk
> space, but not that much RAM.

Here's a discussion starter. For the above three fields, we could use four
files:

allfiles.id3db is a simple file list, one file per line. The list is un
sorted.

<field>-index.id3db are index files, sorted alphabetically by field:

song-index.id3db:
<allfiles offset1>;<song name1>
<allfiles offset2>;<song name2>

album-index.id3db:
<song-index offset1>;<song-index offset2>;<album name1>
<song-index offset1>;<song-index offset2>;<album name2>

artist-index.id3db:
<album-index offset1>;<album-index offset2>;<artist name1>
<album-index offset1>;<album-index offset2>;<artist name2>

That takes care of finding and browsing artists, albums and songs by name.
We can also connect artists to their albums and albums to their songs. We
don't have connections backwards though (browsing artist and album from
song), but since that data is present in the id3 tag we can just search for
it.

This format is also expandable with year, genre etc using the same formula.

> 3) How to synchronize/generate the database?

Offline. No incremental magic, total remake each time (checking to see if a
file's info has changed is more expensive than just adding it).

First create the list of files, then song-index album-index and artist-index
in that order (since they depend on each other).

Comments?

-- 
Björn
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox

Received on 2004-10-13