Rockbox mail archive
Subject: Re: Patch - virtual file structures
From: Owen Sebastian Hofmann (oshofmann_at_amherst.edu)
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
> 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.
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.
Page was last modified "Jan 10 2012" The Rockbox Crew