SV: [Speex-dev] How to detect SpeexBits corruption

[Jean-Marc Valin]

The first thing to know about Speex packets is that for the most part,
they will look almost totally random. If they didn't, it would mean the
information is redundant, i.e. not optimally compressed. The only
exception is (part of) the first byte. The narrowband encoder uses 5
bits to indicate the mode. The first bit is always 0, and the following
4 bits indicate the bit-rate. Basically, it looks like:

+---+---+---+---+---+---+---+---+
| 0 |     Mode      |   Random  |
+---+---+---+---+---+---+---+---+

For instance, a 8 kbps stream, will begin with a byte 0x18 to 0x1f. The
reason for the range is that the three next bits are random. The valid
mode values are 0-8 and mean:
0: Silence (no likely to see that one)
1: 2.15 kbps
2: 5.95 kbps
3: 8 kbps
4: 11 kbps
5: 15 kbps
6: 18.2 kbps
7: 24.6 kbps
8: 3.95 kbps (yes, it's not an error)

To convert "bits per second" into "bytes per packet" (which is more
useful for figuring things out), just divide by 400 and round up (to
have complete bytes). Hence at 8 kbps, packets are 20 bytes long
(including the first byte described above). That's about all there is to
know about Speex packets.

	Jean-Marc

P.S. Have you published your results somewhere? I'm sure others would be
interested.

Greg Copeland a écrit :
> Ohh...nice.  I actually thought I was emailing Jean-Marc and didn't
> expect anything back from the list.  In fact once I got a reply back
> saying it was waiting mod approval for list submission, I though it
> would be dropped.  Your reply is both unexpected and much appreciated.
> 
> I'm checking it out right now!!
> 
> Thanks,
> 
> Greg
> 
> 
> On Sat, 2007-03-17 at 12:00 -0400, Steve Kann wrote:
>> I wrote a speex parser, which we use inside of asterisk and iaxclient.  
>> It can parse a stream of speex data into individual packets:
>>
>> See static int speex_get_samples(unsigned char *data, int len) (and it's 
>> 2 helper functions) in 
>> http://iaxclient.svn.sourceforge.net/viewvc/iaxclient/trunk/iaxclient/lib/libiax2/src/iax.c
>>
>> As it's written, it just looks at a bunch of speex data, and tells you 
>> how many actual samples are contained within, but the code can be 
>> changed to do more generic parsing.
>>
>> -SteveK
>>
>>
>> Greg Copeland wrote:
>>> I was curious if you had ever peeked at a Teamspeak voice packet?  I
>>> already have large chunks of the protocol torn apart.  I believe the
>>> voice packets are the last big hurdle.  As I know nothing about speex
>>> encoding, it is proving difficult to figure out the start of the actual
>>> voice data and/or any voice specific state data contained within the
>>> packet.  If you have any information and are willing to share, I'd
>>> certainly love to see it.  I'm oh so close to having a bare bones TS
>>> client on Linux which actually uses ALSA.
>>>
>>> On my hardware, the ALSA-OSS emulation provides for horrid mic input
>>> (even using the native TS client) but the native ALSA stuff sounds
>>> pretty well.  At any rate, any detail you can provide would be
>>> appreciated!!!
>>>
>>> If you're curious, I'm currently prototyping this in python using
>>> audioop, wave, pyaudio and pySpeex.  Once I have something that works,
>>> I'll probably turn around and make a WxWidgets client (C++) which uses
>>> ALSA...but I'd also like to quickly tie a T-T-S app to a TS server via
>>> the python implementation, quickly, if I can.
>>>
>>> As an aside, I started this project to filter various TS packets to
>>> prevent hackers from abusing the server.  To do that, I had to determine
>>> good packets from bad packets.  Thus far my efforts have stopped all
>>> hacking (to date) on my brother's TS server.  So naturally, I thought it
>>> would be fun to tie a T-T-S mechanism to the server to stop the "who
>>> joined" questions...so on and so on...  And here we are.  ;)
>>>
>>> --
>>> Greg 
>>>
>>> _______________________________________________
>>> Speex-dev mailing list
>>> Speex-dev at xiph.org
>>> http://lists.xiph.org/mailman/listinfo/speex-dev
>>>
>>>