Re: [flac-dev] Compression failed message
On Feb 1, 2014, at 00:06, lvqcl wrote: 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 exit code? The input files are valid, all calculations are valid, but FLAC returns an error... IMHO it's counter-intuitive: I can't find another lossless encoder or general-purpose file archiver that works in the same way. It makes sense to have the option to return non-zero when the compression fails to compress. As Erik pointed out, a script could use the return code to decide to delete the larger FLAC output file and keep the original input file since it is smaller (and equally lossless). However, I agree that it is rather strange to return non-zero by default, requiring a command-line option to defeat. I would expect it to be the reverse: off by default, and enabling non-zero on larger files via command-line option. Brian Willoughby Sound Consulting ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Compression failed message
Brian Willoughby wrote: It makes sense to have the option to return non-zero when the compression fails to compress. As Erik pointed out, a script could use the return code to decide to delete the larger FLAC output file and keep the original input file since it is smaller (and equally lossless). However, I agree that it is rather strange to return non-zero by default, requiring a command-line option to defeat. I would expect it to be the reverse: off by default, and enabling non-zero on larger files via command-line option. I agree, thanks for the suggestions. Just pushed the following two commits. Cheers, Erik commit 37a97a5992f22710dfef773279e0922a25ac15de Author: Erik de Castro Lopo er...@mega-nerd.com Date: Sat Feb 1 19:42:34 2014 +1100 src/flac/encode.c : Improve message when compression fails. As suggested by Brian Willoughby this is not an ERROR but a FAILURE. Also list a couple of possible causes of this failure and remove the suggestion to contact the developers. commit 48133110318a7a067ebb70d732e9364fdc255d3e Author: Erik de Castro Lopo er...@mega-nerd.com Date: Sat Feb 1 19:45:33 2014 +1100 src/flac/main.c : Change the default beahviour when compression fails. Previously the flac executable would return a non-zero exit code when the output file was bigger than the input file and this could be disabled with the --no-error-on-compression-fail option. New beaviour is to print the failure message but return a zero exit code in the above situation, and only return a non-zero exit code with the --error--on-compression-fail option. The --no-error-on-compression-fail command line option has been retained. -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Compression failed message
On Sat, 2014-02-01 at 20:27 +1100, Erik de Castro Lopo wrote: only return a non-zero exit code with the --error--on-compression-fail option. The --no-error-on-compression-fail command line option has been retained. Extra dash in the option (error--on), but it doesn't seem to be the case in the actual commit, so I'm just sending this to warn future readers of the mailing list. https://git.xiph.org/?p=flac.git;a=blobdiff;f=src/flac/main.c;h=f404b3ebad30bb7ca5b8a5877e431bc0225e9876;hp=b19abb8a632f3d75368fe4ed276d09707f09ec51;hb=48133110318a7a067ebb70d732e9364fdc255d3e;hpb=37a97a5992f22710dfef773279e0922a25ac15de ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] 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. in the following cases: a) recompressing from FLAC 1.2.1 (sometimes) Yes, if the file was encoded with say -8 in 1.2.1 and you are re-encoding to something less then the output file is likley to be bigger. b) encoding very short wav files (around 5k samples) In this case, flac simply isn't given enough data to find redundancy required to actually make the file smaler. c) encoding white noise test signal. In this case, flac splits the file into blocks, tries to encode each block, files that each block cannot be compressed (information content is too high) and adds it to the output as a verbatim block. However each verbatim block has a block header so the output file is bigger than the input. Does that explain it? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Compression failed message
lvqcl 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? Or to compare compress ratio with 1.01 (or 1.05 or 1.1) instead of 1.0? As soon as the output file is the same size of bigger than the input, the encoding process is no longer providing compression. I think checking against 1.0 is in fact the correct behaviour. There is a --no-error-on-compression-fail command line option. Its documented in the HTML docs I've just added it to the --help output. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Compression failed message
On Jan 31, 2014, at 23:06, Erik de Castro Lopo wrote: lvqcl 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? I think a more appropriate term would be FAILURE, as in COMPRESSION FAILURE, because the compression failed to make the file smaller. Error implies that the program is not working the way that it is supposed to, especially when it suggests contacting the developers to correct the problem. There is nothing to be done with a lossless algorithm that cannot guarantee it will always compress any data that might be given to it. It is not an error when that algorithm fails to losslessly compress a particular set of data. It's simply a mathematical fact. Or to compare compress ratio with 1.01 (or 1.05 or 1.1) instead of 1.0? As soon as the output file is the same size of bigger than the input, the encoding process is no longer providing compression. I think checking against 1.0 is in fact the correct behaviour. There is a --no-error-on-compression-fail command line option. Its documented in the HTML docs I've just added it to the --help output. Ah, there you see that fail is the terminology used in the option. I suggest replacing ERROR with FAILURE, and removing the comments about contacting the developers. Brian Willoughby ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] compression
hi can we expect much better compression (like the step to v. 1.2.x) in future versions of the flac encoder or are we at maximum compression level now? thx ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] compression ratio
-- Boris Shingarov [EMAIL PROTECTED] wrote: 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 encoding and decoding. cool, keep us posted. I have wanted to experiment with this but have had no time for it. Josh Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s user panel and lay it on us. http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] compression ratio
2007/5/14, Josh Coalson [EMAIL PROTECTED]: --- Harry Sack [EMAIL PROTECTED] 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 Josh: can we suspect much better compression ratio in the future or is the encoder already at his *almost* peak compression level. I think you're talking about average compression ratio because it depends on the particular sample. to make significant improvements (3%) would require changes to the format that wouldn't work with older decoders, which I don't plan on ever doing. i think that's a very good decision! if you look at the comparison here: http://flac.sourceforge.net/comparison.html you will see that FLAC is already within 3-4% of the most aggresive codecs. so in the future we can expect mostly speed improvements for encoder/decoder? Thanks Josh Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] compression ratio
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! ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
