Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: Patch - virtual file structures

Re: Patch - virtual file structures

From: TP Diffenbach <rockbox_at_diffenbach.org>
Date: Mon, 9 Jun 2003 00:16:23 -0400

Quoting Owen Sebastian Hofmann <oshofmann_at_amherst.edu>:

> There is one main reason for the binary format. Think about a directory
> tree written in a nested text format like I have written above. Each
> directory can contain dozens of files, and also contain directories
> which themselves contain dozens of files. These add up, which creates a
> problem when trying to display a single directory as a list.


Yeah, I've thought about this. :) Quite a bit. I was thinking of using something
similar to provide a searchable "database" of mp3s: index files of
{ unique id, offset to name, offset to index }
{ unique id, offset to name, offset to index }
...
name,
name,
...
unique id of first index entry for unique id 1,
unique id of second index entry for unique id 1,
...
unique id of Nth entry index entry for unique id 1,
unique id of first index entry for unique id 2,
unique id of second index entry for unique id 2,
...
unique id of Nth entry index entry for unique id 2,
EOF

with index files for genre, album, artist, composer, song, and one file with
actual paths, ordered by unique id.

The difference is that I wouldn't expect this to be human writable, so I didn't
see a need for them to be human readable. You indicate (in another email) that
you expect that in some cases your files would be tool-generated, with lessens my
objection to a binary format.

But since your objection to human readbale files is the inefficiency of skipping
over subdirectory information, may I susggest making a virtue of necessity?

How about limiting your files to the following: entries that point to real files,
entries that point to real directories, and entries that point to other virtual
directories. If you did this, each entry would be one line (or two, if you allowed
a line that gave a different display name). Furthermore, the virtual directories
would be compatible with existing .m3u files with #EXTINFO lines, so existing
tools would be already available on Windows and linux AND on Rockbox, to write
them. And they'd be human readable and writable as well. And it might make your
code simpler to write, and for others to modify.

--Tom--
Archos FM has a Rockbox!
Received on 2003-06-09

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy