Hi Matt, thanks for the reply. * Matt Zimmerman (mdz@debian.org) wrote:> On Tue, Oct 30, 2001 at 11:39:11PM -0800, Joshua Haberman wrote: > > > 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. > > If you really want this, the right place to implement it is in > userspace, not in the kernel. Take a look at libbz2 and zlib for > examples of how this can be done. You could write a FLACopen routine > like gzopen, which would transparently encode/decode from/to WAV format. > This would probably go in the FLAC library, and make it trivial to add > FLAC support to many WAV-supporting programs (those which don't use > mmap).This doesn't give me the transparency I desire.> If you wanted transparency, you would write a shared library which would > override open(), and perhaps read(), etc. and do its magic there. > fakeroot, esddsp, and dmalloc are examples of how this is done. > However, in this case, you'd want to name all of your FLAC files with a > .wav extension so that the programs in question would open them. The > right thing to do is to add FLAC support to these programs, and the > above technique might make that easier.I hadn't thought of that. I like how this lifts me of the burden of having to muck around in kernel code. However I dislike how flacs are deceptively given .wav extensions, which will mess up programs that are linked statically or somehow run without LD_PRELOAD set correctly. I disagree that adding flac support to all programs is "the right thing to do," simply because it's not necessary or realistic. In my scenerio, people will be accessing the music using many different programs and OSs, and there's no reason why each one should be required to learn about a different format when it's conceptually identical to reading a straight wav file. As someone who's doing development on an application involving digital audio, I can tell you that it's a pain spending time supporting umpteen different formats when each of them has a command-line encoder that understands wav just fine (but alas, that's what users want...). I really appreciate the suggestion to LD_PRELOAD, thanks. Joshua -- Joshua Haberman <joshua@haberman.com>
--- Joshua Haberman <jhaberman@ups.edu> wrote:> I disagree that adding flac support to all programs is "the right > thing > to do," simply because it's not necessary or realistic. In my > scenerio, > people will be accessing the music using many different programs and > OSs, > and there's no reason why each one should be required to learn about > a > different format when it's conceptually identical to reading a > straight > wav file. As someone who's doing development on an application > involving > digital audio, I can tell you that it's a pain spending time > supporting > umpteen different formats when each of them has a command-line > encoder > that understands wav just fine (but alas, that's what users want...).this is the fundamental problem with having several formats. I think the idea of making .flac files look like .wav files and munging a layer that makes it work has the desired effect for the developed but will ultimately be confusing for the user. the trend now is migrating to format-neutral 'layer' libraries. for audio, these would be like audiofile and libsndfile, where the library handles the format details and prevents a uniform interface to the data. of course, then you have to pick a library that works for you, and there may not be one. but I think newer tools now are starting to do that (at least open source ones). I am working on a FLAC plugin for audiofile, and next will be libsndfile, if that's any consolation... Josh __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com
On Wed, Oct 31, 2001 at 12:16:04PM -0800, Joshua Haberman wrote:> I disagree that adding flac support to all programs is "the right > thing to do," simply because it's not necessary or realistic. In my > scenerio, people will be accessing the music using many different > programs and OSs, and there's no reason why each one should be > required to learn about a different format when it's conceptually > identical to reading a straight wav file. As someone who's doing > development on an application involving digital audio, I can tell you > that it's a pain spending time supporting umpteen different formats > when each of them has a command-line encoder that understands wav just > fine (but alas, that's what users want...).I agree with Josh (the other one) that abstraction libraries like libaudiofile are a good way to make this a zero-maintenance feature. Theoretically, support for new formats can be added to the library, and all programs using that library will become instantly able to handle it. So while the program could continue to deal with raw audio data, decoding of various formats would happen transparently through the library. This is a complete userspace solution that doesn't require any fancy preloading tricks (following the KISS principle). On a related note, it might be nice for the flac command-line encoder itself to link with libaudiofile, to enable it to read various audio formats for encoding. It could in effect become an anything->FLAC converter. -- - mdz
* Matt Zimmerman (mdz@debian.org) wrote:> I agree with Josh (the other one) that abstraction libraries like > libaudiofile are a good way to make this a zero-maintenance feature. > Theoretically, support for new formats can be added to the library, and > all programs using that library will become instantly able to handle it.This is clearly the best solution. However, no abstraction library exists today that can read and write all common uncompressed formats, vorbis, mp3, and FLAC. Instead I'm stuck writing and maintaining separate code for libsndfile, libvorbis, libmad, lame, and libFLAC. I also don't foresee all of the windows audio jukebox programs that my friends use linking with this universal audio format library anytime soon. :-( Joshua -- Joshua Haberman <joshua@haberman.com>