similar to: Calling libFLAC from Java

Hi Jesper, Thanks for reaching out. The links page on the FLAC website needs some pruning. I'm afraid there are a lot of dead links there. I can include your effort here as a library wrapper though: https://github.com/ietf-wg-cellar/flac-specification/wiki/Implementations Anyway, nice to see that libFLAC can be used for Java. As far as I am aware, libFLAC was only available for Java through

I am also philosophically opposed to changing the specification. That said, there's nothing wrong with adding a note to the specification about the common implementations, particularly the reference library. Then, future developers will know both the precise specification and still have the warning that they risk incompatibility by deviating from the reference implementation. I own devices

On May 24, 2011, at 12:11, David Troendle wrote: > Thanks for the tip, Brian. I did have a version that does > everything in > memory, but only had enough memory to get six threads going. > (Although my > system has 16GB, I have not taken the time to create 64-bit > libraries for > wxWidgets, TagLib, libFLAC, etc.) What's wrong with only 6 threads? Is that just 3

Have you tried decoding to memory, and encoding from that memory? This technique would avoid file I/O. If you are reluctant to allocate enough memory for the full file (and why not, with a 64-bit system?), then you could implement a FIFO. You would need a semaphore to keep track of the decoder's progress, and multithreaded coding. The decoder would pause, whenever the FIFO gets

Thanks for the tip, Brian. I did have a version that does everything in memory, but only had enough memory to get six threads going. (Although my system has 16GB, I have not taken the time to create 64-bit libraries for wxWidgets, TagLib, libFLAC, etc.) Based on the direction you are pointing me in, I assume that encoding from within the decoder is not permitted. I really like your idea of the

I am getting large, corrupted native FLAC files when trying to call the encoder from inside the decoder. The metadata in the output file is OK. Is initializing and calling an encoder from inside a libFLAC decoder write callback supported? The encoder is initialized on the first write callback. Environment is Win 7 Ult, 64-bit, VS 2008, libFLAC 1.2.1. Here is some context. The static

First, this dependency exists only on Windows. For obvious reasons such dependency cannot exist on Linux/FreeBSD/OSX/etc. Previous versions (up to 1.2.1) didn't support Unicode filenames on Windows. And then it was decided to add such support. Windows uses UTF-16, where characters have 16-bit wchar_t type. LibFLAC receives strings only via char*. So one way to add Unicode support is to add

hello all, I just joined the development team for audacity, a corss platform open source multitrack audio editor. I would like to add support for importing and exporting files in FLAC format. I was wondering if any of you could point me to some documentation about using libflac to add FLAC support to other programs? thanks, jason jason@pepas.com ps - sorry i am not subscribed to the list, so

Now that the new libFLAC interface has stabilized, I'm wondering if I should put out one more source release before 1.0? Or is it enough just to have you guys look it over? Binary compatibility should be easier to maintain now since 1) there are no structures passed or altered and 2) the constructors set reasonable defaults so that when parameters are added/ changed/deleted there should be a

Hi everyone. I'm working on a FLAC plugin for the Java Media Framework (JMF) on Mac OS X. I'm having some trouble linking to libFLAC... When I first try to link to it, it tells me the libFLAC.a TOC is out of date, so run ranlib. So then I run ranlib, and it seems to be okay, except I then get undefined symbol errors: % cc -bundle

Before I start reinventing the wheel, has anything been done or is there any work ongoing to provide a P/Invoke based interface to parts or all of libFLAC or even a native port of libFLAC to C#/.NET? Regards, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20051221/2b360697/attachment.html

This patch renames flac_internal_CreateFile_utf8() function to grabbag__CreateFile_utf8() and moves it from /src/libFLAC/windows_unicode_filenames.c into src/share/grabbag/file.c This function is not used by libFLAC anyway. After this, it should be possible to compile libFLAC as UWP. In the old code there were 3 different #if conditionals around the code that uses CreateFile_utf8(): 1) #ifdef

Hi, The GStreamer flac plugin broke due to libflac 1.1.0 and libflac 1.1.1 not being ABI/API compatible. Skimming through the archives I see that this breakage was intentional. I think it is quite common understanding that when you have a stable release of something you don't break your API, you only add to it. If you want to break the API that should be done by going to a new major number,

So far I can see three ideal solutions of this issue: 1) Make Unicode support a part of the libFLAC API. In this case there will be no need in separate -lFLAC -lwin_utf8_io options, just -lFLAC will be needed. 2) Remove the dependency between libFLAC and win_utf8_io. In this case win_utf8_io will be linked statically to 1st-party apps, like other libraries from src/share:

Hello, I hope this is the right place for this kind of question. As developper, i'm actually writing java interface to use libFLAC with JNA, to reproduce "flac -t" function, needed to validate/unvalidate flac files before sending them in our preservation system. . Everything is working fine between java and libFLAC.so. Callback are called, C API is smart with void* client_data

Hello, I just tried to compile libFLAC (using Borland C++ Builder 6 on Windows). The compilers yells at me on line 233 of libFLAC/lpc.c *(residual++) = *(data++) - (sum >> lp_quantization); --> data is const and cannot be modified Funny thing is, if data is declared: const FLAC__int32 *data instead of const FLAC__int32 data[] everything is ok. Is this a bug in my compiler, or

To avoid crash caused by an unbound LPC decoding when predictor order is larger than blocksize, the sanity check needs to be moved to the subframe decoding functions. --- src/libFLAC/stream_decoder.c | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index d13b23b..211b4db 100644 ---

> I just joined the development team for audacity, a corss platform > open source multitrack audio editor. > > I would like to add support for importing and exporting files in FLAC > format. > > I was wondering if any of you could point me to some documentation > about using libflac to add FLAC support to other programs? > (note to self... write libFLAC documentation

Josh Coalson wrote: > > For those of you using CVS, I have added a libFLAC section to the > documentation page. I'm not sure how detailed to make it but I > think it's a good start. Let me know if there's anything else > you'd like to have in there. > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/~checkout~/flac/flac/doc/documentation.html?rev=HEAD >

Hello everyone! Can we add low-level seek functions into libFLAC? I'm using libFLAC in a program where file operations can't be completed synchronously from those user callback procedures that libFLAC calls when it needs to perform read, seek, etc. So I had to modify libFLAC in a way that it doesn't call any user callbacks while performing seeking. Although I added a dirty hack for