similar to: [PATCH 0/1] opusenc support for WavPack input

Copy additional filter values from Foobar2000 as found in <http://code.google.com/p/sirens2/source/browse/trunk/libwavpack-4.32.psp/wvgain.c?r=32> to allow metaflac to perform gain analysis on high sample rate audio. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac-dev/attachments/20120107/018c821b/attachment-0001.htm

Hi, I have read this on a forum: 'FLAC supports 24-bit audio fine. My understanding is that the FLAC format also handles 32-bit ints, but the reference encoder does not implement it, and FLAC has no support for float data. WavPack handles all integer bitdepths up to 32-bit and also 32-bit floats. Both codecs handle all sampling rates.' I was wondering if there are plans to support

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

This patch adds a new option "channel-mapping" to opusenc which sets the channel mapping family used by the multistream encoder. Please let me know whether adding this option is worthwhile and whether the help string is okay. I tried to keep it short but accurate. The error message for an unimplemented channel mapping is "Error cannot create encoder: request not implemented".

"Didier Dambrin" <didid at skynet.be> wrote: ... > I like FLAC on the paper because of its metadata preservation, in that riff > tag, which is critical for my needs. Try using WavPack, http://www.wavpack.com/ This can losslessly compress 32-bit floating point WAVE-EX files, and faithfully preserves every chunk (which FLAC does not do). It is also free. Regards, Martin --

Thanks to those who sent in results for the 24 bit FLAC test I created. Results were received for Windows, Linux, and Intel Mac. All results showed the identical poor compression ratio with the given test file. This indicates that the issue is likely not related to a certain platform/compiler. I also tested FLAC with various other options like integer only and turning off ASM optimizations (to

Dear list, > Which "output file" are you referring to?? Also, your question is incompletely specified, because you do not qualify whether the input is the same when you expect the output to be the same. My question is the following: For any encoding option (e.g. -5, default), does the flac encoder produce the same byte-for-byte output regardless of the CPU? Regards, Fernando

> PS: Here is the answer of David Bryant, the developer of WavPack: "The WavPack codec is hardware independent; the standard "C" encoder will produce the same byte-for-byte output regardless of the CPU it is running on (assuming a properly working C compiler, of course)." The same is true of flac, as long as you're using the same version of the encoder, right? The same

On Fri, Aug 14, 2009 at 5:05 PM, Josh Coalson<xflac at yahoo.com> wrote: > it's unlikely flac will ever support floating-point samples natively. ?the main application for it is audio engineering, which demands easy editing and very high speed for both encoding and decoding above everything else. thats not why floating point is used. the highest current feasible bit resolution for

On Aug 8, 2009, at 23:11, Didier Dambrin wrote: > Electronic music quite often doesn't leave a computer these days. > And it > mainly consists of drums, synths & vocals/effects. Drums are often > samples > sequenced at sample (not sub-sample) accuracy, thus repeated (of > course if > the song was post-resampled, there will be sub-sample times). Good point. I

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. I agree that perhaps 32 bit float/pcm isn't entirely necessary when it comes to storing different qualities. But when wanting to preserve

Avuton Olrich wrote: > On 7/11/05, Erik de Castro Lopo <erikd-flac@mega-nerd.com> wrote: > >>and I'm thinking of adding support for FLAC in a CAF container >>as well. Is anyone else working on this? If so please let me >>know so we can agree on how FLAC should be contained with CAF. > > > I'm sorry, but what are the advantages to the different

On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote: > Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. >

Op do 25 jun. 2020 om 16:02 schreef Con Kolivas <kernel at kolivas.org>: > The idea is to actually use it for playback, not just storage, and > nothing else has the nice asymmetrical fast decompression with such > effective compression (wavpack supports 705/768 but is woefully slow > on decompression and poorly supported). Mostly the sample rates would > be multiples of the

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

Dear list, We are investigating about some state-of-the-art lossless audio codecs and their performance in terms of? rate and compression ratio. Therefore, it is very important to us to know whether a codec is hardware independent, i.e. if it produces the same output file regardless of the hardware. Could you please tell me whether FLAC is hardware independent? Thank you very much in advance.

Isn't the FLAC encoder 'tuned' for the compression of audio data at common sample rates anyway? Does it make sense to use FLAC to compress arbitrary analog data at very high sample rates as opposed to other general purpose compression algorithms? Tor Am 25.06.2020 um 14:49 schrieb Martijn van Beurden: > Op di 2 jun. 2020 om 05:59 schreef Con Kolivas <kernel at kolivas.org

Hi all, Currently I'm looking for users of the --keep-foreign-metadata feature of FLAC. There has been some improvement of this feature in FLAC 1.4.0. Since 2007 there has been a warning in FLAC that --keep-foreign-metadata is a new feature. I think removal of this warning is long overdue, but there are still some issues surrounding it. So, if there are users of this feature on the mailing

On Mar 29, 2007, at 12:44, Harry Sack wrote: > 2007/3/29, Josh Green <josh@resonance.org>: > 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. > > I also want to know if this

Not sure if this belongs here or in flac-dev. I am subscribed to both, so flop it over if fits better over there. Looking at the Changelog for FLAC 1.2.1 (17-Sep-2007), it says: "With the new --keep-foreign-metadata in flac, non-audio RIFF and AIFF chunks can be stored in FLAC files and recreated when decoding." Where can I find more detail on what is a