[vorbis] vcut breaks song index ? XMMS search fails

[Arc]

On Fri, Aug 29, 2003 at 08:28:44AM -0400, Carsten Haese wrote:
> 
> See http://www.xiph.org/ogg/vorbis/doc/vorbis-ogg.html

I found that after I wrote the email. It backs up my previous belief.

> Your problem lies in a misunderstanding of what the granulepos
> indicates. It doesn't say "stop decoding here." It says "This is the
> position of the *last* PCM sample of the last packet completed on this
> page." By definition, that can't be negative. The negative number comes
> into play when you infer the *first* sample position from that, by
> subtracting the length of audio contained in the page from the
> granulepos. If the granulepos is smaller than the length, this will give
> you a negative number that indicates how many samples to discard from
> the beginning.

It looks like I'm right, you're right, we're all right.

It doesn't matter if you put it in terms of "stop decoding here" if the
granulepos is less than the total number of samples in the packet, or
"skip this many samples" if the vorbis header packets negetive number,
and yes by definition it can be negetive.

Forcing a rigid way of understanding the situation doesn't help.  Either
way you look at it negetive numbers (other than -1) are legal in the
first data page, will not generate an error, and mean "this number of
samples have been chopped off the front" when it's present in the first
data page which contains two packets.  A non-zero number for the same
two packets means that the stream started somewhere in the middle and
the decoder should consider this number to be the "first" position.

Then on the last packet give it a lower than total granulepos and the
player will not play beyond this point.

On the physical layer, packets don't have granulepos.  However, the
ogg_packet structure does have granulepos's when ogg_stream_state turns
it into a ogg_page.  Therefore, for the first two vorbis packets you'd
set the granule to be the same negetive number, send these in, and then
call a flush to get a complete page that ends on that negetive number.

Continue as normal till end..

Then on last packet give it a less than total granulepos to indicate
that the player shouldn't play any more, ie, "stop decoding here".  
No other packet can be short like this, and since it's the EOS it must
be the last packet in a page.

The only thing I'm unsure of is the granulepos of the middle packets.
If you take an existing stream and want to, say, chop 5 granules off the
start, do you need to edit the granules of the rest of the stream as
well to be 5 less?  Also, what does -1 mean on the first data pages,
"skip 1 granule" or "nothing decoded"? Does -1 actually ever appear on
the header of a Ogg page or is that just internal?

Also, is such behavior expected to be for all codecs, or just Vorbis?

If there's anything in this that's incorrect please help me understand
it better, because I do spend quite a bit of time explaining how Ogg
works to other techs (and am planning to publish the easier-to-understand 
"ogg in like a book" metaphore for the libogg2 docs).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis/attachments/20030829/5c2e8f26/part-0001.pgp