Displaying 20 results from an estimated 1000 matches similar to: "stream_encoder metadata callback"
2004 Sep 10
1
make headers C++ compatible?
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
2004 Sep 10
2
adding song metadata
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
2004 Sep 10
3
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
>
2014 Jan 05
3
[LLVMdev] stack switching?
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,
2004 Sep 10
2
flac in the filesystem?
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
2004 Sep 10
3
Should FLAC join Xiph?
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
2004 Sep 10
2
possible bug in process_metadata()
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
2012 Jul 18
2
[LLVMdev] rwx pages dangerous?
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
2004 Sep 10
2
FLAC as part of the Ogg project?
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
2004 Sep 10
1
flac-1.0.3_beta released
--- 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
2016 Feb 27
2
Error: istream-seekable: safe_mkstemp(/tmp/dovecot.imap.) failed
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:
2004 Sep 10
2
Should FLAC join Xiph?
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
2004 Oct 14
3
patch for non-seekable streams on Windows
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
2004 Sep 10
2
latest checkins
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
2012 Jul 18
2
[LLVMdev] rwx pages dangerous?
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
2012 Jul 18
0
[LLVMdev] rwx pages dangerous?
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
2001 Nov 12
1
Vorbisfile: non-seekable
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
2012 Jul 18
1
[LLVMdev] rwx pages dangerous?
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
2012 Jul 18
0
[LLVMdev] rwx pages dangerous?
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
2004 Apr 17
1
Reading OGG embedded in a pack file
I have a number of assets packed into a single file. Some of these are OGG files. I have code to seek to the start of an embedded file, but cannot find any OGG functions that let me start at an arbitary point in a stream. The original code (which works) that opens a stream, then reads in the OGG data starts like this:
// Read from an already open stream.
// Assumes stream is positioned to