similar to: stream_encoder metadata callback

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

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

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 >

Are there any plans to add stack switching to LLVM? I've seen a few proposals for it floating around (some even implemented): http://ulir.ul.ie/handle/10344/2927 (implemented in: https://github.com/stedolan/llvm) https://code.google.com/p/llvm-stack-switch/ But I couldn't find any discussion of whether there was a plan to integrate one of these. Any plans to add this feature? Thanks,

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

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

Hello! I'm using the seekable stream decoder API of libFLAC 1.02 and I think that I found a possible bug in process_metadata(). The problem is as follows: I have a file which isn't a FLAC sample (it's actually an ACE archive) where process_metadata() returns TRUE. And even worse, the metadataCallback() is never called (which means process_metadata() succeeds, although no metadata is

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

I'm seeing these recently: Feb 27 09:24:01 nihlus dovecot: imap(tlx at leuxner.net): Error: istream-seekable: safe_mkstemp(/tmp/dovecot.imap.) failed: No such file or directory Feb 27 09:24:01 nihlus dovecot: imap(tlx at leuxner.net): Error: istream-seekable: safe_mkstemp(/tmp/dovecot.imap.) failed: No such file or directory Feb 27 09:24:01 nihlus dovecot: imap(tlx at leuxner.net): Error:

I've been trying to get oggdec to work with input streamed in through a pipe or a socket. This seems to work on Linux and OS X, but not on Windows. I've found that code in vorbisfile.c tests the input stream for seekability by invoking fseek in the following way: int offsettest=(f?callbacks.seek_func(f,0,SEEK_CUR) : -1); Unfortunately, fseek succeeds for a socket on Windows (even

I have checked in a few changes worth noting: 1. I split the file decoder into a more general 'seekable stream decoder' which, makes the file decoder just a special case of the seekable stream decoder. this is useful in situations where you are trying to add decoding support to something that has abstracted the file away. the file decoder interface is still identical, it is all backward

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

Hi, I use the following code: if (ov_open(NULL, &vf, const_cast<char*>(reinterpret_cast<const char*>(get_data())), get_size()) < 0) error = 0x100; else { vorbis_info* vi = ov_info(&vf, -1); Cvirtual_file f; const int cb_samples = ov_pcm_total(&vf, -1); const bool seekable = ov_seekable(&vf); So all data is already in memory and passed to

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

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

Right now it is impossible (using the metadata API) to get metadata from a FLAC stream unless it is a file on the local disk (AFAICS). It would be useful if there was another interface level that could provide read-only access to metadata by providing the data via a read callback. This would allow metadata to be read from remote locations and in streaming situations. BTW, right now I am adding