similar to: [PATCH] doc: Add notes about subframe sample size

Hi all, And cc'ing flac-dev. > On May 10, 2017, at 12:15 PM, Dave Rice <dave at dericed.com> wrote: > > Hi Andrew, > >> On May 10, 2017, at 11:19 AM, Andrew James Weaver <weevz at uw.edu <mailto:weevz at uw.edu>> wrote: >> >> Hello all! >> >> In a previous discussions on this list about people interested in working on the FLAC

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

Hello all! (cc-ing the flac-dev list) I would like to give an update as to the recent CELLAR work on the FLAC specification. • Work has been done to make internal and external links more accurate and reliable. • 'Rice Coding' has been clarified as 'Exponential Golomb Coding.' • Clarifications have been made for binary representation. • Typos and other small changes have been

> On May 12, 2017, at 1:05 PM, Dave Rice <dave at dericed.com> wrote: > > Hi all, > And cc'ing flac-dev. > >> On May 10, 2017, at 12:15 PM, Dave Rice <dave at dericed.com <mailto:dave at dericed.com>> wrote: >> >> Hi Andrew, >> >>> On May 10, 2017, at 11:19 AM, Andrew James Weaver <weevz at uw.edu <mailto:weevz at

Hi all, > On Jun 5, 2017, at 11:52 PM, Andrew James Weaver <weevz at uw.edu> wrote: > > Hello all! > (cc-ing the flac-dev list) > > I would like to give an update as to the recent CELLAR work on the FLAC specification. > > • Work has been done to make internal and external links more accurate and reliable. > • 'Rice Coding' has been clarified as

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 that are the same sze as the orginal wave files. Doing a flac -a on the flac files I see that I get: frame=9 blocksize=4608 sample_rate=8000 channels=1 channel_assignment=INDEPENDENT subframe=0

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

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 would like to know if my vision of things is correct about frame structure. -------------------------------------------------------- Frame header -------------------------------------------------------- Subframe1 header|Subframe1 content| -------------------------------------------------------- Subframe2 header|Subframe2 content| --------------------------------------------------------

Here's how I set up the data for processing: // For moving data into 32 bit shape uint8_t *buffer8 = NULL; uint16_t *buffer16 = NULL; uint32_t *buffer32 = NULL; unsigned sample32; unsigned sample, channel; uint32_t bitsPerSample = this->get_bits_per_sample(); numFrames = inData.GetSize();

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

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

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

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

hi group, I am making a little rails app to experiment with rails. It consists of one model, item, that represents an item on a todo list. A todo item has a description, a state (finished or not) and a due date. After changing the scaffold screens a bit, I wanted to be able to have no due date. I tried to do this by making a radio button; if ''no date'' is selected, the date

Hello, it is likely that I will have to analyze a rather sizeable dataset: 60000 records, 10 to 15 variables. I will have to make descriptive statistics, and estimate linear models, glm's and maybe Cox proportional hazard model with time varying covariates. In theory, this is possible in R, but I would like to get some feedback on the equipment I should get for this. At this moment, I have a

Configuration: Samba 2.2.8a with openLDAP 2.1.30 on a SeSE 8.2. server When adding a user using a ldif file we give the user a given name, say Ruud Baart. The cn and uid are the same, say 21cs12345 (a studentnumber). After adding the user to LDAP the displayname is as expected: "Ruud Baart". However after smbpasswd -a 21cs12345 -s secret the displayname is "21cs12345".

>> Ok I will give it a try and see what I can come up with. > Is the most interesting data the [frame] and [subframe] info? > Is the qlp_coeff[], warmpup[] and parameter[] data for each frame/subframe important? Yes, it would be nice if MetaFLAC will show minimum and maximum values of parameters (if are not constant/fixed) for the stream. And it would be VERY NICE if you implement

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