similar to: latest additions

--- Harry Sack <tranzedude@gmail.com> wrote: > 2007/7/25, Josh Coalson <xflac@yahoo.com>: > > > > --- Harry Sack <tranzedude@gmail.com> wrote: > > > 2007/7/25, Harry Sack <tranzedude@gmail.com>: > > > > > > > > Hi > > > > > > > > I have downloaded a FLAC file somewhere and when trying to > decode

Subject says it all. Visit the home page for all the info, but in a nutshell: - the winamp2 plugin has finally been fixed. - there were some format changes (that break backwards compatibility). these should be the last. the changes include a longer sync code. and a 16-bit frame CRC. - more analysis options. http://flac.sourceforge.net/ Josh

Take advantage of a 20% discount on the most recent R books from Chapman & Hall/CRC! Chapman and Hall/CRC is pleased to offer the latest books on R - all available through our website at a 20% discount to users of the software. To take advantage of this offer that is valid across the board for all of our R books, simply visit http://www.crcpress.com/, choose your titles, and insert the online

Josh Coalson <xflac@yahoo.com> wrote: > thanks for the patch. No prob :) > also, if you have miroslav's patch again a more updated version > of bitbuffer.c that would be great. I have been meaning to get > around to applying it for a long time. This is Miroslav's patch, from the mailing list post I dug up in the archives: --- orig/src/libFLAC/bitbuffer.c +++

From: "Richard W.M. Jones" <rjones@redhat.com> Headers and code related to GUID Partition Tables are moved to a common directory to allow us to share that code across multiple plugins and filters in future. This change is pure refactoring. --- Makefile.am | 1 + common/gpt/Makefile.am | 42 +++++++++++ common/gpt/efi-crc32.c

OK, after some debugging, it turns out this is related to an earlier bug (#131976 which has a temporary workaround). In other words, it will not trigger unless you are encoding more than 2 channels, and only then at large blocksizes (>32k samples). The full fix will be in 0.8 Josh --- Josh Coalson <xflac@yahoo.com> wrote: > A bug fix in 0.7 created another bug related to >

20% discount on four new R books from Chapman & Hall/CRC Chapman and Hall/CRC is pleased to announce the publication of four new books on R, all available through our website at 20% discount to users of R. To take advantage of this permanent offer, which is valid across all of our R books, simply visit http://www.crcpress.com/, choose your titles, and insert the online discount code -

On Thu, 15 Feb 2001, Josh Coalson wrote: > well, I took a look at the files. from my > knowledge of shorten there are two things it does > that flac doesn't do: > > BUT, you have stumbled on some recordings where the > LSB is 0 for much of the file. as a matter of fact, > in > the worse track (track 6) almost the entire signal in > both channels is like that.

The attached patch adds the ability to fstype to detect lvm2 physical volumes (PV's). Signed-off-by: David H?rdeman <david@2gen.com> -------------- next part -------------- diff -Nur klibc-orig/usr/kinit/fstype/fstype.c klibc/usr/kinit/fstype/fstype.c --- klibc-orig/usr/kinit/fstype/fstype.c 2006-03-22 21:28:31.000000000 +0100 +++ klibc/usr/kinit/fstype/fstype.c 2006-03-23

--- Josh Coalson <xflac@yahoo.com> wrote: > > -- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > On Tue, Dec 17, 2002 at 01:01:08PM -0800, Josh Coalson wrote: > > > --- Miroslav Lichvar <lichvarm@phoenix.inf.upol.cz> wrote: > > > > Ok, what about enabling the 3dnow function in libFLAC by > default? > > > > I think time

"Sanjay Patel" <spatel at rotateright.com> wrote: > IIUC, you want to use x86-specific bit-hacks (sbb masking) in cases like > this: > unsigned int foo(unsigned int crc) { > if (crc & 0x80000000) > crc <<= 1, crc ^= 0xEDB88320; > else > crc <<= 1; > return crc; > } To document this for x86 too: rewrite the function

Hi @ll, while clang/LLVM recognizes common bit-twiddling idioms/expressions like unsigned int rotate(unsigned int x, unsigned int n) { return (x << n) | (x >> (32 - n)); } and typically generates "rotate" machine instructions for this expression, it fails to recognize other also common bit-twiddling idioms/expressions. The standard IEEE CRC-32 for "big

Unsubscribe --- flac-request@xiph.org wrote: > Send Flac mailing list submissions to > flac@xiph.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.xiph.org/mailman/listinfo/flac > or, via email, send a message with subject or body 'help' to > flac-request@xiph.org > > You can reach the person managing the list at >

well, I took a look at the files. from my knowledge of shorten there are two things it does that flac doesn't do: 1. it estimates the mean of the signal for each block, subtracts it out and stores it separately. but this is pretty useless for the predictors that shorten uses as they are pretty insensitive to the mean (try different values of -m from 0 to whatever and note practically no

On 08.06.20 08:14, Michael S. Tsirkin wrote: > If subblock size is large (e.g. 1G) 32 bit math involving it > can overflow. Rather than try to catch all instances of that, > let's tweak block size to 64 bit. I fail to see where we could actually trigger an overflow. The reported warning looked like a false positive to me. > > It ripples through UAPI which is an ABI change,

On Wed, Nov 28, 2018 at 7:11 AM Sanjay Patel via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Thanks for reporting this and other perf opportunities. As I mentioned > before, if you could file bug reports for these, that's probably the only > way they're ever going to get fixed (unless you're planning to fix them > yourself). It's not an ideal situation, but

--- Christian Weisgerber <naddy@mips.inka.de> wrote: > Josh Coalson <xflac@yahoo.com> wrote: > > > Basically what I want is configure.in determination of > > basic machine type (intel/compatible, alpha, ppc), then within > > that (say intel) the code will detect variants like MMX, SSE, > > and use the right routines. > > Please include a way to

> > I've never come across a sample like this which is > > why I thought it wasn't useful to add that > > functionality to FLAC... maybe if this is a common > > practice I should put it in. > ... > I've > compressed around 50 albums with flac and found 1 > where the LSB is 0. Even > if it's 1 in 200, that's going to be lots of cases >

Firstly, a big thank-you to Josh for FLAC. Someone mentioned it in a post on Slashdot, so I came over to sourceforge for a look-see. This is just the sort of thing I've been looking for. Can anyone relate any general tips for using flac on Windows for the purpose of archiving cd's? If I can nail down a solid, easy-to-use process, I'm happy to write it up and contribute it to the

On Mon, Jun 08, 2020 at 08:58:31AM +0200, David Hildenbrand wrote: > On 08.06.20 08:14, Michael S. Tsirkin wrote: > > If subblock size is large (e.g. 1G) 32 bit math involving it > > can overflow. Rather than try to catch all instances of that, > > let's tweak block size to 64 bit. > > I fail to see where we could actually trigger an overflow. The reported >