Re: [Flac-dev] A-law and mu-law
On Nov 21, 2011, at 15:25, Conrad Parker wrote: > 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 flac sources > and just use libsndfile for that part. It would be a bad idea to remove code from the FLAC command line. As far as I know, there is nothing in libFLAC that deals with WAV or AIFF, so there is nothing to remove there. Only the command-line tool deals with external formats, and the command-line tool should not be crippled beyond what it is already. Brian Willoughby Sound Consulting ___ 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, 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 flac sources and just use libsndfile for that part. cheers, Conrad. On 21 November 2011 21:01, Brian Willoughby wrote: > > On Nov 19, 2011, at 16:42, Giulio Paci wrote: >> So the problem would be suboptimal compression due to suboptimal >> assumption about the input signal, right? > > The problem is more that FLAC should not be a collection of code to > read every possible file format in existence. That would be a > duplication of at least two other audio file format conversion > utilities, and quite bug ridden, at best. Instead, FLAC supports the > two major lossless file formats plus totally raw data (no container > or formatting besides the raw samples). Between those three options > you have everything you really need for lossless audio compression. > > The only totally new file format that would make sense as an addition > is CAF, and only because it allows larger files and is also lossless. > >> 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? > > If you were to treat *-law data as 8-bit, then you would have a > couple of problems. First of all, I don't think that FLAC supports 8- > bit. It's really rather pointless to develop lossless compression > algorithms for 8-bit audio. More importantly, reinterpreting *-law > as 8-bit linear PCM would introduce nonlinear distortion that would > affect the compression algorithms. FLAC would still be lossless, but > it probably wouldn't be able to compress distorted audio as small as > clean audio. > >> 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 think the biggest problem here is that you have two types of sound > files or audio data in your overall collection. All of the A-law and > mu-law files are not up to the same lossless recording quality as an > 8-bit AIFF, for example. Trying to shoehorn two different quality > levels of recordings into the same file format doesn't really make > much sense. You're probably better off by archiving the *-law files > with a slightly modified organization to reflect the different > quality level. > > Unless conversion to 16-bit lossless audio followed by FLAC > compression shows substantial savings in space, then you're probably > better off just leaving the *-law files as they are. > > Brian > > ___ > 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
Re: [Flac-dev] A-law and mu-law
Giulio Paci wrote: > These are good news. > Do you know if there is any patent pending for ALAC and CAF? I do not know of any pattent issues with either of these formats. CAF is a very simple container format like WAV and AIFF. It does not contain anything that could possibly be patented (ignoring how many stupid patents have in fact been granted). ALAC was recently released by Apple under the Apache license which has a 3rd clause that states: Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. Which to me seems pretty safe. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] A-law and mu-law
Thank you all for your answers. They were all useful. Il 21/11/2011 07:37, Erik de Castro Lopo ha scritto: > Giulio Paci wrote: > >> 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). > > FLAC is in maintenance mode. Good luck getting new features. > >> 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? > > Apple's CAF format supports both ALAC (Apple's lossless audio format, not > FLAC) and ALAW. > > I am currently in the process of adding CAF/ALAC support to libsndfile: > > http://www.mega-nerd.com/libsndfile/ These are good news. Do you know if there is any patent pending for ALAC and CAF? Bests, Giulio. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Bug: end-of-line in FLAC console output
It's becoming clear to me that we need to distinguish between the different aspects of FLAC software, whether it be the core library, command-line, or third-party tools. Although I use the command-line tool exclusively (plus a few of my own tools), I really don't care about bugs there or missing features. Maybe I'm being selfish, since my bugs fixes and significant design suggestions have all been implemented in the official release, so I'm kinda done with the need for change. Where my concern is focused is the core library. There I have experienced no bugs at all, and I've recorded hundreds of live musical performances that were either originally created as FLAC (SD702) or compressed to FLAC before archival. The third-party front ends tend to distribute old versions of the command line, and what's most important is that the third-party tools were never maintained by Josh. Glancing at the bug database, it would be helpful if the open bugs could be classified, particularly if, as I suspect, many of them would end up with an official status of "will not fix" or "by design." Finally, I also consider porting efforts to be separate. So, if Windows support is the only place where compile errors and bugs are appearing, then it would make more sense to me if there was a Windows porting project that is distinct from the official FLAC distribution. Brian On Nov 21, 2011, at 08:39, Declan Kelly wrote: > On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote: >> As a seasoned software developer, I've learned the hard >> way that every single change to a source code repository is a chance >> for a new or old bug to appear. I am not aware of any bugs in FLAC, >> so the lack of changes is perfect. > > The only bug I'm aware of is the end-of-line one, where the command- > line > utility's output goes one character further than it should, > resulting in > extra scrolling when the output is too long for the console. > Anyone using a FLAC front-end will not even be aware of that, and I am > guessing that most possible fixes might break any of the existing > front > end tools that depend on this behaviour. ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote: > > This will leave Apple with even less reasons to support FLAC ... > > You make some important observations, but I do not see how anything > can be done by the FLAC team about Apple's lack of support. I think that only people who work for Apple can do anything to persuade Apple to (ahem) think different about FLAC. I'm guessing there is a strong "Not Invented Here" effect at work. > As for FLAC, no news is good news. That means the code is stable and > bug free. I appreciate that, a lot. That's why I run mostly Debian or Ubuntu LTS on machines that need to be stable (but don't need to have the latest fancy stuff). Unfortunately, most people tend to prefer the latest fancy stuff (in devices and installed software) so for those people lack of change is usually seen as a bad thing. Although having said that, last time I had to install FLAC on a Windows PC (someone else's) the GUI front-end that I downloaded came with an older flac.exe than the current FLAC version at the time. > It seems that all of the recent updates have been efforts to port > FLAC to operating systems like Windows and Linux. In terms of your > comments above, Windows/Linux support does absolutely nothing to help > FLAC compete against ALAC on the OSX platform. Not directly, no... ...but most people like New Stuff as opposed to not fixing something that isn't broken. Enough to cause more interest in Apple Lossless as a supported format (outside of Apple devices) and therefore less interest in FLAC. It could even cause some music download sites to reconsider their support of FLAC. > It is indeed noteworthy that Apple has released the source for ALAC. > The power of FLAC is that it was designed for embedded systems from > the beginning, and that's why you see portable recorders like the > Sound Devices 700 Series supporting FLAC, as well as various optical > disc players (CD, DVD, etc.). One question that remains for me is > whether Apple's ALAC open source can be ported to these kinds of > embedded systems with the same ease. I wish I could afford a portable recorder from Sound Devices! They record multichannel or stereo in FLAC aswell as playing it, right? Obviously, FLAC requires much less horsepower to decode than to encode, and that's OK (for most uses) because the decode will happen more often. I can live with uncompressed recording, but when buying hardware, FLAC support is always a deciding factor. However, almost every device that can play audio (from el-cheapo DVD players, to almost every "pro" DJ or broadcast deck) is able to play MP3 files. Most of them can also play WMA and AAC (lossy), but FLAC support on mass-market devices is rare. There is such a huge variety of chipsets and other hardware elements that it's impractical to port Rockbox to them. For example, OPPO do some very nice DVD and BD players for the home theatre and audiophile markets. But only their top-range players can play FLAC files. That is according to their own website, but it may be a "hidden extra". Similarly, CD DJ decks from Pioneer and Denon seem to support every lossy compressed audio format, but not lossless. And to make it even worse, Silvio Zeppieri (Denon brand manager) commented on www.denondjforums.com (in Feb 2010) that their reason for not supporting FLAC was that hard drives are cheap now, so just use WAV for "lossless" instead, as it would cost Denon too much to develop FLAC support. FolderPlay (app for Nokia S60) is what I listen to music with on the move every day (mostly FLAC, some MP3) and the developer told me that it took him half a day to add FLAC support. Whereas Denon were afraid that the DJ features (scratch, loop in/out points, etc) that are already possible on Denon hardware in WAV, will cost them too much development time to support in FLAC. What impressed me most about the discussion on www.denondjforums.com wasn't the overall defeatist attitude from a Denon manager (he said "no direct FLAC sales" in Feb 2010), but that most of the other people on the forum agreed that hard drives are so cheap that lossless has no real advantage: digital DJs should either use MP3s (not caring about sound quality) or WAV (not caring about storage space). And now we find ourselves in a world where hard drives are suddenly not cheap anymore... -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[Flac-dev] Bug: end-of-line in FLAC console output
On Wed, Nov 16, 2011 at 03:36:12PM -0800, bri...@sounds.wa.com wrote: > As a seasoned software developer, I've learned the hard > way that every single change to a source code repository is a chance > for a new or old bug to appear. I am not aware of any bugs in FLAC, > so the lack of changes is perfect. The only bug I'm aware of is the end-of-line one, where the command-line utility's output goes one character further than it should, resulting in extra scrolling when the output is too long for the console. Anyone using a FLAC front-end will not even be aware of that, and I am guessing that most possible fixes might break any of the existing front end tools that depend on this behaviour. -- -Dec. --- "Mosaic is going to be on every computer in the world." - Marc Andreessen, 1994 ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] A-law and mu-law
On Nov 19, 2011, at 16:42, Giulio Paci wrote: > So the problem would be suboptimal compression due to suboptimal > assumption about the input signal, right? The problem is more that FLAC should not be a collection of code to read every possible file format in existence. That would be a duplication of at least two other audio file format conversion utilities, and quite bug ridden, at best. Instead, FLAC supports the two major lossless file formats plus totally raw data (no container or formatting besides the raw samples). Between those three options you have everything you really need for lossless audio compression. The only totally new file format that would make sense as an addition is CAF, and only because it allows larger files and is also lossless. > 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? If you were to treat *-law data as 8-bit, then you would have a couple of problems. First of all, I don't think that FLAC supports 8- bit. It's really rather pointless to develop lossless compression algorithms for 8-bit audio. More importantly, reinterpreting *-law as 8-bit linear PCM would introduce nonlinear distortion that would affect the compression algorithms. FLAC would still be lossless, but it probably wouldn't be able to compress distorted audio as small as clean audio. > 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 think the biggest problem here is that you have two types of sound files or audio data in your overall collection. All of the A-law and mu-law files are not up to the same lossless recording quality as an 8-bit AIFF, for example. Trying to shoehorn two different quality levels of recordings into the same file format doesn't really make much sense. You're probably better off by archiving the *-law files with a slightly modified organization to reflect the different quality level. Unless conversion to 16-bit lossless audio followed by FLAC compression shows substantial savings in space, then you're probably better off just leaving the *-law files as they are. Brian ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [Flac-dev] Git branch with compiling fixes for win32
On Thu, Nov 10, 2011 at 09:58:03AM +1100, Erik de Castro Lopo wrote: > If anyone else has Flac patches that they would like to > see commited to the Xiph Git repo, now would be a good time > to speak up. I'd like to see the following patch included. It's not trivial, but I think it's very well tested after those years. http://www.mail-archive.com/flac-dev@xiph.org/msg00914.html An updated version of the patch which includes some other optimizations is here. http://pkgs.fedoraproject.org/gitweb/?p=flac.git;a=tree There are other patches which I think you might find useful: -asm, -gcc43 and -hidesyms. I can prepare proper git patches, if interested. Thanks, -- Miroslav Lichvar ___ Flac-dev mailing list Flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
