[Flac-dev] Ogg FLAC and granulepos

Josh Coalson xflac at yahoo.com
Tue Feb 5 23:44:01 PST 2002

--- Ingo Ralf Blum <ingoralfblum at gmx.de> wrote:
> Hi,
> > sorry about that... it sounds like a good idea but I don't
> > know what the right metric would be (bytes written, sample
> > number, etc).  I was going to forward this to vorbis-dev
> > but haven't yet.
> If you see the whole thing from a perspective of a filter graph, like
> DirectShow or GStreamer, the number of bytes written so far is the
> best
> solution. The graph for playing such a stream would be
> FileReader -> OggDemultiplexer -> FLACDemultiplexer -> here we have
> audio data
> Each filter has a capability to receive seek commands, which works
> upstream,
> and each filter can deliver data by pushing it downstream. So lets
> look what
> happens when you seek to a specific time. The FLAC demultiplexer,
> which
> thinks, that it has a real FLAC file at its input, seeks to a
> specific byte
> position in the virtual FLAC file. Virtual because the FLAC file is
> not on
> the disk, but its a byte stream embeded into the Ogg container. So
> when it
> receives the seek command, it translates it to a byte position and
> itself
> issues this position with a seek command upstream. Now the Ogg
> demultiplexer
> has to seek to a specific byte position and this can be done best by
> using
> the bytes written so far as a granulepos. Doing it this way a real
> FLAC file
> can be read with the same filters:
> FileReader -> FLACDemultiplexer
> And with such an Ogg demultiplexer it is possible to embed any other
> byte
> stream into the Ogg with the same method, e.g. you could put an Ogg
> into
> another Ogg.
> A better aproach would be to, not to embed the whole FLAC file into
> the Ogg
> itself, but the single audio frames the way done with Vorbis frames
> (Ok,
> they are called packets there). If so, the best granuelpos would be
> the
> sample position, like in Vorbis.

OK, gotcha.  but currently flac does put one FLAC frame per
packet.  the exception, and a bug looking at the code again,
is that it also uses the first packet for the FLAC metadata
but is using 0 for the packet number of both the metadata and
the first audio packet, which I need to fix.

so I think it does make sense to use the sample number.  unless
I am missing something.  the ogg spec suggests that it should
be the number of the last sample in the packet.  so for the
metadata packet, it could be 0 and still make sense I think.


Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!

More information about the Flac-dev mailing list