ogg dev - Apr 2007 - AW: .NET tagging library for ogg Vorbis and ogg FLAC

Hello,

I'm still working on the native .NET ogg tagging library. It already works
well for non-multiplexed ogg vorbis, ogg flac and native flac files. Concerning
multiplexed files, I've got two short questions:

1) Is it valid to insert an "empty" page into the stream which simply
contains the binary value 0 for the page_segments counter, and which therefore
contains no segment table nor any packet data? I'd like to do this to
produce a gapless page sequence number so that I don't have to re-number all
following pages, so that I don't have to re-compute the checksums of all
following pages. This is way faster.

2) Is it correct that in multiplexed files the page sequence number is in the
scope of the logical stream, not of the physical stream (meaning that the
sequence numbers of two logical streams multiplexed into a physical file stream
both start with 0)?

Thanks,
Mathias



      __________________________________  Yahoo! Clever: Stellen Sie Fragen und
finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever

On Fri, Apr 20, 2007 at 03:10:09PM +0000, Mathias Kunter wrote:
> 1) Is it valid to insert an "empty" page into the stream which
simply contains the binary value 0 for the page_segments counter, and which
therefore contains no segment table nor any packet data? I'd like to do this
to produce a gapless page sequence number so that I don't have to re-number
all following pages, so that I don't have to re-compute the checksums of all
following pages. This is way faster.
Good question! I don't think anyone has thought of that before. libogg 
can't produce such pages, but the code doesn't obviously look like it 
will fall over. Have you tested this?

The specs clearly didn't consider this case, but I agree the appropriate 
interpretation is that the page is empty, containing no packet segments.
If the software doesn't treat it as such we should fix that. It is more
likely to cause problems with embedded implementations though.
> 2) Is it correct that in multiplexed files the page sequence number is in
the scope of the logical stream, not of the physical stream (meaning that the
sequence numbers of two logical streams multiplexed into a physical file stream
both start with 0)?
That is correct. The page sequence number is for detecting missing or 
corrupt data, so you don't end up concatenating segments from different
packets, and thus is scoped by the logical stream. The granulepos field
is the only thing that affects ordering in a multiplexed stream.

 -r

Ralph Giles wrote:
> Good question! I don't think anyone has thought of that before. libogg 
> can't produce such pages, but the code doesn't obviously look like
it
> will fall over. Have you tested this?
I believe (according to Monty; he can correct me if I'm wrong) that this
has always been allowed by design (for example, it allows you to insert
a timestamp for seeking purposes when there is otherwise no actual data
in the stream). What existing software it will break, I have no idea.

On 21/04/07, Ralph Giles <giles@xiph.org> wrote:
> Good question! I don't think anyone has thought of that before. libogg
> can't produce such pages, but the code doesn't obviously look like
it
> will fall over. Have you tested this?
OOOgg and HOgg can produce such files. libogg doesn't stop parsing if
it sees them. Zen was playing with these in the context of the
Skeleton EOS page a while ago, but we ended up specifying a
zero-length packet in that so that it is visible at the page level,
and so that its granulepos makes sense. Fudging page sequence numbers
sounds useful :-)

cheers,

Conrad.