Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20060719/1f7ff5c0/signature.pgp
> Kind of interesingly to me, with that plain command-line-call mentioned > above, double_codebook is turned on. > Since I haven't found anything in the manpages: how can I turn this off? > Would you consider turning this off useful?double_codebook isn't a feature. It's just an internal parameter that describes how the encoding is done at different bit-rate. In practice, it's only enabled at very high bit-rate.> The second thing you immediately see when using none of these fancy > options is that the codebook entries found in > libspeex/cb_search.c::split_cb_search_shape_sign and written into the > stream by speex_bits_pack are (in one subframe) very often the same > (I've seen the numbers 63, 45 and 171 being written into the stream very > oftenI do expect some to be more common than others, but I don't think it's only a handful of entries that get used.> Has anybody ever examined this statistically? There seems to be some > redundancy (this might be also because I of course look at the beginning > of the coding output, which might be silence). Should I try at least > using -vad to reduce this redundancy (the less redundancy there is, the > better this is for my task, which is still a steganographic extension to > speex).I don't see what -vad would have to do with that... In any case, yes there is some redundancy. Speex uses VQ, but it doesn't use any form of entropy coding on the symbols. This makes it easy to get CBR, but of course, there's a bit of redundancy left (I would expect about 10%). Jean-Marc
Hi, Jean-Marc Valin wrote:>> (I've seen the numbers 63, 45 and 171 being written into the stream very >> often > > I do expect some to be more common than others, but I don't think it's > only a handful of entries that get used.I will have to examine the statistics of the codebook entries written into the stream during my work anyways. Maybe I'll find out something interesting, I can post that on the list if I have any results.>> Should I try at least >> using -vad to reduce this redundancy (the less redundancy there is, the >> better this is for my task, which is still a steganographic extension to >> speex). > > I don't see what -vad would have to do with that... In any case, yes > there is some redundancy.For my test scenario, I will use speexenc --vbr [filename].wav [filename].spx because that seems reasonable for many applications like hearing books, podcasts etc. (I don't see a reason why a no-option call or a call with option -n would be very reasonable)> Speex uses VQ, but it doesn't use any form of > entropy coding on the symbols. This makes it easy to get CBR, but of > course, there's a bit of redundancy left (I would expect about 10%).As I wrote above, this redundancy will be subject to my studies. Thank you very much, Bj?rn -- You will inherit millions of dollars. -- Important! Please recognize my new GPG Public Key! Bj?rn Thalheim gpg fingerprint: 2F22 AAEB 1818 1548 EC78 1AE8 9D2E FCB4 0980 28CC download key: wget http://www.ifsr.de/~bjoern/gpg/public_key.asc See also: http://www.ifsr.de/~bjoern/gpg/key.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.xiph.org/pipermail/speex-dev/attachments/20060724/83ae2076/signature.pgp