Speex dev - Jul 2006 - Ogg embedding, problem with spec and/or bugs in speexenc

(Sending again after subscribing, I guess the moderator is on vacation.)

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?

If it doesn't mean page sequence number, what does it mean?

If it does really mean packet, does that mean there are no guarantees
about page/packet boundries? e.g. Vorbis guarantees the first page
contains only, and entirely, the first packet. speexenc breaks pages
after the info and comment packets, which again suggests "pages"
rather
than "packets" is meant.

Later it says that the audio data starts at packetno 2. Does this really
mean page number 2? If so, does that mean the comment packet cannot span
multiple pages? I can force speexenc to write a multipage comment
packet, which would indicate either speexenc is wrong or the spec is
wrong.

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.

[0] http://www.sacredchao.net/quodlibet/wiki/Development/Mutagen
[1] http://www.speex.org/manual2/node7.html#SECTION00073000000000000000
-- 
Joe Wreschnig <piman@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/20060715/dc5414b9/attachment.pgp

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.

On a related note:

The granulepos field is only stored on a per-page basis, and corresponds 
to the granulepos of the last packet to finish on that page. So while 
the encoder fills out all the ogg_packet structures it generates, most 
of these are discarded when they are packed into ogg pages. When the
packets are later unpacked from the stream, libogg doesn't attempt to 
reconstruct the granulepos (this requires codec-specific knowledge) so
only packets which happen to be the last to finish on a page will be 
marked with a granulepos; all other packets will have -1; it's up to
the layer of software above libogg to reconstruct them if necessary.

HTH,
 -r

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...
-- 
Joe Wreschnig <piman@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/20060715/38b8cf9d/attachment.pgp