Re: [Flac-dev] Git branch with compiling fixes for win32
Well the memory leak I mentioned in my previous message for one. But there are plenty more listed here: http://sourceforge.net/tracker/?atid=113478group_id=13478func=browse and here: http://sourceforge.net/tracker/?atid=313478group_id=13478func=browse Admittedly I haven't read all of those, maybe some are invalid or actually feature requests, but surely some more actual, valid bugs are listed there as well. So I would be happy if (after 2 years) someone would take care of a couple of open reports. At least those where users have already submitted patches to fix them (after reviewing the patch of course). --- On Sat, 11/19/11, Brian Willoughby bri...@sounds.wa.com wrote: From: Brian Willoughby bri...@sounds.wa.com Subject: Re: [Flac-dev] Git branch with compiling fixes for win32 To: Bastiaan Timmer basjetim...@yahoo.com Cc: flac-dev@xiph.org Date: Saturday, November 19, 2011, 4:48 AM What bugs? On Nov 18, 2011, at 04:16, Bastiaan Timmer wrote: It's good to see some updates to the FLAC project after so much time! Will there be any timeline for a bugfix-release? ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] A-law and mu-law
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 write down the original format information in the output while decoding? For my needs converting them to 16bit linear PCM is an option, but I will need to keep track of the original format outside the file, which is something that I would prefer to avoid. I would prefer to avoid having multiple file format around (I mean containers format here) if possible. Do you know of any container that supports both flac and *-law streams? Thank you again. Bests, Giulio. Il 18/11/2011 19:13, Martijn van Beurden ha scritto: Because u-law and a-law are non-linear algorithms and the mathematics of FLAC (and AFAIK all lossless encoders) are build for linear PCM. Adding these formats would change the FLAC format altogether, decoders are not made to work with it (they can only output plain PCM) Best option would be converting these files to 16-bit plain WAV and compressing, but I guess files won't be much smaller that way. IMO best is to keep them as they are. Op 18-11-11 12:34, Giulio Paci schreef: Hi to all! I have a database of audio files that I want to losslessly compress. Unfortunately I have several 8bit A-law and mu-law files in the database and I see from here http://flac.sourceforge.net/documentation_tools_flac.html that they are not supported by the reference flac encoder/decoder. Is there a reason for this? Would it be possible to add support for these files in the reference encoder? Bests, Giulio. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
