Joshua Haberman wrote:> The most interesting questions to me are ones you didn't address: > > 1. Will Ogg FLAC become the default manifestation of the FLAC codec? > If not, why not? What does Ogg not offer that makes it worth having > two different file formats of the same codec floating around?Related to 2...> 2. Will FLAC be incorporated into the Ogg project to such an extent > that there could be one set of libraries and one set of commandline > tools for both FLAC and Vorbis? This would be so incredibly useful.This might be also a problem. Are FLAC and Vorbis similar codec ? No. Do they need the same codec API ? Yes. Can they be used in OGG ? Yes. Can they be used in other containers (MCF?) ? They should Do the current Xiph API allow to put Vorbis in other containers ? I don't know. Do you want the FLAC API to be tied to the OGG container ? I don't think so.> As an application author (Audacity), having to write, test, and debug > an extra set of import/export routines is a significant pain, and > it would be so great to have to write only one set that would support > both Vorbis and FLAC. As a user who has encoded a significant amount > of music into the FLAC format, I feel like a second-class user since > many applications now support Vorbis but very few support FLAC.This is interresting. The UCI project is exactly for you. http://uci.sf.net/ It is still in early stage but with some more support (we already try to help Alex as much as we can) it could solve your problem and also for many other people ! The same codec API on all OS. I hope Xiph will consider that initiative too !> If encoding/decoding/metadata operations could be accessed from a > single API, this would be a great boon to seeing FLAC supported in > many more applications. BTW, why is metadata implemented as part > of each codec and not as part of Ogg?
On 21 Nov 2002 at 1:39, Josh Coalson wrote:> 2. The core libraries would become BSD-licensed. I've been really > 50/50 on this ever since I submitted the question to Slashdot > (see http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ).Interesting thead. I think your issues are with software developers. The hardware guys are using the decoder, and they have no incentive to make do something bizarre that would make it incompatible with what the core encoder implementation outputs. But in thinking about the software end, I think back to the ARC vs. ZIP. If a particular implementation becomes very popular, the author would have plenty of incentive to develop extensions to the encoder that might break other people's decoder implementations. Are file extensions copyrightable? If they are, maybe you can copyright the extension for FLAC files to insure that anything claiming to be a FLAC file is compatible with the core libraries. Incompatible extentions must be called something else.
En r?ponse ? earldunovant@earthlink.net:> On 21 Nov 2002 at 1:39, Josh Coalson wrote: > > > 2. The core libraries would become BSD-licensed. I've been really > > 50/50 on this ever since I submitted the question to Slashdot > > (see http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ). > > Interesting thead. I think your issues are with software developers. The > > hardware guys are using the decoder, and they have no incentive to > make do something bizarre that would make it incompatible with what > the core encoder implementation outputs. But in thinking about the > software end, I think back to the ARC vs. ZIP. If a particular > implementation becomes very popular, the author would have plenty of > incentive to develop extensions to the encoder that might break other > people's decoder implementations. > > Are file extensions copyrightable? If they are, maybe you can copyright > > the extension for FLAC files to insure that anything claiming to be a > FLAC file is compatible with the core libraries. Incompatible extentions > must be called something else.We actually have the same concern with the MCF format (see http://mcf.sf.net/). We want to make an open and standard file format for multimedia. And we definitely would like some hardware support in the future. But being open (the code as well) make any minor changes possible and so incompatible formats appearing, and claiming they are MCF. To avoid that, the only solution we have found so far is to create a certification program and a logo. Only applications/hardware that pass a few tests on the standard would be allowed to use the logo.
xflac@yahoo.com said:> That is the question I put before you all tonight :)As a user of both projects (and donor to xiph.org), I think it's a great idea. Jason
Josh Coalson <xflac@yahoo.com> wrote:> That is the question I put before you all tonight :) > > (Short background, Xiph is the corp behind Vorbis and Ogg, > among other things; see http://xiph.org/about.html . I > think Emmett is here now so correct any of this if it's > wrong.) > > I've been talking a little with Emmett Plant and Monty about > this. If it were to happen, it would mean the following: > > 1. FLAC would benefit from the increased visibility from the > association. Emmett can probably expound more upon this point. > Anyway, hopefully this will mean it's popularity will rise, > not just with users but also with developers of other tools. > > 2. The core libraries would become BSD-licensed. I've been really > 50/50 on this ever since I submitted the question to Slashdot > (see http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ). > Now that WMA lossless is out it seems like less of an issue but > I will still need to get permission from some of you, those that > have contributed legally-significant (in the U.S. I think that > means >10 lines of) code to libFLAC. Only the codec libraries > need to be BSD; the command-line tools and plugins would remain > GPL. > > 3. Operations would move from Sourceforge to Xiph. There are > pluses and minuses, actually not so much minuses as unknowns. > > These are the main changes that would happen. So I ask everyone, > especially libFLAC contributors, what do you think?The most interesting questions to me are ones you didn't address: 1. Will Ogg FLAC become the default manifestation of the FLAC codec? If not, why not? What does Ogg not offer that makes it worth having two different file formats of the same codec floating around? 2. Will FLAC be incorporated into the Ogg project to such an extent that there could be one set of libraries and one set of commandline tools for both FLAC and Vorbis? This would be so incredibly useful. As an application author (Audacity), having to write, test, and debug an extra set of import/export routines is a significant pain, and it would be so great to have to write only one set that would support both Vorbis and FLAC. As a user who has encoded a significant amount of music into the FLAC format, I feel like a second-class user since many applications now support Vorbis but very few support FLAC. If encoding/decoding/metadata operations could be accessed from a single API, this would be a great boon to seeing FLAC supported in many more applications. BTW, why is metadata implemented as part of each codec and not as part of Ogg? 3. Is there a way to convert FLAC files to Ogg FLAC? I am very excited about the possibility of FLAC joining Xiph, I think it would be a great opportunity to increase the acceptance of FLAC and make Xiph stronger. A different Josh -- "If we ever meet up with aliens from some other world, they will probably use the equivalent of radians, too." -- Eugene Hecht, _Physics: Calculus_
I'm kind of swamped today so I'll answer what I can get away with until tonight: --- Joshua Haberman <joshua@haberman.com> wrote:> The most interesting questions to me are ones you didn't address: > > 1. Will Ogg FLAC become the default manifestation of the FLAC codec? > If not, why not? What does Ogg not offer that makes it worth having > two different file formats of the same codec floating around?I'm hesitant to make that decision myself, I'd rather let users converge on something.> 2. Will FLAC be incorporated into the Ogg project to such an extent > that there could be one set of libraries and one set of commandline > tools for both FLAC and Vorbis? This would be so incredibly useful.Without actually promising it :) I would say yes. It sounds like Monty et al. is/are doing work to unify multiple codecs under a larger Ogg interface and have everything just work. It is all coming together now that more codecs have entered into the mix (Theora, Speex, FLAC).> If encoding/decoding/metadata operations could be accessed from a > single API, this would be a great boon to seeing FLAC supported in > many more applications. BTW, why is metadata implemented as part > of each codec and not as part of Ogg?That's one for Monty. Probably the answer is "it's too hard to come up with a spec that will satisfy even a majority given that Ogg can contain anything". I predict most metadata will remain specialized, perhaps with the exception of Vorbis comments since those are implemented in Vorbis, FLAC, and I think also Speex.> 3. Is there a way to convert FLAC files to Ogg FLAC?Not without decoding. If I had it to do over again I might have done it differently, but in native FLAC you can not find the frame boundaries without decoding. This reduces the container overhead but it's one of the drawbacks. I am working on a transcoding interface that will be able to at least do this without writing out to disk. Ogg FLAC to raw FLAC however is trivial as it just involves stripping the Ogg container off and concatenating the contents. Josh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
On Thu, Nov 21, 2002 at 01:39:40AM -0800, Josh Coalson wrote:> 2. The core libraries would become BSD-licensed. I've been really > 50/50 on this ever since I submitted the question to Slashdot > (see http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ). > Now that WMA lossless is out it seems like less of an issue but > I will still need to get permission from some of you, those that > have contributed legally-significant (in the U.S. I think that > means >10 lines of) code to libFLAC. Only the codec libraries > need to be BSD; the command-line tools and plugins would remain > GPL.If it is going to happen, you will get my permission.> > 3. Operations would move from Sourceforge to Xiph. There are > pluses and minuses, actually not so much minuses as unknowns. > > These are the main changes that would happen. So I ask everyone, > especially libFLAC contributors, what do you think?I think it is a good idea. -- Miroslav Lichvar
On Thu, Nov 21, 2002 at 01:39:40AM -0800, Josh Coalson wrote:> 1. FLAC would benefit from the increased visibility from the association. > Emmett can probably expound more upon this point. Anyway, hopefully this > will mean it's popularity will rise, not just with users but also with > developers of other tools.I agree that a relationship with Xiph.org would have a positive impact on both communities, for both developers and users.> 2. The core libraries would become BSD-licensed. I've been really 50/50 > on this ever since I submitted the question to Slashdot (see > http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ). Now that WMA > lossless is out it seems like less of an issue but I will still need to > get permission from some of you, those that have contributed > legally-significant (in the U.S. I think that means >10 lines of) code to > libFLAC. Only the codec libraries need to be BSD; the command-line tools > and plugins would remain GPL.BSD licensing has been demonstrated to work in practice, for similar applications, by a number of high-profile projects, including those associated with Xiph.org. I believe that in these situations, the freedom and continued viability of the software is ensured not by legal restrictions, but by recognized leadership in a community. Xiph.org is a strong ally in that area, with a thriving and well-recognized community. In the end, this is, by and large, your personal decision, as the primary copyright holder. Either way, I have confidence in the continued viability of FLAC.> 3. Operations would move from Sourceforge to Xiph. There are pluses and > minuses, actually not so much minuses as unknowns.I see this as a minor item; software projects move from place to place all the time. Assuming that sourceforge is willing to help to provide a smooth transition, this should be painless.> These are the main changes that would happen. So I ask everyone, > especially libFLAC contributors, what do you think?I can foresee no obvious negative consequences, and a few tangible benefits. Overall, I would say that it seems like a beneficial course of action, though not to the extent that I would consider it a failure if it were not taken due to other concerns. -- - mdz
That is the question I put before you all tonight :) (Short background, Xiph is the corp behind Vorbis and Ogg, among other things; see http://xiph.org/about.html . I think Emmett is here now so correct any of this if it's wrong.) I've been talking a little with Emmett Plant and Monty about this. If it were to happen, it would mean the following: 1. FLAC would benefit from the increased visibility from the association. Emmett can probably expound more upon this point. Anyway, hopefully this will mean it's popularity will rise, not just with users but also with developers of other tools. 2. The core libraries would become BSD-licensed. I've been really 50/50 on this ever since I submitted the question to Slashdot (see http://ask.slashdot.org/article.pl?sid=01/11/27/1650256 ). Now that WMA lossless is out it seems like less of an issue but I will still need to get permission from some of you, those that have contributed legally-significant (in the U.S. I think that means >10 lines of) code to libFLAC. Only the codec libraries need to be BSD; the command-line tools and plugins would remain GPL. 3. Operations would move from Sourceforge to Xiph. There are pluses and minuses, actually not so much minuses as unknowns. These are the main changes that would happen. So I ask everyone, especially libFLAC contributors, what do you think? Josh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
En r?ponse ? Matt Zimmerman <mdz@debian.org>:> BSD licensing has been demonstrated to work in practice, for similar > applications, by a number of high-profile projects, including those > associated with Xiph.org. I believe that in these situations, theIn the case of hardware support, the benefits are still not there.> freedom > and continued viability of the software is ensured not by legal > restrictions, but by recognized leadership in a community. Xiph.org is > a strong ally in that area, with a thriving and well-recognized > community.Well, in the Windows world, Xiph are seen as Linux people. With all the positive and negative vibes that is related. Just look at all the mess that happened with the video integration in OGG (through Tobias W.'s DirectShow filter), or the war of file extensions OGM vs OGG.> I can foresee no obvious negative consequences, and a few tangible > benefits. > Overall, I would say that it seems like a beneficial course of action, > though not to the extent that I would consider it a failure if it were > not taken due to other concerns.That sounds reasonable. My main concern is that FLAC should be usable in other containers than OGG and other architectures than the one Xiph wants to create. This is probably not the right place for me to discuss about this. But the "complete solution" that Xiph wants to create is IMHO a bad move. I think the UNIX way of doing things is better : have simple things working, instead of a big mess. That means there should be a portable codec API, different containers that can work with this API, and the codec developpers should work with that API and don't care about the underlying and upperlying levels. Putting everything in the same bag seems to be a good solution to fill the lack of consistency in the Linux multimedia world. But I think it's a short sighted view.
Maybe Matching Threads
- Should FLAC join Xiph?
- Should FLAC join Xiph?
- [LLVMdev] Compiling issues: undefined reference to `.Lline_table_start1'
- [LLVMdev] Compiling issues: undefined reference to `.Lline_table_start1'
- [LLVMdev] Compiling issues: undefined reference to `.Lline_table_start1'