Re: How do I seek to seek to specific samples using libvorbis?

This thread reminded me of Ralph's LCA presentation entitled "Seeking is
Hard". <http://xiph.org/~giles/>

Not sure if it contains anything you don't already know, but worth a
mention.

- Josh

On 2015-5-20 06:55 , Madison Link wrote:
> Thanks.
> 
>  
> 
> If decoding from the last packet on the previous page works, I may have
> to do that. But I was hoping to avoid it. Yes, I may be seeking a lot. A
> packet spanning multiple pages shouldn't be a problem for me, because
> I'm only adding index points that represent the beginning of a packet.
> But does this actually happen for Vorbis? (Aside from large header
> packets) The large blocks I've encountered seem to be 1024 samples per
> channel. Even with 8-channel audio, uncompressed floating-point PCM
> sound, such a packet would only take up 129 segments on the segment table.
> 
>  
> 
> Madison
> 
>  
> 
>  
> 
> From: Jordan Verner [mailto:[email protected]]
> 
> Sent: Tuesday, May 19, 2015 12:20 PM
> 
> To: Madison Link
> 
> Subject: RE: [Vorbis] How do I seek to seek to specific samples using
> libvorbis?
> 
>  
> 
> What I did was performed a binary search in my ogg vorbis file, in order
> to find the page proceeding the page containing the desired sample (you
> can determine this using the granule position). Next, I used
> ogg_page_packets() to determine how many packets complete on that page,
> skip to the final packet by calling ogg_stream_packetout N times and
> just ignoring the result. Then decode the page's final packet. This
> should mean that the next sample you decode will actually be the one the
> granule position says it is. Then you have to calculate an offset
> between the sample you're at and the one you want, decode that many and
> discard them. In practice this seems to work but leaves a lot to be
> desired. You could be decoding up to an entire page of audio (slow if
> you seek a lot), and there's an off chance that a complex and rare case
> involving a packet spanning three or more pages could still throw you
> off. I think it could be possible to do it with only decoding two extra
> packets if you can calculate where you'll end up based on blocksize
> values and window overlapping rules, but it's not well explained. The
> spec leaves a lot to be desired.