similar to: flac error with some aiff files?

I have a test program that loads an AIFF or WAV file with libsndfile and plays then using libao. After running around in circles for a while, I found and fixed the problem, but I'm still confused as to why the solution works. Would someone please explain this to me so I don't trip over this again later in my project? I used sf_open_fd() to get a SNDFILE* pointer and an AF_INFO

Brian Willoughby <brianw at sounds.wa.com> wrote: > Hello all, > > Is anyone here potentially up to the task of adding support for CAF > (the CoreAudio Format) into the flac command-line? ... > I've already made some recordings > that are so long that they cannot be uncompressed from FLAC to WAV or > AIFF because they would exceed 4 GB - the maximum file size for

Hello, I have written a libsndfile (http://www.mega-nerd.com/libsndfile/) file output plugin for libao. For the moment I haven't done any changes to the core of libao. However some changes could make this more useful. Before I embark on anything like this I'd like to have your opinion on a few things. --- First, what do you prefer ? 1a. Keeping the AU/WAV/RAW plugins and adding

The patch I submitted only reads AIFF files. I'm about to start the patch to write AIFF files. To do so, we need a command-line option to specify AIFF. My inclination is to add an option: -ff { raw | wav | aif } In some sense, "-ff" is silly since it probably stands for "format format". Still, I think it's better than just "-f", since the first

I know this is probably blindingly obvious, but I can't find it anywhere. Is there a way to tell the Vorbis codec what endian your samples are or do I have to do my own byte reversal. AIFF is Be's 'standard' audio file format, and its encoded big endian, not little endian even on Intel boxes. I know for decoding ov_read has an endian option, but I can't see an equaivalent for

I use Sony (previously Sonic Foundry) Sound Forge, which allows me to save audio files in .w64 (Wave 64) format to get around the 2GB .wav file limitation. W64 was invented by Sonic Foundry, and is an open format as far as I know. The only programs I know about using the .w64 format at the moment are Sound Forge and Steinberg Nuendo, although there may be others out there. With increasing

just recently I have finished implementing support for saving non-audio chunks in RIFF WAVE and AIFF with the FLAC file in application metadata blocks, and restoring them when decoding. you can read about more about it here: http://www.hydrogenaudio.org/forums/index.php?showtopic=56968 the zip file there has windows binaries; CVS HEAD has everything checked in if you need a different platform.

Hello all, Is anyone here potentially up to the task of adding support for CAF (the CoreAudio Format) into the flac command-line? This would present minimal difficulty under OSX, due to the presence of the CoreAudio API, but the real challenge would be to support CAF on Unix and Windows - everywhere that flac is now available. Although the format is rather unknown, there are some very

--- Matt Zimmerman <mdz@debian.org> wrote: > On Tue, Jul 30, 2002 at 09:04:38PM -0500, Brady Patterson wrote: > > > The patch I submitted only reads AIFF files. I'm about to start > the patch to > > write AIFF files. > > > > To do so, we need a command-line option to specify AIFF. My > inclination is to > > add an option: > > > >

Hi, sndfile-convert already converts from all these formats to FLAC, but the flac tool itself has more flac-specific options. Is it possible to use sndfile-convert to provide the input data? In any case Erik is maintaining both libsndfile and libflac, and it's unlikely he'd want to duplicate the code. If anything it'd make more sense to remove code for reading other formats from the

Hi Martijn, thank you for your answer. So the problem would be suboptimal compression due to suboptimal assumption about the input signal, right? What I do not understand is how the format of a FLAC format would be affected by supporting A-law and mu-law files as input (and thus output). Despite of suboptimal performance, is it possible to treat 8bit *-law samples as 8bit linear PCM files and

--- Brady Patterson <brady@spaceship.com> wrote: > > Brady, I would say for now, your proposal is fine. I am going > > to move flac to getopt soon... > > > > Matt, that would be cool if you wanted to take on the audiofile > > support. I have actually been waiting to ask you for that, > > waiting until I got the getopt support done, and the new > >

And more info... Screen capture of the WAV file's hex. This tells me little, but maybe someone out there knows more about this than me. http://img139.imageshack.us/my.php?image=screenshot251awavghexnd1.png Thanks again, Matthew On Feb 6, 2008 12:18 PM, Matthew Davis <zasdarq@gmail.com> wrote: > Came across another error that might help! Using flac -t I get: > > 251_A.wav:

Josh, I applied this patch and all the "make check" tests passed (but I do not have valgrind and I did not use --enable-exhaustive-tests during configure, so it isn't all the tests). Do you see anything suspicious about it? --- flac-1.1.2.oldBuild/src/flac/decode.c 2005-01-24 20:13:46.000000000 -0800 +++ flac-1.1.2/src/flac/decode.c 2006-09-06 23:36:26.000000000 -0700

I can now load and play AIFF, WAV, and OGG files using libsndfile and libao. Now I'm moving on to loading and playing files embedded in an IFF file. This is presenting a problem. Playing an AIFF embedded in an IFF works fine. Playing an OGG embedded in the same IFF fails. Specifically, it appears that sf_open_fd() can't figure out what it's being told to load. Except for

On Tue, Jul 30, 2002 at 09:04:38PM -0500, Brady Patterson wrote: > The patch I submitted only reads AIFF files. I'm about to start the patch to > write AIFF files. > > To do so, we need a command-line option to specify AIFF. My inclination is to > add an option: > > -ff { raw | wav | aif } > > In some sense, "-ff" is silly since it probably stands

How about the opposite? What I would like to see is FLAC support in libaudiofile, so applications written with libaudiofile could transparently take advantage on FLAC's compression. Ironically I guess it would still make sense to use libaudiofile in FLAC for getting input. Mmmm, cyclic dependancies... Or is that just a stupid idea? Dave On Wed, 2002-07-31 at 13:10, Matt Zimmerman wrote: >

Lots of comments throughout this one... On Jan 7, 2011, at 15:28, Declan Kelly wrote: > On Fri, Jan 07, 2011 at 02:22:51PM -0800, brianw at sounds.wa.com wrote: >> However, you should be aware that many modern producers use software >> to create their music, and when the software stores sound clips in >> MP3 format, what you end up with is music that sometimes looks like

Hello, I am currently learning the FLAC C API and had the code working with FLAC__stream_decoder_init_file. However, since I'd need the Unicode filename support, I tried _wfopen_s in combination with FLAC__stream_decoder_init_FILE, however I get a runtime crash as sonn as I call FLAC__stream_decoder_process_until_end_of_stream. The same code (partially taken from the examples) is working

So some research and experimentation I think I found the problem, but I'm not sure how to go about fixing it. If I import one of the wav files into Audacity then export them as "16 bit PCM" then they encode to flac and play fine. The files bitrates are currently at 24. If I export them from audacity as a 24 or 32 (anything higher than 16), flac fails on me. With a bitrate of 24, the