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? ---- 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? ---- 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? Thanks for all the answers you have already provided. Josh --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Sat, Nov 15, 2003 at 07:09:57PM -0800, 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 info is lost at the ogg level for packets that don't end a page, you may be able to reconstruct the granulepos using codec-specific knowledge, hence the other magic in vcut (which I'm not too familiar with :) Conrad. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.