similar to: How to check/test existing FLAC stream for Subset?

Please help me understand what values of FFMPEG's "compression_level" preset generate subset FLAC stream and what not-subset? Default value of compression_level for FFMPEG's FLAC encoder is 5. FLAC specific encoder parameters: Encoder flac [FLAC (Free Lossless Audio Codec)]: Threading capabilities: no Supported sample formats: s16 s32 FLAC encoder AVOptions:

I have been playing around with sparse matrices in the Matrix package, in particularly with the Cholesky factorization of matrices of class dsCMatrix. And BTW, what a fantastic package. My problem is that I have to carry out repeated Cholesky factorization of a spares symmetric matrices, say Q_1, Q_2, ...,Q_n, where the Q's have the same non-zero pattern. I know in this case one does

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

Hey. The problems with Levinson -type algorithms and integrization are well known. Older codecs have usually solved the problem by using Schur decomposition for inversion of the autocorrelation matrix instead of Levinson. Another solution sometimes used is to use double precision - in this case you probably could code some pseudo-64bit implementation (using only 32bit commands), but that

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)

I scanned the website with linkchecker and found quite a lot of dead links. This commit fixes or removes them. --- developers.html | 2 +- documentation_tasks.html | 2 +- download.html | 12 ++++++------ faq.html | 2 +- features.html | 2 +- feeds/feed.xml | 8 ++++++++ format.html | 8 ++++----

I scanned the website with linkchecker and found quite a lot of dead links. This commit fixes or removes them. --- developers.html | 2 +- documentation_tasks.html | 2 +- download.html | 14 +++++++------- faq.html | 2 +- features.html | 2 +- feeds/feed.xml | 8 ++++++++ format.html | 8 ++++----

I was feeling masochistic the other day and we have been having some wierd memory problems so I started digging into the source for L-BFGS-B. In the lbgfsb.c file I see the following code: /* Cholesky factorization of (2,2) block of wn. */ F77_CALL(dpofa)(&wn[*col + 1 + (*col + 1) * wn_dim1], &m2, col, info); if (*info != 0) { *info = -2; return; } If I am not mistaken

>> 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 >>

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| --------------------------------------------------------

Hi Jean-Marc, I did what you proposed. I changed the levinson durbin algorithm to: { int i, j; spx_word16_t r; spx_word16_t error = ac[0]; for (i = 0; i < p; i++) lpc[i] = 0; if (ac[0] == 0) { //for (i = 0; i < p; i++) // lpc[i] = 0; return 0; } for (i = 0; i < p; i++) { /* Sum up this iteration's reflection coefficient

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

Hi, While exploring how summary.lm generated its output I came across a section that left me puzzled. at around line 57 R <- chol2inv(Qr$qr[p1, p1, drop = FALSE]) se <- sqrt(diag(R) * resvar) I'm hoping somebody could explain the logic of these to steps or alternatively point me in the direction of a text that will explain these steps. In particular I'm puzzled

On Mon, Dec 1, 2014 at 10:40 PM, ???? ?????? <bart.gopnik at gmail.com> wrote: > Please help me solve the following problem: > > FLAC tools have a lots of warnings about non-subset files during > encoding, but unfortunately don't have easy way to check/test existing > FLAC stream for subset compliance. > > "flac -a" generates the big text file that has

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > yes, I will probably get to it soon after the release. > the encoding side is pretty convoluted but for decoding, > src/libFLAC/stream_decoder.c:read_residual_partitioned_rice_() > should be pretty straightforward once you ignore the > FLAC__SYMMETRIC_RICE stuff (which is not used). feel free to > ask

Jean-Marc, >> > It's odd that it "almost" works with the fixed_generic.h. The easiest >> > thing would be to gradually replace routines and see which one causes >> > problem. It's most likely (though I'm not 100% sure) that somewhere in >> > the code, I have a 16-bit value that gets sent to a function/macro that >> > expects a

Erik de Castro Lopo wrote: > I think I have an alternative fix for the CVE which should not break > seeking. I'm working on getting an copy of the file with which to test. Patch applied and pushed. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

> -----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

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