similar to: Exact FLAC subset constraints

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

I'm misleading about FLAC subset constraints... Please help me understand exact FLAC subset limitation.

Hi I am thinking of ripping albums to a single flac file with embedded cuesheet. As track and index points have to be on a 588 sample boundary due to the CD TOC standard working in 588 sample frames, I thought it may be beneficial to rip CDs with a blocksize of 588 samples. According to the format page on sourcefourge a stream is subset if "The blocksize bits in the frame header must be

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:

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

Hi Josh, I made some choices for the encoder based upon how quickly the pocket pc could convert files. I think that I chose flac -0 because of this and also I think that I may have increased the buffer already to 4608. However, I will do some additional testing. The cpu's used are in the ARM family. Xscale (PXA255) as found on the hp 5100/5500 series and 2200 series. The best performer

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 >

I have some FLACs that have STREAMINFO that looks like this: METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minumum blocksize: 4608 samples maximum blocksize: 4608 samples minimum framesize: 0 bytes maximum framesize: 0 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 0 MD5 signature: 00000000000000000000000000000000 (This came

So I recently encoded my entire CD collection (over 7000 songs) to flac and I have found that 18 of them have a strange problem.  The files are corrupted in some way.. They will stop playing abruptly in the middle of the song.  I've attached a listing of the metadata and you'll see what I mean.  You can see that the seek points toward the end have a bunch of zeros and I'm not sure

Hello, I'm currently doing a little music player using libflac and libao. What I've currently done works as it should, but I have a problem where only one metadata block is detected, even if there are more (it doesn't have the last attribute set to true). This is using flac 1.3.2 on Gentoo amd64. The main code file is attached, it mainly follows the examples given with the libflac

Hello, I'm currently doing a little music player using libflac and libao. What I've currently done works as it should, but I have a problem where only one metadata block is detected, even if there are more. This is using flac 1.3.2 on Gentoo amd64. The main code file is attached, it mainly follows the examples given with the libflac and libao doc. And here's what metaflac --list

Torsdag, 23 januar 2003, skrev Tor-Einar Jarnbjo <Tor-Einar_Jarnbjo@grosch- link.de>: >According to the format description, the coding method has to be 0. > >I've been using libFLAC 1.0.4 to encode the stream. I've checked my interpretation against "flac -a" and it seems to read 17 bits for each warmup sample. Here is its output: frame=168 blocksize=4608

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 that > the same file is used for this test (hopefully ruling out any issue with > the encoder). > > Details of the

--- "Stephen F. Booth" <me@sbooth.org> wrote: > Hello all, > > I recently upgraded the libFLAC used in my application Max (http:// > sbooth.org/Max/) to 1.1.3 and added preliminary support for album > art. During the upgrade I evidently made some coding mistakes with > interesting results. I've combed everything over and can't quite see > the

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

> 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

Here you are: soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ metaflac --list 02\ St?rtebecker.flac METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minimum blocksize: 4608 samples maximum blocksize: 4608 samples minimum framesize: 14 bytes maximum framesize: 15637 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 5857656