similar to: pipe and windows

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 >

I have checked in all the latest into CVS and am going to start the test suite again. if all goes well I will probably release this as beta 10. this one should have all the configure stuff working with the new assembly infrastructure. I have tried to make it as easy as possible to port routines to assembly. all that's really needed now is to write the corresponding routine for a specific

I've released FLAC 0.6. The big improvements are: - encoding speed in default mode (-6) is at least 3x faster - a new "loose mid-side" adaptive algorithm should help -1 and -5 modes - a new analyze mode for developers - a autoconf/libtool-based build system (thanks to Matt Zimmerman) - bug fixes related to pipes Check the new comparison page. FLAC has the best ratios of any open

I am trying to set up a flexible infrastructure for the assembly code. 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. I know how to do the second, but what is a good way to do the first? Linux/Cygwin/Solaris seem to support the MACHTYPE

--- smoerk <smoerk@gmx.de> wrote: > good idea, i'm always putting *.cue files to the directory with the > ripped audio files. but it would prefer one file per song and not one > big file for the whole cd. My vision of how the players should work is this: - make one album.flac with CUESHEET - player loads album.flac, sees CUESHEET, calculates CDDB id (or CDindex, or custom

--- 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 remember someone saying that compiling flac with gcc 3.0 yields a broken executable. I saw this on the Lame list that might explain the problem. I don't have a gcc 3.0 setup yet but somebody may be able to verify this... --- Alexander Leidinger <Alexander@Leidinger.net> wrote: > From: Alexander Leidinger <Alexander@Leidinger.net> > Subject: Re: [MP3 ENCODER] Lame and

I'll rearrange a little and respond: --- Mark Powell <M.S.Powell@salford.ac.uk> wrote: > Also, when flac takes input from stdin it fails to > fill in the wav size > fields correctly, whereas shorten has no problems > with this: i.e. >... > You can see it puts a data chunk size of zero in > there. > OK, this has been fixed in CVS. > Flac refuses

Hello, how good is the quality with very low bitrates like 16kbps mono. 16 kbps files compressed with lame sound awful, realaudio is much better. Will vorbis sound as good as realaudio with low bitrates? How fast is vorbis (in comparison to lame). Smoerk --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list,

> > I have checked in all the latest into CVS and am going to start the > > test suite again. if all goes well I will probably release this as > > beta 10. > > > > anyway, try it out and let me know if anything bad happens! it > > should be a short jump from beta 10 to 1.0. > > I've just checked out the latest from scratch. There is no configure

2007/9/9, Josh Coalson <xflac@yahoo.com>: > > --- Harry Sack <tranzedude@gmail.com> wrote: > > 2007/9/8, Josh Coalson <xflac@yahoo.com>: > > > > > > it actually is complicated. the libFLAC api is not suited to a > > > multithreaded design because the i/o is stream-based, not file- > > > based. flac(.exe) is the file-based wrapper

--- Jan Suhr <jan.suhr@usa.net> wrote: > It would be easier if FLAC understand the following command: "flac > *.wav *.flac" or "flac -d *.flac *.wav" > > for now I have to use some shell "tricks". > I assume you're using the DOS shell? because all unix shells I know will expand the globs first so this syntax cannot work anyway. but I know

> > > It would be easier if FLAC understand the following command: "flac *.wav > > > *.flac" or "flac -d *.flac *.wav" > > > > > > for now I have to use some shell "tricks". > > > > > I assume you're using the DOS shell? because all unix shells I know will > > expand the globs first so this syntax cannot

> > 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 >

On Fri, 25 May 2001, Josh Coalson wrote: > I have checked in all the latest into CVS and am going to start the > test suite again. if all goes well I will probably release this as > beta 10. > > anyway, try it out and let me know if anything bad happens! it > should be a short jump from beta 10 to 1.0. I've just checked out the latest from scratch. There is no configure

On Tue, 29 May 2001, Josh Coalson wrote: > > AM_INIT_AUTOMAKE(flac, 0.9) > > > > I've never had to run autoconf manually before so I'm not really sure > what > > I'm doing. > > > hmm... not sure what the syntax error is; did you run aclocal first? No. Had no idea I had to. I've gleaned from someone else's message that I should be doing

--- Harry Sack <tranzedude@gmail.com> wrote: > 2007/9/8, Josh Coalson <xflac@yahoo.com>: > > > > it actually is complicated. the libFLAC api is not suited to a > > multithreaded design because the i/o is stream-based, not file- > > based. flac(.exe) is the file-based wrapper around libFLAC that > > allows it to work on files. the way libFLAC buffers

--- Mark Powell <M.S.Powell@salford.ac.uk> wrote: > Josh, > Those speed improvements are great. Quick test on > an 365MB wav of Neil > Young's eponymous 1st album on a PIII 650E > (Coppermine) under FreeBSD 4.2: > > User Sys MB > > shorten23 0:46s 4.0 208.3 > shorten31 1:24s 5.3 208.6 > flac CVS 4:21s 7.5 199.2 > > It's getting near to be

Perhaps someone answered this but I missed it. I'm still havign this problem and can't figure this one out on my own. Does anyone have any suggestions? Thanks Anthony --- Anthony Abby <anthonyabby@yahoo.com> wrote: > Date: Sun, 29 Apr 2001 07:32:06 -0700 (PDT) > From: Anthony Abby <anthonyabby@yahoo.com> > Reply-to: anthonyabby@yahoo.com > Subject: Libpamc.so.0

wow, this is pretty cool, but I may not get to play with it for a little while. trying to have 0.9 out this weekend. but this is a good proof of concept. do you have any numbers as to how much the file size increases on average? Josh --- Matt Zimmerman <mdz@debian.org> wrote: > On Mon, Mar 26, 2001 at 11:34:04AM -0800, Josh Coalson wrote: > > > --- "smoerk@gmx.de"