From: Owen Sebastian Hofmann <oshofmann_at_amherst.edu>
Date: Sun, 08 Jun 2003 21:32:47 -0400

TP Diffenbach wrote:
> I'd been thinking -- nothing more -- of doing something similar, hacking dir_cache
> and tree.c to display playlists, as alternate "directory structures".
>
> I think your work is a good start but would be useful if it could read .m3u
> playlists, perhaps with additional optional syntax to represent virtual
> "subdirectories".
>
> What I don't like is the binary format; if you're referring to files and
> directories as strings, e.g., "/dir/dir/file.mp3", I figure you can't get much
> addiional compression or speed with a binary format anyway.
>
> Why do you prefer to seperate the parser out?
>
> I believe that the .m3u specification allows embedding the name of a playlist
> within a playlist, which could represent subdirectories; it would additonally be
> nice to represent them inline using your syntax or similar.
>
> --Tom

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. The parser
hits a directory, reads its name, and then must skip over its contents
in order to read the next file. In a format that is easily
human-readable and can be edited by hand and used immediately, this
means that the player must read through every single byte until it
reaches the end of the subdirectory. In a complex layout with many
songs, combined with rockbox's limited capacity for buffering, this adds
up to time-consuming disk accesses which lose the feeling of actually
browsing through the hierarchy. A binary format allows you to say,
"This block here, it takes up X bytes" and then just do a seek to get
to the next file. The format is relatively simple, I should have
explained it earlier: each block has a header with one byte specifying
the type of block, an integer specifying the length of the label, and an
integer specifying the length of the data, be it a path or a list of
other blocks. The the label and data are written one after the other.

In response to Eric: I had actually thought about that, and it was
really just a matter of preference. I liked the idea of these
hierarchies not actually existing by means of directories.

About m3u's as directories: another thing I had thought about doing.
And it would be pretty easy to do. I just decided to go for allowing a
more complex hierarchy, which is entirely behind the decision for the
binary file format. I tried parsing the plaintext files in firmware
originally, but the code just didn't 'feel right' for the limited space
and speed of the jukebox.
Received on 2003-06-09