Rockbox mail archiveSubject: Re: ID3 database browsing
Re: ID3 database browsing
From: Jacob Erlbeck <jacob01_at_gmx.net>
Date: Mon, 18 Oct 2004 13:42:23 +0200
On Mon, Oct 18, 2004 at 10:56:18AM +0200, Björn Stenberg wrote:
> Jacob wrote:
> > > I don't think this is necessary.
> > > The process would take forever on an archos.
> > I don't agree to this hypothesis. Instead I would like to recall the
> > dbase argument: Back in the good old days (TM) it was possible to index
> > this amount of data (say 12000 records) on slower CPUs with much less
> > RAM and much slower mass storage in reasonable time.
> No they couldn't. We are talking about 12000 *files* here, each several megabytes in size. Not 12000 records in a database. How many 80-gig disks did you have in your IBM XT? ;-)
How often do you replace all of the 12000 files on the disk? So if there
were a data table which contains the relevant id3 data along with the
filename, file modification time and size, you would have to seek and
parse only newly added files. This table can even be split into two,
to separate id3 and file data, so that the latter could fit into
memory when looking for modified and/or added files.
BTW, dbase on an IBM XT (640kB RAM, 20 MB hard disk) had been notably
slower than on a 4Mhz, 128kB RAM, Z80, Floppy-based, CP/Mplus device.
> To get a slight feel for the performance, try the "create playlist" function. The only thing it does is traverse the directory tree, yet even that takes significant time (and not because the code is slow). Then imagine opening each and every file in those directories, seeking to the end of them, reading the id3 tag and parsing it. It will take massive amounts of time.
> Offline database creation will be faster, easier to write and more user friendly. If anyone wants to write code to do it on the player that's fine with me, but I won't do it.
I'm not asking you to do the coding if you don't want to, I'm talking
about not to make it impossible for someone else to do it, without the
need to change the database format completely. If you can live with the
support of two different database formats, fine. At least in this case I
suggest a proper database API (no, not a generic SQL one, but something
that hides the real database structure), so that those who prefer local
database updates are able to do it by replacing the offline database
code. But I definitely prefer a common format for both approaches.
Received on 2004-10-18