[vorbis-dev] some more granulepos questions

[Michael Smith]

On Sunday 16 November 2003 14:09, Joshua Haberman wrote:
> I've made a lot of progress on my lossless Vorbis editing project.  I
> have a few more questions about granulepos issues I don't quite
> understand.
>
> granulepos is a property of Ogg pages, yet it is a field in the
> ogg_packet struct.  When reading packets from an Ogg stream, the
> granulepos is set to -1 for all packets except the last packet in a
> page.  From this I infer that
>
> - for encoding, the granulepos needs to be correctly set for every
> packet submitted to the stream because any packet could be the last on a
> page.  If it is the last on a page, its granulepos is used for that
> page's granulepos.
>
> - for decoding, the stream cannot determine a granulepos for each packet
> since it doesn't know anything about the codec, so it uses -1 to
> indicate that it doesn't know.  For the last packet on a page, it uses
> the page's granulepos.
>
> Q1.  Is this accurate?
>

Yes, that's exactly right.

<p>> ----
>
> I want to know the granulepos of individual packets.  It appears that
> Ogg cannot provide me this information.  Glancing at vcut, it appears
> that I can use the function vorbis_packet_blocksize() to determine the
> number of samples contained in a given vorbis packet.  But I have no
> idea why the vcut function get_blocksize() adds the packet's block size
> to the previous packet's blocksize and divides by 4.
>
> Q2.  How does vcut's get_blocksize() work?

This is how the vorbis format is specified. get_blocksize() is probably poorly 
named - what it does is calculate the number of output samples from the 
packet (i.e. the amount by which granulepos will be incremented). This is a 
property of the block size of the current and previous blocks.

>
> ----
>
> The spec says that the stream starts at an offset greater than zero if
> there are less samples in the first page than the granulepos of the
> first page.  For on-disk streams that have this characteristic, how will
> the vorbisfile ov_*_seek() and ov_*_tell() functions behave?  Will they
> act as though the file begins at offset 0, or will they expose the >0
> starting offset?
>
> Q3.  How does vorbisfile deal with >0 offsets?

This situation is a characteristic of files that have had the start removed - 
it's nicer (vcut does this) to clean up by re-numbering the granulepos of all 
the page. This is most common when receiving a stream from a streaming server 
- you'll usually be connecting mid-way through.

I believe vorbisfile exposes this - you won't be able to seek to the missing 
data, you'll get errors if you try. 

Mike

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.