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.