similar to: Beginner's question

2013/2/8 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Collin wrote: > >> It turns out it was an error on my part; sorry for the trouble. I misunderstood >> the format libflac was expecting my samples in. I found the wording in the >> documentation very confusing. >> >> My audio file has 2 channels and 16-bit samples, so I have to pull out each >>

Erik de Castro Lopo <mle+la <at> mega-nerd.com> writes: > > Collin wrote: > > > Has anyone encountered a similar problem, or are there any known issues that > > could explain this? > > No known issues of this kind, but I would like to see a repeatable test > case so I can investigate further. > > Cheers, > Erik It turns out it was an error

2013/2/9 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Johnny Rosenberg wrote: > >> For example, when loading an audiofile with libsndfile, all the >> samples are converted to floating point numbers, > > With libsndfile, converting to float is optional. You can just as > easily read int or short. > >> which is what I want >> anyway, but the

Ooops? I accidently sent a reply privately instead of to the list, sorry for that. Here it is again, this time hopefully to the list: ---------- Forwarded message ---------- From: Johnny Rosenberg <gurus.knugum at gmail.com> Date: 2013/4/23 Subject: Re: [flac-dev] Metaflac UTF-8 fixes To: Janne Hyv?rinen <cse at sci.fi> 2013/4/23 Janne Hyv?rinen <cse at sci.fi>: > Hopefully

2013/2/8 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Collin wrote: > >> It turns out it was an error on my part; sorry for the trouble. I >> misunderstood >> the format libflac was expecting my samples in. I found the >> wording in the >> documentation very confusing. >> >> My audio file has 2 channels and 16-bit samples, so I have to

For instance the write_callback thing: client_data ? can it be a pointer to just about anything? For instance a pointer to a two-dimensional array? Are those FLAC-WAV and WAV-FLAC examples the only examples available? What would be the best approach to read a FLAC file to an array of some kind? Passing a pointer to the array as ?client_data?? I'd like to use a two-dimensional array, but

I pulled the test directory from 2003, but everything else from 2005. The 2005 files have more ?cross-compiling? targets than the 2003 ones. I fixed the various missing files in the new 2008 projects (misc.c and one other other are gone now). The only thing you could do which would make them more compact would be to get rid of the subdirectories under each vs-version. There is no real need for

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 data is also impossible to parallelize without significantly changing the api. it would take a specialty file-based encoder using an independent frame

2013/2/10 Erik de Castro Lopo <mle+la at mega-nerd.com>: > Johnny Rosenberg wrote: > >> Anyway, if I'm allowed to ask a libsndfile question here, > > Sorry, but no, this list is for FLAC related discussion. And of course you won't waste your time replying outside this mailing list? Is there a libsndfile mailing list? Hm? yet another stupid question, of course. If

On Aug 27, 2012, at 11:37 AM, gohman at apple.com wrote: > On Aug 24, 2012, at 5:56 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > > > If we can also describe the alignment padding inserted at the end of a struct when it is placed in an array, then we can improve the current LoopIdiom pass to build more memcpys. I would think that would be attached to the struct

libFLAC limits the value of qlp_coeff_precision to make sure that 32-bit math is enough for decoding of 16-bit audio. subframe_bps can be equal to 17 for 16-bit input (for side channel). So the value of subframe_bps should be compared with 17, not 16 (see also http://git.xiph.org/?p=flac.git;a=blob;f=src/libFLAC/stream_encoder.c;hb=02591f6b4b09e7c6e26bd2ae7225ff2810b227bb#l3431 ) --------------

They are not needed since the section is defined in nasm.h. --- src/libFLAC/ia32/bitreader_asm.nasm | 4 ---- src/libFLAC/ia32/cpu_asm.nasm | 4 ---- src/libFLAC/ia32/fixed_asm.nasm | 4 ---- src/libFLAC/ia32/lpc_asm.nasm | 4 ---- src/libFLAC/ia32/stream_encoder_asm.nasm | 4 ---- 5 files changed, 20 deletions(-) diff --git

I have also asked this question on stackoverflow (http://stackoverflow.com/questions/8694676/compiling-64-bit-flac-libflac-in-os-x-lion), which you can answer if you're interested in reputation points. I am very unfamiliar with compiling C/C++ source of this size, and I'm having trouble debugging the issue. Basically, in the root folder of the FLAC bundle, even if I use the flags

As I've left Sony, I should handoff code ownership of the PS4 triple. Sony is still committed to LLVM and I look forward to continue to work with them in open source. Sony has asked that I nominate Paul Robinson to become code owner. +------------------------------------------------------------+ | Alexander M. Rosenberg <mailto:alexr at leftfield.org> | | Nobody cares what I

As you might have noticed, we’ve begun landing patches to open source the Sony PlayStation®4 system compiler. Many more are coming. I’d like to propose that I be named code owner for this platform. I already have this role internally for open source. It feels necessary to establish as part of the process to handle external contributions. ----------------------------------------- Alex Rosenberg

lvqcl wrote: >>> Win_utf8 stuff should not be included in libflac since it's only to be >>> used by the flac.exe frontend. It is not needed by other programs nor >>> would they benefit from it without doing the extra work of converting >>> their ansi filenames and functions to utf-8. >>> >>>> Version 2 of my patch attached, which fixes

> OK, that worked. > > I checked in your patch to make a static libFLAC-asm.a and > I moved @XMMS_LIBS@ to the end of ...LIBADD. Matt and Ben, > can you try the latest CVS to see if it works for you now? It doesn't work for me. Looks like libtool decided not to link libFLAC-asm.a into libFLAC. Here's the output: Making all in src gmake[1]: Entering directory

On Fri, Jul 20, 2001 at 04:17:38PM -0400, Matt Zimmerman wrote: > Maybe the easy way to get around all of this is to build a plain old .a archive > for the assembler stuff, instead of a libtool .la library. This may or may not > cause problems when linking the libFLAC shared library. I'll try it. It does work, but gives a warning: *** Warning: Linking the shared library

Janne Hyv?rinen wrote: > Win_utf8 stuff should not be included in libflac since it's only to be > used by the flac.exe frontend. It is not needed by other programs nor > would they benefit from it without doing the extra work of converting > their ansi filenames and functions to utf-8. > >> Version 2 of my patch attached, which fixes the problem for the >>

Ozkan Sezer wrote: > flac.exe built with mingw with or without the dllimport/dllexport patch > always requires libFLAC-8.dll (because flac/Makefile.am has libFLAC.la > in flac_LDADD and not libFLAC-static.la), and the patch doesn't make it > any more or any less dependent on any 'foreign' dlls: the patch doesn't > change the existent situation in that regard. If