similar to: No subject

I mean that the first statement [Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz).] published on https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize page IS NOT EQUAL to second statement [The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample

I think you've found a bug, Bart. flac 1.2.1 did not have any FLAC__format_blocksize_is_subset() function, so the source you're seeing in format.c must be new. If the format documentation you linked to is correct, then either the specifications are self-contradictory, or the code is not implementing the subset checks as described. My interpretation is that blocksize bits of 0110

I mean that the first statement [Subset streams must use one of 192/576/1152/2304/4608/256/512/1024/2048/4096 (and 8192/16384 if the sample rate is >48kHz).] published on https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize page IS NOT EQUAL to second statement [The blocksize bits in the frame header must be 0001-1110. The blocksize must be <=16384; if the sample

Any progress? > I agree. Please keep up informed. >> FLAC__format_blocksize_is_subset() was introduced by commit #8ab0138 >> (https://gitorious.org/flac/flac/commit/8ab013837d379d3d1fa84eac5420faec41852fd7) >> over 5 years ago and available in the latest stable release 1.3.0. >> >> It would be nice if the official FLAC documentation used common >> adopted

>>>>>>>>> I'm misleading about FLAC subset constraints... Please help me >>>>>>>>> understand exact FLAC subset limitation. >>>>>>>>> >>>>>>>>> From https://www.xiph.org/flac/documentation_tools_flac.html#flac_options_blocksize: >>>>>>>>>

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'm misleading about FLAC subset constraints... Please help me understand exact FLAC subset limitation.

No, FFMPEG uses its own FLAC encoder/decoder, based on Flake source code, that based on FLAC reference encoder/decoder source code. Yes, I agree that "optimal"? values for reference encoder/decoder may differ "optimal"? values for FFMPEG's encoder/decoder. But we're talking about the "highest reasonable" values, not "optimal". >>>>>

> check the resulting file for subset blocksizes, sample rates, bits per sample, LPC filter order and rice partition order. That's all parameters that I need to check? 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

> > the best thing would be to try and set the > blocksize > > to match the length of the individual 'sample'. > if > > each sample is much shorter than the blocksize > then > > the encoder may not be able to generate an > efficient > > model of the signal. if the samples within the > > soundfont vary greatly in length that also makes >

Josh Coalson wrote: > yeah, flac doesn't have a 'gzip' fallback method > so any non-audio data will probably get stored > verbatim. I'm kind of reluctant to add a generic > compressor. If you wan't, you could come up with a > FLAC metadata block to store a gzip'ed chunk and I > could add that to the format. > I had the same thought when I was

sorry if I did not reply to this, answers below: --- Josh Green <josh@resonance.org> wrote: > On Tue, 2006-07-25 at 06:37 +0200, Josh Green wrote: > > A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a > bug > > report related to decoding of CRAM files. This issue occurs with > > flac-1.1.2 but not previous versions (such as flac-1.1.1). Note >

For those who are interested in checking out my initial specification for the FlacPak format, I updated the web pages at: http://swami.sourceforge.net/flacpak.php The direct link to the specification notes: http://swami.sourceforge.net/flacpak_format.php For those who weren't reading the previous threads, FlacPak is a format being designed to handle compression of files containing binary 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 +++---------

hi Howard, I'll check into the discrepancy but having the FLAC blocksize match the CD sample frame size is probably not desirable. the optimal blocksize for FLAC is relative to the stationarity of the signal and the 588 sample frame is not related to that, it's an artifact of optimal storage on CD. Josh --- Howard Farrar <howard.farrar at meridian.co.uk> wrote: > Hi > >

Thanks for the info, Dave. Speed is a very important feature, but there might be some risk choosing the FFmpeg decoder. They've had trouble with their encoder in the past, which tells me it's possible your users might one day run into a valid FLAC that the FFmpeg decoder won't handle correctly. A better suggestion might be to start with libFLAC, optimize as needed, and

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:

--- Josh Green <jgreen@users.sourceforge.net> wrote: > I stripped out all non-audio data from a few fonts > (which doesn't > usually amount to much, 50k in a font with a lot of > preset/instrument/sample overhead information). I > managed to save a good > 20k by gzipping this data and not making FLAC > compress it. Not that much > for all the effort. Although I

Hi, For some reason I see this in my logs: [2016-08-02 12:43:02] INFO source/send_to_listener Client 169 (127.0.0.1) has fallen too far behind, removing The more interesting is that it is the ffmpeg, that is listening to the source stream being removed. My setup is: Stream generator: DEVA TX, streaming 44,1 khz PCM (pcm16le) stream to icecast2 server Transcoding: VM with ffmpeg reading this

https://ffmpeg.org/pipermail/ffmpeg-user/2015-April/025906.html https://trac.ffmpeg.org/ticket/4421 Some ffmpeg-encoded FLAC files can be successfully decoded by ffmpeg, but not FLAC. So it's either a bug somewhere (presumably in ffmpeg, but maybe in FLAC), or ffmpeg treats something differently than FLAC. libFLAC has routines like FLAC__lpc_compute_residual_from_qlp_coefficients and