[vorbis] vcut breaks song index ? XMMS search fails

[Arc]

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:

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

> Yes, vcut really is sample-accurate (in the cases where it works - as you and 
> others have seen, it doesn't always). This means it does two things: it cuts 
> to packet (not page) accuracy, then rewrites the granulepos values so that 
> (as described above) they're 'short' at the start/end, so that the exact 
> sample offset desired is used.

Can you clarify, what did you do to make vcut make the second file start
decoding midway through the packet?  Did you edit the packet's data to
do this or did you do something else?  

-------------- 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/c437a439/part.pgp