Vorbis - Feb 2002 - Seeking in a saved stream; or,Why isn't that sucker valid?

>> Running ogginfo on the stream data gives:
>> stream_integrity=fail
>This line in the ogginfo output concerns me.  It means that there are
actually
>damaged Ogg packets in the stream.  How are you saving this stream to disk?
This particular one was obtained with wget on OpenBSD.  I've observed the
same problem with files saved from Winamp.
>I think there is a problem here, but not with seeking, exactly.  If the file
>is saved on disk, then it should be seekable.  It is possible that
vorbisfile
>is not acting correctly when given damaged streams of the sort you have.
That seems to be the problem, rather than libvorbis - it plays without problems,
though it doesn't pass ogginfo.  I had assumed that there was a problem with
the first and last bits of data that was preventing vorbisfile from properly
parsing the file.

Can you save a live stream to disk and have it perform properly?  I've used
http://ogg.bbc.co.uk:8001/radio1_high.ogg and
http://ogg.bbc.co.uk:8001/radio1_low.ogg ; you might try those first.

<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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

[megasnip]
> > > stream_integrity=fail
> > > stream_truncated=true
> > > header_integrity=fail
> >                    ^^^^
> > odd one there.  But if it were true, it couldn't play.
> Uh, more weird is that there are two of them.  It looks like vorbisfile
> decided that there were two streams, and the last one has a damaged header
> (or more likely, the last packet doesn't contain Vorbis headers at
> all).  Perhaps this is what confuses most players.  This looks like a
chained
> stream with a bad second part.
I realize that I may have unintentionally been misleading you by leaving some
information out.  That error report from ogginfo keeps going, repeating the same
3 errors (as above) over and over again.  It ends after a stream_truncated=true,
not giving a final header_integrity=fail.  (Perhaps because there's not
another packet?)  Then it reports a total playtime of 0.

<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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

Stan Seibert wrote:
>feature, really.  The granulepos numbers (used to compute time) don't
have to
>start at zero, and usually won't in a stream you download.  (Time 0 is
usually
>when the stream was first started.)  Ogginfo should probably subtract the
>start time from the end time, rather than just assume the end time is the
>total time.
So would it be simple to generate a fresh stream with correct granulepos numbers
(e.g., read the input stream, start granulepos at zero, spit out the stream to a
new file)?

<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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.

> Stan Seibert wrote:
> Fairly simple, though that doesn't address the corruption problem.  In
that
> case, ogginfo is getting confused by the final corrupted packet.  (Since
the
> download is terminated manually, the last packet is most likely
incomplete.)
OK.  I'll try to work on this this weekend - hopefully, I'll remember
enough C to be able to write a stream-cleaning program.

<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@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.