* Josh Coalson ([EMAIL PROTECTED]) wrote: > I'm kind of swamped today so I'll answer what I can get > away with until tonight: > > --- Joshua Haberman <[EMAIL PROTECTED]> 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.
You make the decision for 99% of users just by the defaults you write into the software. Even as a fairly informed user, I am unclear on the differences and interactions between: - Ogg FLAC vs. FLAC - id3 vs. vorbiscomment Is Ogg flac literally a FLAC file verbatim with extra framing? Is it possible to have id3 tags in an Ogg FLAC file? Is it possible to have both vorbiscomment and id3 tags in the same file? If so, which is designed to take precedence (ie. what will libFLAC give to the application?) Can libFLAC always read any permutation of these? Above all, why do I need so much choice? :-) I think it would be good to have some sort of standardization or recommendation on what form audio data compressed by FLAC should take. This doesn't have to mean taking away options from the user, just crafting the defaults so that users who aren't tweaking things will find that everything just works. The user shouldn't have to care if their comments are in id3 or vorbiscomment format. Pick the one that is better, and depricate the other (continue to support reading it for a while but stop writing it, make it easy to convert one into the other, etc.) > > 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). That's excellent to hear. > > 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. Gosh, it really seems like it would have been simpler to make it a property of the ogg stream. The arbitrary attribute/value parameters seem to give plenty of flexibility, and it could always be extended. But I guess what's done is done. :-) > > 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. Great. Since we're lossless, transcoding is just a minor pain. As a user and app developer, I am definitely in favor of FLAC joining Xiph. The potential for increased exposure and increased application support makes it seem like a no-brainer. I cannot think of any substantial objections. 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_ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Flac-dev mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/flac-dev
