Erik de Castro Lopo wrote: > There should be some indication of why in the git history.
http://git.xiph.org/?p=flac.git;a=commitdiff;h=27846708fe6271e5e3965a4bbad99baa1ca24c49 Now I remember a discussion about a bug in -p switch: the old code substracts lpc_order instead of FLAC__bitmath_ilog2(lpc_order), and this commit fixes this. It seems that the logic in process_subframe_() and in evaluate_lpc_subframe_() is the same, so the constants in the conditions should be the same: either both equal to 16, or both equal to 17. I built two flac executables, the 1st is from current git head, the 2nd - with my patch applied. Then I took a 16-bit WAV file and compressed it with both encoders. Standard compression levels (-0...-8): no difference (the resulting files are bit-identical). -p option: no difference (the resulting files are bit-identical). -q N option (N = 13...15): the 2nd encoder produces slightly smaller files. -l N --lax option (N = 16...31): again, the 2nd encoder produces slightly smaller files. About decoding speed: the difference isn't very big. Except for "-l N --lax" option and 32-bit decoder: the files created by the 2nd encoder have noticeably faster decompression speed. So it seems that my patch is slightly beneficial for those who use non-standard encoding presets. Especially when they use non-Subset encoding options. _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
