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
* Josh Coalson (xflac@yahoo.com) wrote:> 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.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_
--- Joshua Haberman <joshua@haberman.com> wrote:> * Josh Coalson (xflac@yahoo.com) wrote: > > 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. > > 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. vorbiscommentI'll answer but keep it short just in case you're asking rhetorically:> Is Ogg flac literally a FLAC file verbatim with extra framing?Yes, Ogg FLAC is FLAC where each metadata block and frame is treated as a packet and fed into Ogg.>Is it possible to have id3 tags in an Ogg FLAC file?No, I believe Ogg disallows id3, i.e. compliant apps are not require to support them.> Is it possible to have > both vorbiscomment and id3 tags in the same file?In the same raw FLAC file, yes (raw FLAC is neutral to id3), but Ogg FLAC, no.> If so, which is > designed to take precedence (ie. what will libFLAC give to the > application?) Can libFLAC always read any permutation of these?libFLAC does not know about id3, it only reads Vorbis (it does know how to skip over id3v2 tags though). No compliant FLAC implementation is required to support id3 but it may if it wants to. The plugins currently do it for convenience by merging all existing tags together, Vorbis comments with highest priority, then id3v2, then id3v1.> 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.)If I started over from the beginning that's what I would do. Vorbis comments are relatively new (this year I think). I picked up on Ogg after the raw FLAC format was done. I haven't dictated a standard, but by your measuring stick of the easiest path through the tools, this is what it has evolved to with my prodding: Tagging: libFLAC and flac (the command-line encoder) only support Vorbis comments. Format: by default flac encodes to raw FLAC. If you go out of your way with --ogg you can get Ogg FLAC. The standard that is likely to persist is that raw FLAC is used to store audio only (usually CDs or taped shows), but when you want to stream/route/mux it through Ogg tools, then Ogg FLAC fits great. Josh __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus – Powerful. Affordable. Sign up now. http://mailplus.yahoo.com