search for: subframes

I think I've gotten FLAC__lpc_restore_signal() about as good as I'm going to get it. Here's what I have: -a new file, lpc_asm.s, which has the assembly routines -changes to cpu.h, cpu.c, and stream_decoder.c to enable them -changes to configure.in to support the new cpu stuff -a preliminary Makefile.am -maybe something else I'm forgetting Now automake complains that configure.in

...C__int32*)malloc(sizeof(FLAC__int32)*size+15U); if(tmp == 0) { decoder->protected_->state = FLAC__STREAM_DECODER_MEMORY_ALLOCATION_ERROR; return false; *************** *** 1809,1818 **** FLAC__int32 i32; FLAC__uint32 u32; unsigned u; decoder->private_->frame.subframes[channel].type = FLAC__SUBFRAME_TYPE_FIXED; ! subframe->residual = decoder->private_->residual[channel]; subframe->order = order; /* read warm-up samples */ --- 1821,1831 ---- FLAC__int32 i32; FLAC__uint32 u32; unsigned u; + FLAC__int32 *residual = (FLAC__int32 *)(...

I have noticed lpc slowdown both in encoding and decoding, not related to new config.h stuff. It seems there is wrong choosing of fastest possible version of lpc function. Patch is attached. -- Miroslav Lichvar -------------- next part -------------- Index: src/libFLAC/stream_decoder.c =================================================================== RCS file:

>> I'm jumping in on this thread to make a few remarks about the spec. I >> implemented a FLAC decoder by only looking at the spec, and I have a few >> notes that would have saved me a lot of time if the spec had mentioned >> them. They are obvious in hindsight, of course. >> >> * If the channel assignment includes a difference channel, then the >>

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

...have a few questions. - I am right, that the FLAC__bitbuffer_read_rice_signed_block method is doing the same as I would have achieved by filling the array in a loop by calling FLAC__bitbuffer_read_symmetric_rice_signed? - Should I allign the bitstream to the beginning of the next byte between the subframes, or only after reading the last subframe. I'm having some synchronization problems which might be caused by this. - My implementation seems to decode fixed subframes now, but the lpc subframes contains nothing but noise, and the bitstream is out of sync after reading one. The source code I'...

Hi Ruud van Asseldonk, > On Jun 11, 2017, at 7:24 AM, Ruud van Asseldonk <dev at veniogames.com> wrote: > >>> I'm jumping in on this thread to make a few remarks about the spec. I >>> implemented a FLAC decoder by only looking at the spec, and I have a few >>> notes that would have saved me a lot of time if the spec had mentioned >>> them. They

On Thu, Jun 19, 2014 at 03:30:06PM +0200, Miroslav Lichvar wrote: > But, as we have seen with unusual data the residual signal can be > wider than bps. The FLAC format specification doesn't seem to mention > this. Should it be treated as a valid FLAC stream? I think it would be interesting to know how common are such streams. I patched flac to print a warning on decoding or testing

I've been working on improving packet loss concealment in my VoIP client -- I hadn't actually realized speex performed some PLC until I was looking at nb_decode(). There are two things I'd like to do, and I think both will require some modification to nb_decode() and nb_decode_lost(). - I'd like to have my frames overlap by some number of samples. This is intended to reduce the

I've been working on improving packet loss concealment in my VoIP client -- I hadn't actually realized speex performed some PLC until I was looking at nb_decode(). There are two things I'd like to do, and I think both will require some modification to nb_decode() and nb_decode_lost(). - I'd like to have my frames overlap by some number of samples. This is intended to reduce the

I would like to know if my vision of things is correct about frame structure. -------------------------------------------------------- Frame header -------------------------------------------------------- Subframe1 header|Subframe1 content| -------------------------------------------------------- Subframe2 header|Subframe2 content| --------------------------------------------------------

...Josh Coalson > > Miroslav's suggestion is the best right now. I probably should > hand-craft a stream that exercises a decoder as much as possible. I've already tested my decoder with the options -0 to -8 and it works, but the streams doesn't contain any verbatim or constant subframes. I guess this depends heavily on the input file. Unpredictable noise will be coded as verbatim frames and periods of complete silence as constant frames? I'll see if I get to run the test-script mentioned, but I am not sure if my Linux installation is working very well. I've made the curre...

Hello, I've set up and have been reading through the FLAC reference implementation source code on Windows and stepping through it in the debugger.   I've been trying to understand how the protocol knows where the subframe and frame boundaries are. Is there a good tutorial that discusses the ins and outs of the flac protocol? Also, is there a piece of the reference code that shows how

looks fine, I would suspect how the PCM sample are formatted and sent to process(), could you show that part of the code? Josh --- James Smith <jsmith@landmarkdigital.com> wrote: > > I'm using libFLACC++ and libFLAC and I think that I'm using the calls > in the > typical order (see code below). But every monoe or stereo file that > I send > thru I get files

I don't understand the comment in src/libFLAC/stream_decoder.c: /*@@@@@@ technically not pessimistic enough, should be more like if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1) << 32) ) */ if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) see

Hi all, I'm jumping in on this thread to make a few remarks about the spec. I implemented a FLAC decoder by only looking at the spec, and I have a few notes that would have saved me a lot of time if the spec had mentioned them. They are obvious in hindsight, of course. * If the channel assignment includes a difference channel, then the subframe for that channel has one extra bit per sample

To avoid crash caused by an unbound LPC decoding when predictor order is larger than blocksize, the sanity check needs to be moved to the subframe decoding functions. --- src/libFLAC/stream_decoder.c | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index d13b23b..211b4db 100644 ---

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > --- Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch-link.de> wrote: > > Hi, > > > > have I just overseen a link, or is the format description on > > http://flac.sourceforge.net/format.html lacking information on how to > > actually decode the residual partitions to PCM sample data? > > you

...is this implementation of the DoD, nobody would voluntarily re-implement CELP. If I read the manual, I guess you just took the idea names CELP, did some conceptual work (resulting in NB, WB und UWB mode as well as all these bitrates Speex supports, as well as stuff like frame-length and number of subframes) and then actually made a new implementation (DoD CELP is far less than Speex). So the Question is: did you take any code from DoD CELP? What would happen, if I took a 8kHz-Wav file and did speexenc -n -.bitrate 4800 file.wav file.spx Would the result of this be comparable to a DoD-CELP encoded f...

Torsdag, 23 januar 2003, skrev "Tor-Einar Jarnbjo" <Tor-Einar_Jarnbjo@grosch- link.de>: >- My implementation seems to decode fixed subframes now, but the lpc >subframes contains nothing but noise, and the bitstream is out of sync after >reading one. The source code I'm using for decoding the lpc subframe is >available here: http://user.cs.tu-berlin.de/~bjote/Subframe.java and the >relevant part starts on line 218. I wo...