Speex dev - Feb 2008 - Determine number of 20ms frames in packet - without decoding

> Ok, here is cleaned up and fixed version.
> 
> * Function is named speex_get_num_frames() now and return
> number of frames, as you suggested.
> * WB layers sizes are taken from wb_skip_table[], while NB frame
> sizes are calculated with speex_mode_query().
Looking better. Just make sure to remove the stuff that isn't
C99-compatible (e.g. // comments).
> I've tested it with testenc in NB, WB and UWB modes with VBR enabled
> to test in as many cases as possible. It seems to work fine.
> Though, while testing I discovered possible bug - original version
> of wb_skip_table[] (nb_celp.c:1081) does not seem to be correct.
> Element 0 should be 4 instead of 0 and last four elements should
> be -1 instead of 0 to make it compatible with speex_mode_query()
> return values. So, for now I declared own version of wb_skip_table[].
I'll need to have a closer look at that code.
> I also think that having rame_num.c in libspeex, code size could be
> reduced and simplified slightly by using speex_skip_wb_frame() in
> nb_decode() instead of duplicating code.
Well, the code is a bit different (e.g. handling of in-band data), so
I'm not sure it's possible in a way that is worth it.
> You definitely have to create some dictionary of terms, used in Speex.
> It's really hard to understand what is meant by "frame",
"subframe"
> and "layer" and how to name output of speex_encode()?
> What I meant is that when encoding in WB/UWB mode every frame
> consist of NB frame with one/two WB layers appended.
frame: 20 ms encoding
sub-frame: 5 ms encoding (internal)
layer: one frame of nb or sb
sb: sub-band
wb: nb+sb
uwb: nb+sb+sb

But what you say seems right.

Cheers,

	Jean-Marc

For clarity I attached modified testenc.c I used to test my code.

On 2/14/08, Jean-Marc Valin <jean-marc.valin@usherbrooke.ca>
wrote:
> > I also think that having rame_num.c in libspeex, code size could be
> > reduced and simplified slightly by using speex_skip_wb_frame() in
> > nb_decode() instead of duplicating code.
>
> Well, the code is a bit different (e.g. handling of in-band data), so
> I'm not sure it's possible in a way that is worth it.
Oh, you're right, inband handling is different, but it's a matter of one
flag, passed to functioin. Probably not that much to keep code DRY.
> frame: 20 ms encoding
> sub-frame: 5 ms encoding (internal)
> layer: one frame of nb or sb
> sb: sub-band
> wb: nb+sb
> uwb: nb+sb+sb
Hum... Then SPEEX_SUBMODE_BITS_PER_FRAME macro have
wrong name. This is what I was trying to ask in my previous mail.
Now it return number of bits in one layer (nb or sb), while I expected
it to return number of bits in one frame (nb or wb or uwb). I want
to get information about frame sizes to estimate bitrate for CBR
operation and bitrate bounds for VBR operation.

-- 
Regards,
Alexander Chemeris.

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testenc.c
Type: application/octet-stream
Size: 4367 bytes
Desc: not available
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20080214/6893d212/testenc.obj

> Oh, you're right, inband handling is different, but it's a matter
of one
> flag, passed to functioin. Probably not that much to keep code DRY.
Well, let's first merge your code and then we'll see about possible
simplifications.
>> frame: 20 ms encoding
>> sub-frame: 5 ms encoding (internal)
>> layer: one frame of nb or sb
>> sb: sub-band
>> wb: nb+sb
>> uwb: nb+sb+sb
> 
> Hum... Then SPEEX_SUBMODE_BITS_PER_FRAME macro have
> wrong name. 
Well, I haven't quite defined whether a frame includes all
"layers" or
just one...
> This is what I was trying to ask in my previous mail.
> Now it return number of bits in one layer (nb or sb), while I expected
> it to return number of bits in one frame (nb or wb or uwb). I want
> to get information about frame sizes to estimate bitrate for CBR
> operation and bitrate bounds for VBR operation.
You know you can already specify the bit-rate directly instead of the
quality, right? Also, VBR now supports a "max rate" option.

	Jean-Marc