[Flac-dev] Ogg FLAC

Ingo Ralf Blum ingoralfblum at gmx.de
Fri Feb 1 03:22:02 PST 2002


> 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 PCM
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.



More information about the Flac-dev mailing list