From: Owen Sebastian Hofmann <oshofmann_at_amherst.edu>
Date: Wed, 23 Jul 2003 21:27:23 -0400

> would this not rely on a contiguous file?

If you mean continguous on the disk, no. otherwise, I'm not sure what
you mean.

> if you use pascal strings, you can search quickly... the string is
> prefixed with it's length - this also allows for variable length
> strings;

But with that you lose the power of the binary search. searching 2000
files would take twice as long as 1000, rather than a nearly
insignificant amoutn.

> alternatively you can prefix a long stream of C strings with an
> offset table ...this second method would be quicker, but require more
> memory.

Well, since it's still disk-based, you don't really need any more memory
at all. It does allow for binary searching as well as variable length,
which is nice. But I think a limit on entry length is reasonable.
Basically what I did was restrict entries in the database to 30
characters. I believed this to be a good solution for two reasons: 1)
id3v1 tags are that long, and I've never really run into a problem where
id3v1 hasn't been able to store enough information to completely
indentify the file (except perhaps in the case of bands who are really
pretentious about naming their songs ((yes, I am nesting parentheses,
which is weird) Godspeed you! Black emporer, a silver mount zion, etc.))
*breath* and... 2) in terms of searching, anybody typing anywhere near
30 characters on the on-screen keyboard is absolutely bonkers.

> If you restrict yourself to 26 characters, then you only need 5bits per
> character; which will compress the text quickly and simply, leaving 5
> characters over for say {' ', '\'', '_', '!', '?'}

This would reduce the size a little, but would be terrible pain to
implement. Bit shifting your eyeballs out.

> food for thought.

I'll second that.

-Owen
Received on 2003-07-24