[vorbis-dev] some more granulepos questions
msmith at xiph.org
Sun Nov 16 18:06:51 PST 2003
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
> 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.
> 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.
--- >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.
More information about the Vorbis-dev