search for: wb_skip_tabl

Hi Alexander, > Here is first attempt. I'm sending it here for review - am I understand > you correctly? If general approach is correct, I'll change code to use > modes from modes.c. I haven't tested, but it looks sane. Just a few comments: - printf("\tERROR not enough bits left after wb\n"); this is actually now an error. It just means you got to the end of the

>> Oh, your table looked fine. I think it's mine that was wrong for the >> "null mode" (which nobody ever uses I guess!). > > I'm not sure, but I guess it may be used in VBR or DTX mode? > At least that's why I kept it. Of course it *can* be used (and needs fixing). It just seems few people did :-) > So, what's the next step towards

Hi, 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(). 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:10...

Hi, Bringing up this unfinished old thread. Here are my patches: wb_skip_table-fix-and-move.diff - fixes the issue with wb_skip_table and makes it available for use outside of nb_celp.c (we need it for the second patch). speex_bits_get_num_frames.diff - adds speex_bits_get_num_frames() method as we discussed. Hope to see this incorporated into trunk ;) On Thu, Feb 21, 200...

> 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 se...

> 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 >>

...; 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. > > Waiting for your decision ;) > I guess you stopped on the fact you need to check my statement > about wb_skip_table? Oh, your table looked fine. I think it's mine that was wrong for the "null mode" (which nobody ever uses I guess!). > It would be good to define - it is very misleading for newcomers > as it is now. And I would like to say, that from user point of view > "frame"...

...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. Waiting for your decision ;) I guess you stopped on the fact you need to check my statement about wb_skip_table? > >> 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...

...Probably not that much to keep code DRY. > >> Well, let's first merge your code and then we'll see about possible > >> simplifications. > > > > Waiting for your decision ;) > > I guess you stopped on the fact you need to check my statement > > about wb_skip_table? > > Oh, your table looked fine. I think it's mine that was wrong for the > "null mode" (which nobody ever uses I guess!). I'm not sure, but I guess it may be used in VBR or DTX mode? At least that's why I kept it. So, what's the next step towards intergartion?...