Hi,
I'm the main author of Speex (http://speex.sourceforge.net), an
open-source speech codec that uses Ogg for file storage. I'd like to
have feedback on the way we store Speex data in Ogg files to make sure
we do the right thing. The Speex documentation can be found at
http://speex.sourceforge.net/manual/ but here's the part about Ogg:
<p><p>Speex bit-streams can be stored in Ogg files. In this case,
the first
packet of the Ogg file contains the Speex header described in table 4.
All integer fields in the headers are stored as little-endian. The
speex_string field must contain the ``Speex `` (with 3 training
spaces), which identifies the bit-stream. The next field, speex_version
contains the version of Speex that encoded the file. For now, refer to
speex_header.[ch] for more info. The beginning of stream (b_o_s) flag is
set to 1 for the header. The header packet has packetno=0 and
granulepos=0.
The second packet contains a user-comment string, without terminating
null. The content/format of the comment string is not defined. This
packet has packetno=1 and granulepos=0.
The third and subsequant packets each contain one or more (number found
in header) Speex frames. These are identified with packetno starting
from 2 and the granulepos is the number of the first sample encoded in
that packet.
The stream is terminated by a packet containing the string ``END OF
STREAM'' (without terminating null). The the end of stream (e_o_s) flag
set to 1. The decoder should rely on the e_o_s flag and not on the
content of the packet.
<p><p>Any error we made? suggestions?
Thanks,
Jean-Marc
--
Jean-Marc Valin, M.Sc.A.
LABORIUS (http://www.gel.usherb.ca/laborius)
Université de Sherbrooke, Québec, Canada
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: signature.asc
Url :
http://lists.xiph.org/pipermail/vorbis-dev/attachments/20020813/c6550fb4/signature-0001.pgp
Here's my opinion (I'm no Xiph member, so just take this as an idea of an outsider):> All integer fields in the headers are stored as little-endian. TheShould be ok, as long as your libs take care of that.> speex_string field must contain the ``Speex `` (with 3 training > spaces), which identifies the bit-stream.Why the 3 spaces?> The next field, speex_version > contains the version of Speex that encoded the file. For now, refer to > speex_header.[ch] for more info. The beginning of stream (b_o_s) flag is > set to 1 for the header. The header packet has packetno=0 and > granulepos=0.Isn't -1 the preferred granuelpos for headers.> The second packet contains a user-comment string, without terminating > null. The content/format of the comment string is not defined. This > packet has packetno=1 and granulepos=0.You should specify the charset, for example UTF8, if your library doesn't handle it.> The third and subsequant packets each contain one or more (number found > in header) Speex frames. These are identified with packetno starting > from 2 and the granulepos is the number of the first sample encoded in > that packet.In Vorbis and FLAC the granulepos is the last sample, which is decodable from the packet, so perhaps you should change that.> The stream is terminated by a packet containing the string ``END OF > STREAM'' (without terminating null). The the end of stream (e_o_s) flag > set to 1. The decoder should rely on the e_o_s flag and not on the > content of the packet.Seems redundant to me. I'd leave away that special packet and set the e_o_s flag on the last data packet. Regards, Ingo <p><p><p><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-dev-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.
At 11:38 PM 8/13/02 -0400, you wrote:>Hi, > >I'm the main author of Speex (http://speex.sourceforge.net), an >open-source speech codec that uses Ogg for file storage. I'd like to >have feedback on the way we store Speex data in Ogg files to make sure >we do the right thing. The Speex documentation can be found at >http://speex.sourceforge.net/manual/ but here's the part about Ogg: > > > >Speex bit-streams can be stored in Ogg files. In this case, the first >packet of the Ogg file contains the Speex header described in table 4. >All integer fields in the headers are stored as little-endian. The >speex_string field must contain the ``Speex `` (with 3 training >spaces), which identifies the bit-stream. The next field, speex_version >contains the version of Speex that encoded the file. For now, refer to >speex_header.[ch] for more info. The beginning of stream (b_o_s) flag is >set to 1 for the header. The header packet has packetno=0 and >granulepos=0.This all looks fine, though space-padding 'Speex ' seems silly to me. I wouldn't do that.> >The second packet contains a user-comment string, without terminating >null. The content/format of the comment string is not defined. This >packet has packetno=1 and granulepos=0.Why not just define the content/format of the comment header as the same as the vorbis comment header (though obviously without the "vorbis" at the start, etc.)? That would seem more useful to me.> >The third and subsequant packets each contain one or more (number found >in header) Speex frames. These are identified with packetno starting >from 2 and the granulepos is the number of the first sample encoded in >that packet.granulepos must be the _last_ sample decodable from that packet, not the first.> >The stream is terminated by a packet containing the string ``END OF >STREAM'' (without terminating null). The the end of stream (e_o_s) flag >set to 1. The decoder should rely on the e_o_s flag and not on the >content of the packet.The final audio packet should have e_o_s set, and there should NOT be a seperate terminating packet like this - there's no need. 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-dev-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.