similar to: Message about compression ratio with stdin input

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

lvqcl wrote: > Reproducible with the following command line: > > flac --ignore-chunk-sizes - -o out.flac < test.wav > src/flac/flac --ignore-chunk-sizes - -o a.flac < flac-test-stereo.wav I get this: flac 1.3.0, Copyright (C) 2000-2009, 2011-2013 Josh Coalson & Xiph.Org Foundation flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are

Git version of the FLAC encoder prints error message: ERROR: Compression failed (ratio 1.xyz, should be < 1.0). Please contact the developers. in the following cases: a) recompressing from FLAC 1.2.1 (sometimes) b) encoding very short wav files (around 5k samples) c) encoding white noise test signal.

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

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

Interesting figures. Some corresponding figures for flac 1.0 for a set of 404 CDs, with a total of 4357 tracks are: Opt Uncompressed Compressed Ratio Encode Time --- ------------ ----------- ------ ----------- -8 234507744748 127468328349 0.5436 n/a Admittedly, this set includes at least one country album, and has a fair share of jazz in it. The worst-case track in this set

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

<PRAISE> First, thanks to everyone for their contributions to flac. It is obviously a significant piece of work with very good performance. For me, the open-source and anti-copy-protection principals of the project make it the best choice among lossless compressors even if there are closed-source projects with marginally better compression. I firmly believe that the open-source process

Can I reduce the bitrate of an OGG file without recompressing everything? It would be useful to convert high bitrate ogg to lower bitrate ogg for portable players. Olaf <p><olaf@ kjws.com> for every kind of mail, except spam! :-) --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message

Hi, I have this idea: It can be useful to have for each frame two variables stored in bitstream that will hold information about starting and ending position of \"valid\" samples in the frame. With these additional information it will be possible to do simple editing (like cutting or concatenating two streams) without decompressing/recompressing at sample-granularity. Simple example

hi flac-dev list! I see, when compressing CD-audio tracks, I can reach up to 60% (ratio = 0.6x) of the original WAV file after compression. I was wondering if the FLAC codec could become as good as reaching 50% of the original WAV file in the future or if we are already at the (almost) maximum compression possible? thx -------------- next part -------------- An HTML attachment was scrubbed...

hi i was wondering if it's possible to tell me what the theoretical best compression ratio the flac encoder can do, because i was wondering what the future of flac will bring us. So this question is probably best addressed to Josh: can we suspect much better compression ratio in the future or is the encoder already at his *almost* peak compression level. thx in advance!

2007/5/14, Josh Coalson <xflac@yahoo.com>: > > --- Harry Sack <tranzedude@gmail.com> wrote: > > hi > > > > i was wondering if it's possible to tell me what the theoretical best > > compression ratio the flac encoder can do, because i was wondering > > what the future of flac will bring us. So this question is probably > > best addressed to

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 No one has any idea on my question of recompressing ogg files? - -- Robert Cole -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9P5QvOWbzte5wVEURAtnoAJ9d2c7ip94Qqte5AQWP2XaYZ/EQ+ACcDs9a sji3Mrw+X3ofLJ5lmyZN6oQ= =3lh9 -----END PGP SIGNATURE----- <p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project

> yes, and much more so in the encoder. the decoder is already > very fast and approaching a fundamental limit. > > the next release of FLAC will be slightly faster encoding and > decoding. Well, I hope to have a proof-of-concept FLAC-on-CUDA to run on the latest generation of NVidia cards, some time this summer. I hope this will achieve about 10x speed improvement for both

Dear list, I' m studying FLAC performance, and I'd like to know how much compression can be achieved for different audio files. 1) It seems that for nontonal sound (wideband noise), the compression factor is better than for compound sound (tones + nontonal components), which is typically 2. The reason for this result could be the following: the LPC filter is more suitable for

On Mar 14, 2013, at 13:24, Declan Kelly wrote: > I want the tightest possible compression, while remaining 100% > compatible with the subset that all known FLAC decoders can > successfully > stream or play now in cars, Hi-Fi units, "MP3 players" and cell > phones. > The out and out most widely supported lossless audio format could (and > should) have a better

R-developers, I have a binary R package built using R 2.14.1 that I would like to run on R 3.0.0. Unfortunately, the original source code is unavailable, so I cannot rebuild the package as R 3.0.0 requires. Is there a straight forward way of converting the package (.rdb, .rdx and .rds files) in the binary package from a 2.14.1 version to a 3.0.0 version without the source code (perhaps

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.