[Speex-dev] Ogg embedding, problem with spec and/or bugs in speexenc

[Joe Wreschnig]

On Sat, 2006-07-15 at 18:30 -0500, Joe Wreschnig wrote:
> On Sat, 2006-07-15 at 14:35 -0700, Ralph Giles wrote:
> > On Sat, Jul 15, 2006 at 02:17:22PM -0500, Joe Wreschnig wrote:
> > 
> > > I'm working on support for tagging Speex files for Mutagen[0] and part
> > > of the specification at [1] is confusing me. It says the first page
> > > should have granulepos 0 and packetno 0. Does this really mean page
> > > sequence number 0, since the Ogg format doesn't number packets?
> > 
> > Sounds like a spec bug. The libogg reference implementation always 
> > flushes a page after the zeroth packet, so packetno=0 is effectively
> > page sequence no zero. But as you say, packetno doesn't exist in the 
> > bitstream, and page number does, so this is what the spec should
> > describe.
> > 
> > > It says the comment packet should have granulepos 0. However, when I
> > > force a multipage comment packet, all but the last page have granulepos
> > > -1. Regardless of the above, I believe this is a speexenc bug. Either it
> > > should mark all these pages 0, or only allow one page.
> > 
> > A granulepos of -1 means 'no value'. Since you're splitting a single 
> > comment packet over multiple pages, only the final page can be marked
> > with a valid granulepos. The others get -1 since no packet ends there.
> 
> This is not in line with what
> http://www.xiph.org/vorbis/doc/Vorbis_I_spec.html#vorbis-over-ogg says: 
> 
>   The granule position of these first pages containing only headers
>   is zero.
> 
> Which makes it sound like *all* the pages containing only headers get
> granulepos 0, rather than just the last page of each packet (or does it
> say "pages" where it means "packets"?). 0 is currently what Mutagen
> writes for Ogg FLAC and Vorbis files, and ogginfo and libvorbis are
> happy with that.
> 
> Though I see vorbiscomment also assigns -1 granulepos to each page
> except the last. Which is correct, the spec or the reference
> implementation?
> 
> > HTH,
> 
> Unfortunately as far as my original query goes, it does not. I still
> don't know whether it means "page" where it says "packet" or means
> "packet" and therefore is just talking nonsense. And now I also need
> clarification for the Vorbis spec...

After talking to Jean-Marc on #xiph, here's an updating phrasing for the
section. It's not presented as a diff because unfortunately LyX doesn't
generate diff-friendly changes. This changes it to describe pages
instead of packets (and adjusts the descriptions appropriately). It also
says there will be a page break between the first and second packets,
and second and third packets. This statement is not in the current
standard, but is the behavior of speexenc/libogg when given the
parameters the old version was describing.

Starting after "For now, refer to speex_header.[ch] for more info.",
replacing the text up until the table describing the header:

"""
... For now, refer to speex_header.[ch] for more info. This packet
should be alone in the first page of the Ogg stream, and the beginning
of stream flag should be set to 1. The granule position of this page
should be 0.

The second packet contains the Speex comment header. The format used is
the Vorbis comment format described here:
http://www.xiph.org/ogg/vorbis/doc/v-comment.html. This packet may span
multiple pages; the granule position of the last page should be 0, and
ones preceding it -1. However many pages it spans, this packet should
finish the page on which it ends.

The third and subsequent packets each contain one or more (number found
in header) Speex frames. The granule position of a page is the number of
the last sample of the last packet completed on that page. A page that
is entirely spanned by a single packet (that completes on a subsequent
page) has no granule position, and the granule position is set to -1.
The last of these pages has the end of stream flag set to 1.
"""
-- 
Joe Wreschnig <piman at sacredchao.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20060719/caa8fefb/attachment.pgp