search for: flac__window_partial_tukey

Op 13-11-14 om 17:45 schreef lvqcl: > FLAC__window_partial_tukey(): > > Np = (FLAC__int32)(p / 2.0f * N) - 1; > > and Np can be equal to -1. So later in the code > > for (; n < (end_n-Np); n++) > window[n] = 1.0f; > > libFLAC writes outside of window[] memory. That does the trick indeed. I still wonder how it is possible that...

Hi, Apparently the new presets are triggering an invalid free in some code. I was running the test suite on ARM, and it gets stuck with small blocksizes. > Testing blocksize variations... > noise8m32 (--channels=1 --bps=8 -8 -p -e -l 0 --lax > --blocksize=16 ): encode...decode...compare...OK > noise8m32 (--channels=1 --bps=8 -8 -p -e -l 1 --lax > --blocksize=16 ): encode...***

...ps=8 -8 -p -e -l 0 --lax >> --blocksize=16 ): encode...decode...compare...OK >> noise8m32 (--channels=1 --bps=8 -8 -p -e -l 1 --lax >> --blocksize=16 ): encode...*** Error in >> `/home/pi/bin/flac/src/flac/.libs/lt-flac': free(): invalid >> pointer: 0x018a41d0 *** FLAC__window_partial_tukey(): Np = (FLAC__int32)(p / 2.0f * N) - 1; and Np can be equal to -1. So later in the code for (; n < (end_n-Np); n++) window[n] = 1.0f; libFLAC writes outside of window[] memory.

...es the trick indeed. I still wonder how it is possible > that this didn't trigger anything on x86_64? Now that I've taken > a better look, there are a few other problems with that code > actually. Here's a patch to fix the issue By the way, FLAC__window_punchout_tukey() calls FLAC__window_partial_tukey(), not itself. Is it intended? If yes, then probably it's better to add a small comment about this (for future readers).

Op 14-11-14 om 17:16 schreef lvqcl: > By the way, FLAC__window_punchout_tukey() calls > FLAC__window_partial_tukey(), not itself. Is it intended? If > yes, then probably it's better to add a small comment about > this (for future readers). I feel really bad about not thoroughly checking this code before sending in a patch. I just spotted another mistake, when choosing a tukey p of 1.0 or larger,...

Hi, > If I understand this correctly, these new apodization functions only > affect compression and that files compressed with these new functions > will still decode correctly with older versions of the FLAC decoder. > > Is that right? Yes, that is correct. These functions are used to window the audiodata, but only for the predictor stage. What these new function enable,