similar to: packaging flac for debian

retitle 138828 flac: progress display is broken with long filenames thanks I don't think it's a gnome-terminal issue, as I've seen the same behaviour with xterm in the past. I've never bothered doing anything about it because it seems to be purely cosmetic; the operation still completes successfully. I'm forwarding this bug upstream. ----- Forwarded message from Britton Leo

Hmm, I wonder how the package search I originally did for it failed. I guess I have a couple wnpp bugs close, but no other work wasted. Britton On Thu, 22 Feb 2001, Matt Zimmerman wrote: > On Wed, Feb 21, 2001 at 05:08:56PM -0900, Britton wrote: > > > The users of debian have been without high quality lossless audio compression > > too long, I say. I am therefore packaging

Full_Name: Britton Kerin Version: docs on web OS: linux Submission from: (NULL) (216.67.49.115) This section from the introduction to R confused me (reason below): 11.7.1 Least squares One way to fit a nonlinear model is by minimizing the sum of the squared errors (SSE) or residuals. This method makes sense if the observed errors could have plausibly arisen from a normal

Hi, I have been making an RPM of FLAC to bundle with GStreamer. In order to get it working I had to make some rather hackish solutions in the SPEC file. The flac Makefile does to build into the correct directories while creating an RPM for some reason. I have attached the SPEC file I ended up with if it is of interest. Of course it didn't help me much cause it turned up we had a bug in the

hi, according to the FAQ flac supports multichannel formats. i had no luck with 1.1.4 though ( "Untitled.aif: ERROR: unsupported number channels 8 for AIFF" ), i guess that feature was added in 1.2? unfortunately, the binary for 1.2 does not run on OS X 10.4 (says libiconv is too old). i removed libiconv and reinstalled that from source, but then flac 1.2.1 just prints

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tried to do this, gcc complained a lot about undefined references. After a bit of mucking with the code, i came up with a few patches. This might be a good conversation starter. The build that i've got out of this does pass the testsuite. To enable LTO you just need to apply these (for non-W32 builds you probably only need one of the patches)

--- developers.html | 16 ++++++++-------- documentation.html | 4 ++-- documentation_bugs.html | 2 +- documentation_example_code.html | 2 +- documentation_tools.html | 2 +- download.html | 2 +- faq.html | 2 +- feeds/feed.rss | 31 +++++++++++++++++++++++++++++--

Hi, I'm developing squash (shameless plug: http://freshmeat.net/projects/squash/ ), and I've just added FLAC support. I'm going to hold off on OggFLAC support until the high level interface is in place. However, my question concerns compiling libFLAC for the strongarm. First I noticed that I could not use the files compiled by tremor, which I have already working. I suppose

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

i'm trying to build ices0.4 and vorbis-tools 1.0.1 with flac 1.1.1. Neither seems happy, hence the crossposting (sorry). ICES0.4 --- ices refuses to see the libFLAC library, even if i specify --with-flac=/usr/local/lib (or even just --with-flac=/usr/local/, as the configure script seems to look in the lib and include subdirectories of the specified path?). i get a configure error:

That's how I understand how flac.exe works with unicode under Windows: There's a flag win_utf8_io_codepage that is equal either to CP_ACP or to CP_UTF8. Initially it's equal to CP_ACP. Then flac.exe/metaflac.exe call get_utf8_argv() that do some things and sets win_utf8_io_codepage to CP_UTF8 on success. This is the only way to set this flag to CP_UTF8. The programs continue to work

Hi, And thanks for flac. There's a minor problem when compiling flac: libtool warns about mixing up shared and static libraries. Typical messages are: *** Warning: Linking the shared library libxmms-flac.la against the *** static library ../../src/plugin_common/libplugin_common.a is not portable! *** Warning: Linking the shared library libxmms-flac.la against the *** static library

On Fri, Jan 7, 2011 at 7:36 PM, Brian Willoughby <brianw at sounds.wa.com> wrote: > This thread has raised several good topics. ?It's surprising that the > FLAC-Dev list has been silent for years, and now suddenly there are several > good ideas to discuss. I'll take credit for this, toot toot toot :D > > On Jan 7, 2011, at 15:04, David Richards wrote: >>

Josh Coalson wrote: > > Good points. I imagine there should be two separate packages; > one for the command line tools, and one like flac-devel, which > has the libs and the includes. BTW in this scenario the files > that are currently in include/FLAC would go in /usr/include/FLAC > and you would do something like #include "FLAC/stream_encoder.h". > Not sure how

On Thu, Nov 21, 2002 at 01:39:40AM -0800, Josh Coalson wrote: > 1. FLAC would benefit from the increased visibility from the association. > Emmett can probably expound more upon this point. Anyway, hopefully this > will mean it's popularity will rise, not just with users but also with > developers of other tools. I agree that a relationship with Xiph.org would have a positive

thanks for the feedback, but it would really help if you supply a patch (diff -c), I didn't understand all the changes you described. someone reported a problem with src/libFLAC/include/private/lpc.h that was fixed in CVS and may fix the problem building with asm disabled http://cvs.sourceforge.net/viewcvs.py/*checkout*/flac/flac/src/libFLAC/include/private/lpc.h?rev=1.24 Josh --- Luca

Cristian Adam wrote: > On Wed, Feb 25, 2009 at 2:23 PM, Brian Willoughby <brianw at sounds.wa.com>wrote: > >> A better suggestion might be to start with libFLAC, optimize as >> needed, and then submit the optimizations back to the FLAC project >> where they will be more widely useful. >> >> But that's just my opinion. >> > > I agree. This

Here is a patch that fixes the issue. There are multiple way to fix it though. Le 14/02/2017 à 15:08, Olivier Tristan a écrit : > Hi Guys, > > The following code in CPU.c (line 155) won't link if you don't have > NASM code built even if FLAC__HAS_X86INTRIN is true as > FLAC__cpu_info_asm_ia32 don't exists and the else is compiled if there > is no dead code

Josh Coalson <xflac@yahoo.com> wrote: > That is the question I put before you all tonight :) > > (Short background, Xiph is the corp behind Vorbis and Ogg, > among other things; see http://xiph.org/about.html . I > think Emmett is here now so correct any of this if it's > wrong.) > > I've been talking a little with Emmett Plant and Monty about > this.

I feel really silly asking this, but where is read_residual_partitioned_rice > > _() ? I tried using the standard find feature on text editors for all of > the .c and .cpp files in libFLAC and libFLAC++, but nothing came up. -Mary On 7/11/06, Ralph Giles <giles@xiph.org> wrote: > > On Tue, Jul 11, 2006 at 04:17:41PM -0700, Mary Amon wrote: > > >