--- Ingo Ralf Blum <ingoralfblum@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 > 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.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. Josh __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com
--- Ingo Ralf Blum <ingoralfblum@gmx.de> wrote:> > currently flac sets all granulepos members of the ogg pages to 0, > when > > embedding a FLAC stream into an Ogg file. Is it possible to change > this > > behaviour to use a more reasonable value, e.g. the bytes written so > far. > So > > when the first packets is 1000 bytes long it gets the granulepos > 1000 and > > when the second packet is 1234 bytes long it gets the granulepos > 2234 and > so > > on. This would make it easier to seek in Ogg/FLAC files. > > No response to this? Is this a bad idea (I don't think so) or should > I send > a patch?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. Josh __________________________________________________ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
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 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. Regards, Ingo