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
[flac-dev] PATCH: IA32 and NASM
Erik de Castro Lopo wrote: Or does it make sence to add the following code: Yes it does. The patch is attached. intrin_if_no_nasm.patch Description: Binary data ___ 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
[flac-dev] PATCH for bitmath.h
FLAC__bitmath_ilog2_wide() function is still problematic: 1) it cannot be compiled with MSVS 2) it returns correct results only when compiles with GNUC 3) it mentions LGPL which isn't good for a BSD-licensed library Here's the patch that should fix these issues. (about LGPL - CC0 change: http://lists.xiph.org/pipermail/flac-dev/2013-September/004356.html ) bitmath.patch Description: Binary data ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] PATCH: IA32 and NASM
lvqcl wrote: Erik de Castro Lopo wrote: Or does it make sence to add the following code: Yes it does. The patch is attached. Applied. Thanks. 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 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] PATCH: sse2 intrinscics code for lpc_restore_signal_...()
lvqcl wrote: The new functions are analogous to FLAC__lpc_restore_signal_asm_ia32_mmx. FLAC uses them for x86-64 arch and also for ia32 if NASM is not available. Applied, thanks. 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] PATCH for encode.c, format_input()
lvqcl wrote: MSVS profiler shows that the encoder spends too much time inside format_input() when the input is 24-bit. The attached patch increases encoding speed: FLAC -5: from 27.1 to 24.2 seconds FLAC -8: from 76.2 to 73.1 seconds (MSVS 2010, 32-bit flac.exe, 24-bit stereo input file) For GCC compiles the encoding speed remains the same. I suspect that GCC is smart enough to use strict aliasing rule to optimize the code, and MSVS doesn't even know about it. Applied, Thanks. 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] PATCH for bitmath.h
lvqcl wrote: FLAC__bitmath_ilog2_wide() function is still problematic: 1) it cannot be compiled with MSVS 2) it returns correct results only when compiles with GNUC 3) it mentions LGPL which isn't good for a BSD-licensed library Here's the patch that should fix these issues. (about LGPL - CC0 change: http://lists.xiph.org/pipermail/flac-dev/2013-September/004356.html ) Applied. Thanks. 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
