|
Rockbox mail archiveSubject: Re: Patch - virtual file structuresRe: 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 |