similar to: Changelog: improved decoding

Erik de Castro Lopo wrote: > The think in and ideal world we would a: > > * Make it work correctly FLAC__BYTES_PER_WORD == 8 and compare the performance > with FLAC__BYTES_PER_WORD == 4. > * If there is an statistically measurable performance, keep it, otherwise > remove the FLAC__BYTES_PER_WORD == 8 code all together. I'll try to do it, but I don't have a deep

Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > but I'd rather see the real seeking bug fixed instead I think I might have a fix, but it touches quite a bit of code, so it'll take some time. I think the problem is that because bogus headers might pop up in the stream of which the CRC checks out, the whole frame is decoded to validate that a frame is correct. The bogus header

On 12/6/16, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > MauritsVB wrote: > >> I noticed you’ve started compiling the changelog for 1.3.2. > > I had sort of hoped I'd finished :). Seems I was wrong! > >> I have kept track of some of the bigger changes since 1.3.1 although >> admittedly haven’t been on top of it this year. Perhaps some of these

Hi all, Sorry for bringing this up this short before the release, but I noticed something rather strange. I was doing some more exotic checks on the last pre-release when I tried test_streams.sh with FLAC 1.3.0 encoding and an older version (1.1.0 or something like that) decoding. This failed for 24-bit samples and I wondered why. After quite some tests and hex-editors, I found out this is

Hi all, It sees that the most serious bug in the flac bug tracker: https://sourceforge.net/p/flac/bugs/413/ has been fixed in git. This fix alone is worth a new release so its time to work towards one. Things I need to do for this new release: * Deal with all current patches on the mailing list. * Review all bugs reported against 1.3.0 on the sf.net. * Testing and coordination of testing

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

Miroslav Lichvar wrote: > On Thu, May 02, 2013 at 09:31:25PM +0200, Martijn van Beurden wrote: > > I don't know why this isn't on the changelog, but it is probably still a > > good idea to add it. This only breaks compatibility for 24-bit streams. > > (So: decoders older than 1.2.0 might not be able to decode 24-bit FLAC > > files made by libFLAC 1.2.0 or

Martijn van Beurden wrote: > op 25-07-14 19:32, Scott Brown schreef: > > ./configure -enable-static -disable-shared CFLAGS=" -isysroot > > /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6" > > make > > Well, the use of CFLAGS 'disables' the -O3 and unroll-loops > optimisation. I'm quite sure that's the culprit. Add -O3 to your

Martijn van Beurden wrote: > You've exposed at least two very serious FLAC bugs, > namely a malfunctioning RICE2-partition encoder and a bug concerning > choosing verbatim frames over fixed/lpc frames. The second, not choosing verbatim frames over fixed/lpc frames is almost certainly a direct result of the first problem. The fix was changing one local variable from FLAC_uint32 to

Miroslav Lichvar wrote: > I think it would be interesting to know how common are such streams. I > patched flac to print a warning on decoding or testing when this is > detected, but didn't find any files with this problem in my (small) > music collection. > > If someone has a large collection and some cycles to spare, can you please > consider compiling flac from git

lvqcl wrote: > I have a couple of questions: > > 1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any pre-releases? I had not planned to do a pre-release. > 2) Do you plan to release any official binaries (flac, metaflac, maybe something else)? Nor had I planned to release binaries. The source code tarball ends up here: https://svn.xiph.org/releases/flac/ I

On 31.5.2013 13:04, Miroslav Lichvar wrote: > On Wed, May 29, 2013 at 04:08:57PM +0200, Martijn van Beurden wrote: >> I was surprised to see that the Windows compile on wine actually >> outperformed the native Linux one. Probably GCC 4.6 optimized a little >> better or something very weird is going on in wine, I don't know. The >> assembly optimizations work very

Hi all, I thought it was a good idea to get an overview of the developments since the release of 1.3.0, so here are a few graphs. The first was compiled with GCC 4.8, the second was compiled with MSVC 2013. Both were tested on a Kubuntu 14.04 machine, with an Intel Core 2 Duo T9600 (SSE support up to "version" 4.1), the MSVC compiles were run through wine, as I don't think

On Fri, Jun 20, 2014 at 01:21:03PM +0400, lvqcl wrote: > Miroslav Lichvar ?????: > > > +/* > > + * This is used to avoid overflow with unusual signals in 32-bit > > + * accumulator in the *precompute_partition_info_sums_* functions. > > + */ > > +#define FLAC__MAX_EXTRA_RESIDUAL_BPS 4 > > > + /* WATCHOUT: "+ bps +

As we?re talking 1.3.1 release, I?ve been keeping track of a couple of changes that I feel should be included in the changelog and that I might as well share here. The things between brackets are just to refresh memories, I?d leave them out of the actual changelog. * Improved efficiency of 24 bit decoding. (https://git.xiph.org/?p=flac.git;a=commit;h=ea0d5ddadc6902e873983c89f473130b3bb6625f) *

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

On 28-05-13 20:09, Janne Hyv?rinen wrote: > On Windows the 32-bit NASM enabled compiles are always fastest. If you > can run 32-bit code on your Linux box you should compile with assembly > optimizations. That depends on the way you define speed. For decoding this doesn't seem to be true. I reran my tests, it took a little longer because I couldn't believe the results I got.

I tried to use new command-line behavior. When i do 'flac -d -c -fb foo.flac', it gives to stdout wav data instead of big endian raw data as i expected, but 'flac -d -fr -fb -c' works fine. I think -d -fb should implied -fr. And when i give it multiple files like 'flac -d -c -fr -fb foo1.flac foo2.flac', it decode only first file. -- Miroslav Lichvar

Hi, This patch improves compression a very tiny bit on average, but up to 0.1 percentage point for classical music. I haven't found any tracks that show worsening compression with this patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-LPC-order-guess.patch Type: text/x-patch Size: 0 bytes Desc: not available Url :

Hi all, The past few weeks I've been busy comparing lossless audio codecs to update the comparison.html page on the FLAC website (and because I wrote a comparison for Hydrogenaudio in the past) and its ready now. Because the patch is pretty large, I've placed it here: http://www.icer.nl/misc_stuff/update-comparison-and-fix-IE-news.patch.zip The reason to do this is because the