search for: flac__fixed_compute_residual

...it. > > If there is no problem with the patch I'll push it. As I see it: FLAC 1.2.1 and 1.3.0 cannot encode snippet6.wav with -7 and -8 encoding modes. But they are able to do this with --disable-fixed-subframes option. This implies that snippet6.wav triggers a problem somewthere inside FLAC__fixed_compute_residual(data[], data_len, order, residual[]) function. And indeed, max. possible residual value is 16 times bigger than max. value in data[] array: residual[i] = data[i] - 4*data[i-1] + 6*data[i-2] - 4*data[i-3] + data[i-4] 16 == 2^4, so max. bps value for residual[] is equal to max. bps for data[]...

...tonight. I am doing my testing with an 8-bit mono sample, so that should hopefully rule out any endianness issues related to the audio data itself, and with all objects compiled using -g -O0 -DDEBUG -DFLAC_OVERFLOW_DETECT. Here is the stack trace for the crash when encoding: #0 0x200000e7304 in FLAC__fixed_compute_residual (data=0x1202b9c54, data_len=4607, order=1, residual=0x1202e6cc0) at fixed.c:165 #1 0x200000e1f44 in encoder_evaluate_fixed_subframe_ (signal=0x1202b9c50, residual=0x1202e6cc0, abs_residual=0x1202fd510, blocksize=4608, subframe_bps=8, order=1, rice_parameter=1, max_partition_order=4,...

Tests show that FLAC__fixed_compute_residual/FLAC__fixed_restore_signal are slightly faster when flac_restrict modifier is added to their arguments. (Encoding speed increase for flac -8 is about 2%. The difference is not very big yet measurable). -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed.patch...

...lem with the patch I'll push it. > > As I see it: > > FLAC 1.2.1 and 1.3.0 cannot encode snippet6.wav with -7 and -8 encoding modes. > But they are able to do this with --disable-fixed-subframes option. This > implies that snippet6.wav triggers a problem somewthere inside > FLAC__fixed_compute_residual(data[], data_len, order, residual[]) function. > > And indeed, max. possible residual value is 16 times bigger than max. value > in data[] array: > > residual[i] = data[i] - 4*data[i-1] + 6*data[i-2] - 4*data[i-3] + data[i-4] > > 16 == 2^4, so max. bps value for residual[]...

...astro Lopo wrote: >> This patch adds new SSE code: it's simpler but not faster so >> this new version is disabled by default. Maybe it will be faster >> on newer CPUs though... > > I'm a little sceptical about adding code that by default is not > being compiled. FLAC__fixed_compute_residual() has the following code: #if 1 /* OPT: may be faster with some compilers on some systems */ residual[i] = data[i] - (data[i-1] << 1) + data[i-2]; #else residual[i] = data[i] - 2*data[i-1] + data[i-2]; #endif So I thought that adding a different algorithm to calculate err1 variable won...

lvqcl wrote: > FLAC__fixed_restore_signal() is a part of flac *de*coder, so it makes > sense to test it on different architectures (ARM, MIPS?). But I have no > idea how to make it. Yes, but the code in FLAC__fixed_restore_signal() is (ignoring identifier name differences) identical to FLAC__fixed_compute_residual(), Maybe I should just publish my micro benchmarking code as part of the repo. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

...UAL_BPS 4 > > > + /* WATCHOUT: "+ bps + FLAC__MAX_EXTRA_RESIDUAL_BPS" is the maximum > > + * assumed size of the average residual magnitude */ > > + if(FLAC__bitmath_ilog2(default_partition_samples) + bps + FLAC__MAX_EXTRA_RESIDUAL_BPS < 32) { > > From FLAC__fixed_compute_residual: > residual[i] = data[i] - 4*data[i-1] + 6*data[i-2] - 4*data[i-3] + data[i-4]; > > so max(residual[i]) == 16 * max(data[j]), or: max_bps(residual[]) == 4 + max_bps(data[]). > > Am I right that it's the reason why FLAC__MAX_EXTRA_RESIDUAL_BPS is equal to 4? Not really, i...

...7:18AM +0400, lvqcl wrote: > lvqcl wrote: > > FLAC 1.2.1 and 1.3.0 cannot encode snippet6.wav with -7 and -8 encoding modes. > > But they are able to do this with --disable-fixed-subframes option. This > > implies that snippet6.wav triggers a problem somewthere inside > > FLAC__fixed_compute_residual(data[], data_len, order, residual[]) function. Interestingly, -8 -l 0 seems to avoid the encoding problem too. > > And indeed, max. possible residual value is 16 times bigger than max. value > > in data[] array: > > > > residual[i] = data[i] - 4*data[i-1] + 6*data[i-2...

...e_residual_from_qlp_coefficients_16_bit() FLAC__lpc_compute_autocorrelation() I did make a change in stream_encoder.c to better align the data passed to FLAC__lpc_compute_residual_from_qlp_coefficients(), I hope this is ok. Most occurrences of residual are replaced with residual+order as in: FLAC__fixed_compute_residual(signal+order, residual_samples, order, residual+order); ... subframe->data.fixed.residual = residual+order; The vectors in Altivec must be 16 byte aligned, and it complicates things if signal[] and residual[] are not aligned. Chris

...pc_compute_autocorrelation() > > I did make a change in stream_encoder.c to better align the data > passed > to > FLAC__lpc_compute_residual_from_qlp_coefficients(), I hope this is > ok. > Most > occurrences of residual are replaced with residual+order as in: > > FLAC__fixed_compute_residual(signal+order, residual_samples, order, > residual+order); > ... > subframe->data.fixed.residual = residual+order; > > The vectors in Altivec must be 16 byte aligned, and it complicates > things > if signal[] and residual[] are not aligned. Cool, I would appreci...

This patch adds new SSE code: it's simpler but not faster so this new version is disabled by default. Maybe it will be faster on newer CPUs though... -------------- next part -------------- A non-text attachment was scrubbed... Name: predictor_intrin.patch Type: application/octet-stream Size: 5165 bytes Desc: not available Url :

..._error_3 > 0) ? log(M_LN2 * (real)total_error_3 / (real) data_len) / M_LN2 : 0.0); + residual_bits_per_sample[4] = (real)((data_len > 0 && total_error_4 > 0) ? log(M_LN2 * (real)total_error_4 / (real) data_len) / M_LN2 : 0.0); #endif return order; @@ -152,7 +152,7 @@ void FLAC__fixed_compute_residual(const int32 data[], unsigned data_len, unsigned order, int32 residual[]) { - unsigned i; + int i; switch(order) { case 0: @@ -190,7 +190,7 @@ void FLAC__fixed_restore_signal(const int32 residual[], unsigned data_len, unsigned order, int32 data[]) { - unsigned i; + int i; switch(orde...

Matt Zimmerman <mdz@debian.org> wrote: > 0.9. As I said, I was using an 8-bit sample, Ah, that didn't quite register with me. I'm using a CD-style 44.1kHz/stereo/16-bit test file. > to avoid dealing with endian issues in the file format. I don't > know whether any of those exist or not. I don't think so. 0.9 works fine on i386 (little) and sparc (big), and

Hi all, People watching the git commits might have noticed that I have been fixing a number of issues around undefined behaviour. Why you ask? * Some forms of undefined behaviour have potential for security exploits. * Compiler writers are free to replace anything which invokes UB with a NOP or even, nothing at all. * Having large numbers of UB warnings makes it difficult (or rather time

Problems in FLAC 0.9: - On alpha, flac immediately dumps core for both encoding and decoding (FreeBSD/alpha). - The distribution Makefile.in files haven't been generated with "automake --include-deps". The resulting Makefiles aren't fully portable; in particular they break with BSD make. In the future, care should be taken to use "--include-deps". - What is