similar to: Can a libFLAC encoder be initialize and called from inside a libFLAC decoder callback?

Have you tried decoding to memory, and encoding from that memory? This technique would avoid file I/O. If you are reluctant to allocate enough memory for the full file (and why not, with a 64-bit system?), then you could implement a FIFO. You would need a semaphore to keep track of the decoder's progress, and multithreaded coding. The decoder would pause, whenever the FIFO gets

Open src/flac/decode.c, find write_callback() function and add return FLAC__STREAM_DECODER_WRITE_STATUS_ABORT; to the beginning of the function. Decoding will fail with the following message: test.flac: ERROR while decoding data state = FLAC__STREAM_DECODER_READ_FRAME As you can see, decoder state isn't quite correct. One of the ways to fix this is in the attached

I write this small piece of code, that get pixels and encode them: ogg_page page; ogg_packet packet; m_frameSource.getYUVBits(m_buffer.y, m_buffer.u, m_buffer.v); theora_encode_YUVin(&m_encoder, &m_buffer); while(theora_encode_packetout(&m_encoder, isLastFrame, &packet)) ogg_stream_packetin(&m_oggStream, &packet); while

On Jan 2, 2007, at 1:54 PM, Josh Coalson wrote: > this is reported a lot. usually it is a misunderstanding in how > to send samples to FLAC__stream_encoder_process() or > FLAC__stream_encoder_process_interleaved(). if you could send > your code where you are doing that, it would help. > > note that samples going in to the process calls must be converted > to signed 32-bit

On Jan 2, 2007, at 5:15 AM, Arek Korbik wrote: > The binary frameworks distribution, as found on: > http://xiph.org/quicktime/download.html , hasn't really been tested > much outside the XiphQT project. I never had any problems with them, > but any improvement suggestions or help is welcome. Well, ok, then if the framework is intended to work, then let me describe closer the

Sorry that it has been a while since the last altivec patch. I have noticed something interesting, and so it remains unfinished... On the ppc, even with the altivec optimizations, almost a quarter of the time is spent in FLAC__stream_encoder_process(). I finally discovered that it is because of all the integer to float conversions. Aside from being exceptionally slow on the g4, they

On Fri, Jul 20, 2001 at 03:01:54PM -0700, Josh Coalson wrote: > --- Matt Zimmerman <mdz@debian.org> wrote: > > > > automake will include ltmain.sh in the source distribution, so it > > should be > > used even if it isn't installed on the build system. In fact, it > > seems to > > always use the distributed version, and not the installed one

> OK, that worked. > > I checked in your patch to make a static libFLAC-asm.a and > I moved @XMMS_LIBS@ to the end of ...LIBADD. Matt and Ben, > can you try the latest CVS to see if it works for you now? It doesn't work for me. Looks like libtool decided not to link libFLAC-asm.a into libFLAC. Here's the output: Making all in src gmake[1]: Entering directory

Hi. I'm have a little problem with setting compression level since 1.1.3 releases. I'm using : FE = FLAC__stream_encoder_new(); FLAC__stream_encoder_set_channels( FE, channels); FLAC__stream_encoder_set_bits_per_sample( FE, bitsample); FLAC__stream_encoder_set_sample_rate( FE, samplerate); unsigned int level; if (formatdatalen>0) level = *(char*)(formatdata); else level = 7; if

--- Evan Olcott <ev@audiofile-engineering.com> wrote: > > On Jan 2, 2007, at 5:15 AM, Arek Korbik wrote: > > > The binary frameworks distribution, as found on: > > http://xiph.org/quicktime/download.html , hasn't really been tested > > much outside the XiphQT project. I never had any problems with > them, > > but any improvement suggestions or help

Ian's explanation below was helpful: On Thu, Aug 14, 2014 at 7:53 AM, Ian Nartowicz <ian at nartowicz.co.uk> wrote: > The sample rate should take care of itself. I suspect your difficulty is how > the 24 bit samples are represented in the WAV data and how to pack them into > the Flac buffer? > > WAV samples are stored in either 8, 16, or 32 bit words, using the smallest

I have in my working directory the trivial header changes necessary to allow FLAC library functions to be used in C++ programs. Is it OK to commit this? -- - mdz -------------- next part -------------- ? Makefile ? Makefile.in ? ordinals.h Index: file_decoder.h =================================================================== RCS file: /cvsroot/flac/flac/include/FLAC/file_decoder.h,v

Here are the warnings I get with 03a9e6064d406e3656afacdbe50e8e47ebfa0de3: LANG=C android-make | grep Warning bitreader.c: In function 'FLAC__bitreader_skip_bits_no_crc': bitreader.c:494:4: warning: implicit declaration of function 'MIN' [-Wimplicit-function-declaration] bitreader.c:494:4: warning: nested extern declaration of 'MIN' [-Wnested-externs] bitwriter.c: In

Thanks for the tip, Brian. I did have a version that does everything in memory, but only had enough memory to get six threads going. (Although my system has 16GB, I have not taken the time to create 64-bit libraries for wxWidgets, TagLib, libFLAC, etc.) Based on the direction you are pointing me in, I assume that encoding from within the decoder is not permitted. I really like your idea of the

FYI, I have checked in a few interesting things. One is a speedup to the decoder (about 15% improvement in overall decode time). Another is a new interface to FLAC file metadata. If you're curious look at include/FLAC/metadata.h. It is basically a collection of object manipulation routines and iterators that make it pretty easy to add/edit/delete FLAC metadata in files efficiently. The

2013/5/15 Ulrich Klauer <ulrich at chirlu.de> > Felix Homann wrote: > > > Yes, HAVE_SYS_PARAM_H is set in config.h: > > OK ... Yet still I don't see how a change in > src/libFLAC/include/private/macros.h could affect src/flac/utils.c in > any way. > > Anyone got an idea? I haven't spend too much attention to the errors when bisecting, sorry! The

Hi, In the last days I've been taking as reference the example found in examples/c/encode/file/main.c. With it I've been able to encode a 2ch, 16 bps, 44100 sample rate input WAV file to a FLAC file. Now I've been trying to modify this example to encode a 2ch, 24 bps, 96000 sample rate WAV file. I have to say I'm a bit lost on how I should read the input file in this case, and

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------