[Flac-dev] Should FLAC join Xiph?

[Joshua Haberman]

* Josh Coalson (xflac at yahoo.com) wrote:
> I'm kind of swamped today so I'll answer what I can get
> away with until tonight:
> 
> --- Joshua Haberman <joshua at 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_