Speex dev - Dec 2004 - NOP pattern - how to make SPEEX packets bigger?

How can I add some size to SPEEX encoded packets without affecting 
decoding results?

I need it to fit smaller (due to VAD) packets in CBR acm-wav file.

i.e. I have 10 bytes packet with 0.02s of silence (only background noice 
without speech).
I need to fit it in 16kbps CBR wav file, so I need to put 30 additional 
bytes to this packets, but decoder should still decode only 0.02s of 
background noice.

On Fri, Dec 17, 2004 at 09:29:13AM +0100, Tomasz Pyra wrote:
> How can I add some size to SPEEX encoded packets without affecting 
> decoding results?
> 
> I need it to fit smaller (due to VAD) packets in CBR acm-wav file.
I'm not entirely familiar with how speex handles packet lengths, but 
have you tried just padding the packet out and seeing if the decoder 
still handles them properly? It looks like most of the reads are 
contingent, so it may find the natural end of the data on its own.

If you do try that, I'd suggest testing with a number of different
padding values, in particular 0xFF, 0xF0, 0x0F and 0x00 to make sure
you're not getting through by accident. 0xFF seems especially likely
to either terminate the packet or cause an error.

And if that scheme doesn't work, you can always embed a private packet 
length before each packet so your wav-demux layer can throw away the 
padding before handing the data off to the decoder.

Hope that is of some help, anyway,
 -r

You need to pad with 01111 (15 encoded in 5 bits). speex_bits_insert_terminator
does that, but it assumes nobody will add anything after.

    Jean-Marc


Selon Ralph Giles <giles@xiph.org>:
> On Fri, Dec 17, 2004 at 09:29:13AM +0100, Tomasz Pyra wrote:
>
> > How can I add some size to SPEEX encoded packets without affecting
> > decoding results?
> >
> > I need it to fit smaller (due to VAD) packets in CBR acm-wav file.
>
> I'm not entirely familiar with how speex handles packet lengths, but
> have you tried just padding the packet out and seeing if the decoder
> still handles them properly? It looks like most of the reads are
> contingent, so it may find the natural end of the data on its own.
>
> If you do try that, I'd suggest testing with a number of different
> padding values, in particular 0xFF, 0xF0, 0x0F and 0x00 to make sure
> you're not getting through by accident. 0xFF seems especially likely
> to either terminate the packet or cause an error.
>
> And if that scheme doesn't work, you can always embed a private packet
> length before each packet so your wav-demux layer can throw away the
> padding before handing the data off to the decoder.
>
> Hope that is of some help, anyway,
>  -r
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev
>
>