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.
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
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 <erikd at 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 <erikd at 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/