[vorbis] vcut breaks song index ? XMMS search fails

[Carsten Haese]

On Fri, 2003-08-29 at 04:55, Arc wrote:
> On Fri, Aug 29, 2003 at 10:59:02AM +1000, Michael Smith wrote:
> > >
> > > Hmm... yea I just assumed that it used negetive granulepos, based on the
> > > Ogg spec.  But under diagnosis, yea...
> > 
> > Read a little closer (actually, isn't this part of the vorbis spec - the part 
> > dealing with how vorbis is embedded in ogg, obviously). In this case, the 
> > granulepos is 'short' - less than it normally would be if you used all the 
> > samples decodable from those packets. It still can't be negative (a negative 
> > granulepos is always an error).
> 
> Ok, first I'll prefix that I've been looking for and cant find the
> source for where I read about the negetive granulepos meaning skip
> initial granules.  However, this still doesn't make sense.  Take the
> following simplified example:

See http://www.xiph.org/ogg/vorbis/doc/vorbis-ogg.html

> 
>                         <- Granules ->
> 0000000000111111111122222222223333333333444444444455555555556666666666777
> 0123456789012345678901234567890123456789012345678901234567890123456789012
>  _______________________________________________________________________
> |_2__|_3____|_4__|_5___|_6____|_7____|_8___|_9____|_10____|_11___|_12___|
>                                   ^cutpoint (granule 34, packet 7)
> 
> The first piece would contain the header packets up to 7, with packet 7
> (thus the page which contains packet 7) having a granulepos of 34.  The
> decoder will not try to play past this so all of packet 7 can be include
> without transcoding it.
> 
> However
> 
> The second piece is going to also have to contain the header packets,
> then packet 7 and on.  Giving packet 7 a lower granulepos (ie, 34) will
> only result in weirdness - the granulepos means "decode up to this
> point" not "start decoding here", therefore mucking it's granulepos
> setting will only result in it starting to play from the beginning.  It
> won't even have anything cut from the second part, as regardless it'll
> begin playing packet 7 from it's first sample.  Giving it a lower
> granulepos will only result in the player reading packet 8 (which
> has a normal granulepos) and playing the rest of packet 7, assuming that
> it was incomplete data.  Or so I believe...

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.

Hope this helps,

Carsten Haese.

<p>--- >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-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.