similar to: "Compression failed" message

lvqcl wrote: > Git version of the FLAC encoder prints error message: > > ERROR: Compression failed (ratio 1.xyz, should be < 1.0). Please contact the developers. Yes, this was added to make sure that during encoding, the flac output file was smaller than the input file. It may be worth replacing the "Please contact developers" with a link to a web page with an explanation.

If I use flac with piped input it warns: FAILURE: Compression failed (ratio 495232,432, should be < 1.0). This happens for some files for one or more of the following reasons: * Recompressing an existing FLAC from a higher to a lower compression setting. * Insufficient input data (eg, very short files, < 10000 frames). * The audio data is not compressable (eg a full range white noise

Erik de Castro Lopo wrote: > INFO: Make sure you know what you're doing when using --ignore-chunk-sizes. > Improper use can cause flac to encode non-audio data as audio. > -: WARNING: skipping unknown chunk 'LIST' (use --keep-foreign-metadata to keep) > -: WARNING: 'data' chunk has non-zero size, using --ignore-chunk-sizes is probably a bad

Erik de Castro Lopo wrote: > Does that explain it? Sure. But maybe it makes sense to write "WARNING" instead of an "ERROR"? Or to compare compress ratio with 1.01 (or 1.05 or 1.1) instead of 1.0?

lvqcl wrote: > I have a couple of questions: > > 1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any pre-releases? I had not planned to do a pre-release. > 2) Do you plan to release any official binaries (flac, metaflac, maybe something else)? Nor had I planned to release binaries. The source code tarball ends up here: https://svn.xiph.org/releases/flac/ I

Erik de Castro Lopo wrote: >> It slightly improves the performance with standard encoding levels and >> 16-bit files as the 17-bit side channel can still be processed with the >> 32-bit accumulator and correctly selects the 64-bit accumulator with >> very large 16-bit partitions. >> >> This is related to commits 6f7ec60c and 187e596e. > > Sorry I

Hi all, I've been notified of a CVE to be publish against FLAC early next week. I have a patch for it and have thoroughly tested it as well as had it verified by the Google Security Team member who found it. I've been asked not to publish that patch until Tuesday. Once I publis the patch, I like to release FLAC 1.3.1 immediately and would therefore like to make sure that all the

Erik de Castro Lopo wrote: > I also notice that on sourceforge: > > https://sourceforge.net/projects/flac/files/flac-win/ > > there are still 1000+ downloads per week 1.2.1 windows binaries > with know security holes. What do people think of the idea of > disabling downloads of old, known buggy Windows binary downlaods? FLAC 1.2.1 is the last version that works on

I'd definately recommend binaries for download as suggested by lvqcl and Janne Hyv?rinen. All the fabolous work on the code base is of little use to me if I can not find binaries at the official site. Olav Sunde At 12:01 23.11.2014, Janne Hyv?rinen wrote: >On 23.11.2014 12:44, Erik de Castro Lopo wrote: >> lvqcl wrote: >>> 2) Do you plan to release any official binaries

Erik de Castro Lopo wrote: >> Sure. But maybe it makes sense to write "WARNING" instead of an "ERROR"? > > Well its an ERROR because the flac executable will exit with a non-zero > exit code, so this condition can be caught in for example a shell script. > > If its only a warning, why would the executable return non-zero? But why should it return non-zero

On 16/07/13 8:10 PM, Erik de Castro Lopo wrote: > Leigh Dyer wrote: > >> Certainly -- I've uploaded the analysis files for both the -6 and -7 >> encodes, in case you wanted to compare: >> >> http://wootangent.net/~lsd/blah/6.ana >> http://wootangent.net/~lsd/blah/7.ana >> >> The encode seems to proceed normally until 59% of the way through the

Miroslav Lichvar wrote: > On Thu, May 02, 2013 at 09:31:25PM +0200, Martijn van Beurden wrote: > > I don't know why this isn't on the changelog, but it is probably still a > > good idea to add it. This only breaks compatibility for 24-bit streams. > > (So: decoders older than 1.2.0 might not be able to decode 24-bit FLAC > > files made by libFLAC 1.2.0 or

On 14-03-13 20:02, Declan Kelly wrote: > The next official release of the FLAC command line should really have > a "-9" option for absolute maxed-out big-memory CPU-burning compression. No. If you want such things, try TAK, OptimFROG, Monkey's Audio or even LA, you'll lose hardware compatibility anyway and they do much better than FLAC will with a -9 option. FLAC 1.0

I just read some of the discussion on the list about 'bitrate peeling' and remembered an interview of Monty that I have read recently. In it he says that Vorbis uses MCDTs <sp> and that these are theoretically reversable. And now, I learn that theoretically we can use bitrate peeling to make smaller files from larger ones, and that leads to my question. Could I theoretically

Op 01-10-15 om 18:14 schreef lvqcl: > Currently libFLAC stores residual signal as 32-bit signed int. And there > are the following comments in stream_encoder.c: The residual is stored as a Golomb/Rice code. As far as I know, that is not limited to 32-bit in the format itself, only in the implementation. However, there are two residual coding methods now: rice and rice2. rice2 was added

A large test I ran on flac 1.0 recently finished so I thought I'd post the results. I took about 60 CDs, totalling around 30 gigs uncompressed, and compressed them all using all 10 of flac's default compression modes (-0 through -9). The CDs are of a wide variety of music; I think the only major genres not represented are country and rap (freudian slip). Anyway, the raw numbers: Opt

a. Intel 2.8 Ghz Core I7 (dual core, I7-4558U) in late 2013 Macbook Pro with Retina Display b. I compiled it the same way I compiled 1.2.1: ./configure -enable-static -disable-shared CFLAGS=" -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" make Am i doing something wrong? Thanks, Scott On Fri, Jul 25, 2014 at 12:54 PM, lvqcl <lvqcl.mail at gmail.com>

Suppose I have a particular version of a largish compressed archive, most likely a .tgz or .tbz2, and that a remote machine has a newer, and only slightly different, version of the same archive, where most of the content hasn't actually changed much. I might attempt to obtain a copy of the newer archive by first copying my local older copy to the newer name as a file to update from. My

Hi all, The latest version of FLAC has been releases. See: https://xiph.org/flac/index.html https://xiph.org/flac/changelog.html The source tarball and Windows binaries are available (with md5 and sha256 checksums) at: http://downloads.xiph.org/releases/flac/ The source tarball is also available at: https://sourceforge.net/projects/flac/files/flac-src/ and similarly the

Fix for padding with --replay-gain option. Ported from flac 1.2.1 maintenance branch: http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/flac/encode.c?r1=1.194&r2=1.194.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/flac/main.c?r1=1.169&r2=1.169.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH -------------- next part