similar to: flac in the filesystem?

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 >

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

* 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

What is the best way to add song metadata (artist, album, title, etc.) to flac files? I want to be able to define an arbitrary number of FIELD=value pairs. Earlier I heard someone mention using id3 tags. I tried this with the command-line "id3v2", and while it seemed to work I noticed that the resulting file no longer began with "fLaC", which violates the format

Matt Zimmerman <mdz@debian.org> wrote: > On Thu, Nov 21, 2002 at 08:11:13PM +0100, Steve Lhomme wrote: > > > Well, I think going GPL would be too much, only GPL softwares could use > > the library. > > This is a common misconception, but entirely untrue. There are many > free software licenses, including the BSD-style licenses, which are > compatible with the

I'm not sure about the legacy JIT interface, but I don't think this can be done cleanly with the current MCJIT interface. I mentioned a while ago that this is one of the improvements we'd like to make to MCJIT. I can definitely see Josh's point about performance, and so we won't want permissions to always be set, but I do think it's worth revising the interface between

Have you considered trying to have FLAC become an official part of the Ogg project? Ogg has Vorbis but no lossless codec, and FLAC is already production quality. You've already written the code to wrap FLAC in an Ogg bitstream. Ogg Squish seems to be abandoned, and it would be a grand waste of effort to revive it when FLAC already works so well. The Ogg people would be much better off

--- Joshua Haberman <joshua@haberman.com> wrote: > 2. I was hoping that the new metadata API would mean that an encoder > could be written without having to know *anything* about the bitwise > layout of the stream format, but that seems not to be the case. From > src/flac/encode.c: > > ( void metadata_callback() ) > /* all this is based on intimate knowledge of the

Allow an alternate libc, such as dietlibc, to be used for the init binary in the supermin appliance. Rich.

I'm kind of swamped today so I'll answer what I can get away with until tonight: --- Joshua Haberman <joshua@haberman.com> wrote: > The most interesting questions to me are ones you didn't address: > > 1. Will Ogg FLAC become the default manifestation of the FLAC codec? > If not, why not? What does Ogg not offer that makes it worth having > two different file

The main problem, as I see it, is that there's no way for the memory manager to know when it can safely change the protection state of sections apart from making assumptions about the implementation of MCJIT (namely that it will generate code on construction) and receiving some sort of notification outside the standard interface. I believe there's also no provision for handling read-only

In the world of the MCJIT, memory allocation, including permissioning, is the responsibility of the client application. The MCJIT only directly touches memory in the address space of the host. Once the old JIT is removed, all of the allocations done by the included memory manager can become RW. lli's trivial memory manager will then have the RW->X transition for code sections. All of the

Thanks for the quick response on the C++ thing. It would also be nice if the host program could correctly write the STREAMINFO block in the stream encoder metadata callback without having to know the specifics of the header format (or worry about endianness). How exactly to achieve this might take some thought, but what about this idea: 1. The correct way to respond to the metadata callback:

When you talk about lazy compilation, it isn't clear to me if you mean the single compilation step that produces a loadable module being delayed until a function is requested or the full-blown, legacy-JIT style lazy compilation of individual functions within a module being JITed only when needed. If the latter, it isn't clear to me how that would be done within the MC model. That's a

Somewhat, yes. The MCJIT currently doesn't support lazy compilation in general, and things like notifications back (via the memory manager) when new sections have been produced and such needs to be part of that. Your'e right that, for now, the underlying assumption is that everything gets built up at once. The following is mostly stuff we've talked about before, but just to make sure

Hello FLACers, I'm working on implementing FLAC support for Audacity, a cross-platform audio editor (audacity.sourceforge.net). We're experimenting with using FLAC as the internal data representation. Unfortunately, the FLAC headers cannot be used in C++ programs because of the use of 'private' and 'protected' as variable names in stream_decoder.h, stream_encoder.h, and

On Jul 17, 2012, at 8:07 PM, Josh Haberman wrote: > I noticed that JITMemoryManager allocates its slabs as rwx. Isn't it a security problem to have memory mapped as both writable and executable? I think JITs often avoid this by mapping their memory as rw, then switching it to rx once the data has been written. I was facing a similar problem in a JIT of my own and was curious to see how

Hi list, I'm trying to compile samba 3.0.1 rc1 with --enable-dmalloc switch because I have been asked to provide more information on a winbindd panic on a Solaris server. However the configure fails with the error shown below, config.status: creating include/config.h Note: The dmalloc debug library will be included. To turn it on use ./configure: command substitution: line 3: syntax error:

v1 -> v2: - If we split out the init program into a separate init/ directory, that makes it much easier to build against an alternate libc. I tried to build against uClibc, but uClibc requires an entire build chain, which looked like it was going to be a massive ballache. Rich.

Hello, I have updated to Xapian 1.1.4 and maybe there is a memory leak. I can run only dmalloc - valgrind would be much too slow. How can I build a debug-build of xapian? Thanks a lot Marcus