search for: willoughbi

a test suite for FLAC would be great, but where do I find it? (I'm sorry if this might be obvious to everyone else, but I can't seem to find anything) Brian Willoughby wrote: > Daniel, have you looked at the test suite for FLAC? I believe that > there are test files there, or perhaps the test suite creates them on > the fly. Either way, you should be able to get some basic

Oops. I proofread my email a little too late. I corrected the example. Hopefully what I am suggesting is clear. Brian Willoughby Sound Consulting On Jun 22, 2010, at 22:15, Brian Willoughby wrote: > What you need to do is write a bitStream function. It should only > read each byte from the stream once and completely deal with all 8 > bits before reading the next byte. You

Or, I was originally thinking: rice_parameter = 0; k = partition_samples; if (k < mean) { int n = mean - k; rice_parameter += n; k <<= n; } (sorry for the hasty post) On Oct 11, 2013, at 10:34, Brian Willoughby wrote: > Hmm, maybe I'm missing something, but what about this: > > rice_parameter = 0; k = partition_samples; > int n = mean - k; > if (n >

On Dec 18, 2009, at 12:12 AM, Brian Willoughby wrote: > > On Dec 17, 2009, at 20:42, Ron Decline wrote: >> Anyway, as you and dathead2 suggested, I can just flac -d, then swap the channels on the wav with SoX, and then flac -a, I can then use metaflac to transfer the tags. Easy enough to write a script to do the work. > > > flac -a will analyze, not encode. Apart from

Harry Sack wrote: > > > 2007/3/29, Brian Willoughby <brianw@sounds.wa.com > <mailto:brianw@sounds.wa.com>>: > > There actually is no problem with 24-bit support, as I stated > earlier. So before people start chiming in with "me too" - I'd > like to request that you actually say what problem you're seeing, > along with a few

On Dec 17, 2009, at 11:02 PM, Brian Willoughby wrote: > > On Dec 17, 2009, at 19:00, Ron Decline wrote: >> On Dec 17, 2009, at 8:50 PM, dathead2 at gmail.com wrote: >>> On Dec 17, 2009, at 8:42 PM, Ron Decline <rutlecorps at gmail.com> wrote: >>> >>>> Is it possible to switch the Left / Right channel when encoding in FLAC? >>>> (I have

On Mar 6, 2011, at 01:22, Erik de Castro Lopo wrote: > Brian Willoughby wrote: >> Hopefully, libsndfile no longer uses the incorrect 0x7FFF (32767) >> factor for float to 16-bit integer conversions, because that would >> make it unacceptable for lossless file conversions. > > That is a statement of opinion rather than fact but I won't go into > that here. It is

On Oct 12, 2008, at 22:32, Paul Davis wrote: > On Sun, 2008-10-12 at 19:26 -0700, Brian Willoughby wrote: >> 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

Brian Willoughby wrote: > Hi Justin, > > Are you saying that 24-bit support does not work for you? Which > version of FLAC are you using? What platform? What kind of files are > you trying to compress? > We're using FLAC 1.1.2, and we're compressing any kinds of PCM audio. The software that we make that uses it is REAPER, www.reaper.fm. We sent some messages

When you download the full source for FLAC and read the instructions, you'll see that 'make test' will run the test suite. The instructions warn people that this can bring even a good machine to its knees, and it is not recommended for everyone to run it. I have run it because I have submitted an installer package for Mac OS X, and it seemed prudent to take the time to test

On Thu, 2007-03-29 at 12:53 -0700, Brian Willoughby wrote: > > Hello FLAC list. > > > > As far as I know 24 bit FLAC support is broken. It often doesn't > > compress the audio at all, but instead stores the chunks as verbatim > > type (although the FLAC format supports 24 bit). Perhaps this is > fixed? > > If so, do let me know. > > Hi

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

On Dec 14, 2014, at 10:02 AM, lvqcl <lvqcl.mail at gmail.com> wrote: > Currently the header of a decoded WAV file can be different to the > original WAV file because FLAC doesn't preserve 'fmt ' chunk. > > For example: create a 24-bit stereo .wav file with WAVEFORMATEXTENSIBLE > header with channel mask == 3. Encode it to .flac then decode back to .wav. > FLAC

hmm, let me ask this question, another way... which setting offer the least compression ?. Richard On Thursday 12 July 2007 3:49:07 am Brian Willoughby wrote: > Hi Rick, > > Alex already told you: All settings for FLAC give perfect quality. > No setting has any more quality than the other, because they are all > identical to the original CD. > > Brian Willoughby > Sound

No, streams should stay. Audio is NOT a file based process -- it's a stream. You can't listen to an entire song simultaneously. You organize it into files for later use, but you listen and record from a stream. Stream-based storage is practically REQUIRED for an audio codec. It's not random access, it's sequential. You can put wrappers around it to make it convenient for file

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

Ralph, The problem is that there is no clear advantage, at least in terms of multiple cores, to the approach you're asking about. In order to allow each stage of the codec to overlap, you need smart buffering between each stage. That adds code and complexity which isn't there currently. So you end up making the system do more work in the hopes that there will be some overlap.

Brian Willoughby wrote: > I do not see the need to jump to 64-bit merely to get beyond the 2 GB > limit. There are modern API that handle 32-bit unsigned file lengths > - i.e., up to 4 GB - without going to 64-bit. When we are talking about offset_t we are talking about the flac C and C++ API. Currently if we have a flac file with more than 2Gig samples it is not possible to seek

Erik de Castro Lopo wrote: > Err, thats a link to a post talking about flac's WAV reader being limited > to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed. > Due to limitations in the way WAV files are specified, no valid WAV file > can ever be over 4Gig. And most don't work over 2 GB. The solution we (Xiph) have used in other projects (opusenc,

stream_encoder.c has the following code: /* try to keep qlp coeff precision such that only 32-bit math is required for decode of <=16bps streams */ if(subframe_bps <= 16) { ... But FLAC can convert 16-bit input to 17-bit if mid-side coding is used. So, does it make sense to compare subframe_bps with 17? (The patch is attached. What do you think about it?) -------------- next part