[vorbis] vcut breaks song index ? XMMS search fails

[Michael Smith]

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

Correct up to here.

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

I don't understand what you're saying here. Packets do not have granulepos 
values (in the ogg stream - we create temporary internal granulepos values so 
that the ogg pages have the right granulepos set), so saying "packet N has 
granulepos X" is very confusing.

What vcut outputs is this:

First, all the headers (these go in unmodified).
Then, start a new page, starting from packet 6. Fill up the page (or maybe it 
only ever puts 2 packets on this page? I don't remember, and it doesn't 
really matter). Calculate the natural granulepos value for this page (the 
granulepos it would have if we were playing everything). Subtract from that 
the offset from the start of packet 7 where we actually want to start 
decoding. Output page.

Continue on for the rest of stream, recreating the ogg layer but not doing 
anything abnormal.

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

vcut never changes packet contents. It rewrites the ogg layer completely, 
including changing granulepos values. 

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