[Flac-dev] flac in the filesystem?

Joshua Haberman jhaberman at ups.edu
Tue Oct 30 23:38:03 PST 2001


I am looking to losslessly archive a lot of music and share it over a
network. The following stipulations lead me to an interesting conclusion:

1. Almost no programs can read or write flac files directly.
2. Almost all programs can read and write wav files directly.
3. The cost of encoding flac files is fairly low
4. The cost of decoding them is even lower
5. These files would be read much more often than they would
   be written.

So I was wondering if flac could be incorporated into the filesystem
driver so that any file ending in .wav would be transparently encoded
into flac. I don't know if this could be done at the vfs level so that it
could be done to all filesystems simultaneously, or if individual
filesystems would need to be modified.

Everyone has heard of or experienced Stacker or DoubleSpace woes, and may
wonder why I would actually encourage this kind of thing. There are a few
reasons why I find this sane nevertheless:

1. The overhead of decoding is so low that reduced disk I/O may even make
   reads faster than not compressing [0].
2. It's entirely opt-in -- if you don't want transparent compression
   to happen, just name your file sound.wave or sound.WAV or sound.notwav

However, I have limited expertise. I'd like to know your thoughts on this
idea -- especially if you're familiar with filesystem code. I don't know
enough to answer questions like "when would compression happen?" or "what
about concurrent reads?" .

On an unrelated note, have you considered the possibility I mentioned
several months ago of making it possible to write the STREAMINFO block
without knowing anything about the format? I would link to the original
message in the archive to refresh your memory, but geocrawler is down for
nightly maintenance.

Joshua

[0] I made that claim up, but I hope it's true. In any case, the reduced
    I/O should at least help compensate for the overhead of having to
    decompress on-the-fly.

-- 
Joshua Haberman  <joshua at haberman.com>




More information about the Flac-dev mailing list