Hello Rick, You covered a lot of ground there so I'll only make a few comments...
Yes I've played with quantising Wo and pitch (1/Wo) and the ideal law is probably some where in between. At the time saving bits on Wo wasn't significant but it probably is now. The 2500 bit/s mode doesn't use differential (in time of freq) quantisation, but the 1400 bits/version does. I am yet to be convinced that bit errors will cause a serious problem - we need to do some tests I think. LSPs don't directly map to harmonic amplitudes, but loosely to peaks in the amplitude spectrum. A closely spaced pair of LSPs will map to a peak in the amplitude envelope. This envelope is like a dotted line tracing teh peaks of the harmonics. The number of harmonics is time varying, from 10 to about 50 depending on Wo. It is possible to synthesise wideband speech(beneath 300Hz, about 4kHz) without any additional transmitted information based on what we know of the properties of speech. Cheers, David On Sun, 2011-12-04 at 20:01 +0000, Rick van Rein wrote: > Hello David + others, > > I've been reading into CELP and the Codec2 source code, and the latter > raises a few questions about things that could make it more compact and > consistent in quality; I would not be surprised if David's already on > top of this, but I'm posting this because I might raise something new. > > > The frequency Wo is encoded as a linear number; however, based on how our > hearing interprets frequencies logarithmically, I would assume that a > logarithmic representation should give rise to a more consistently felt > Wo-quantisation error. That could mean that less bits can be used to > represent Wo, or perhaps better, the range could be expanded to include > a 600 Hz children's voice: now 20-160 Hz in 128 additive steps of > 0.0625 Hz could become 20-605 Hz in steps of a 1.027 factor. > > Codec2 encodes its fields in an integer number of bits; but with the small > packet sizes being created, it would be possible to use DIV/MOD instead of > SHIFT/MASK to extract a field. Most platforms should support that > efficiently? As an example, the 81-entry codebook could be stored in > 2log(81)=6.33985 bits. This could support enlargement in other areas, > e.g. the VQ tables could be enlarged from 4096 to 6472 entries. Perhaps > to make room for wideband codecs :-) > > The same as above might also work for the number of bits used for the > LSP amplitudes, but I am uncertain if that would work for all voices. > > With quantised LSP amplitudes relative to the previous LSP amplitude, > Codec2 stacks quantisation errors on top of each other; from an error > minimisation viewpoint it would be better to quantise all LSP amplitudes > relative to the quantised base frequency, possibly after applying a > predicting factor (e.g. linear or exponential amplitude drop with rising > frequency)? This would give all harmonics with a fixed error relative > to the base frequency. > > The quantisation of the LSP amplitudes is done linearly; but our hearing > is logarithmic. Is it an idea to use a log scale for the LSP amplitudes, > thus achieving more consistently felt rounding/quantisation errors, > basically what G.711 has taught us to work rather well? > > > A few more philosphic points also popped up in my head :- > > > If a voice codec gets more compact, does that mean that it is approaching a > canonical model of speech generation? > > If a voice model captures the physical phenomena of speech production well, > would it be trivial to expand it to a wideband codec, for instance at > 16 kHz, and obtain much better quality? As far as I can tell from the code > there are always 10 harmonics, anything higher is hardly of interest > in making a voice recognisable, but those 10 could also be of use to > a child's voice at 600 Hz. > > While training a codec (effectively looking for that canonical model?) > would it not be helpful to listen to wideband samples? Artifacts should > show up more clearly, and the disruptive work of the in-spectrum sample > rate would not have to end up in the model. > > While training a codec intended for development countries, would it not be > helpful to include sampled sentences from those regions? Remember that > some of the languages include unique sounds, such as clicks. It'd be hard > to judge a language you don't understand though! > > > This is by no means meant as a critique; merely to be thought-provoking > and perhaps lightly inspiring. In Dutch, we have a saying that a fool can > ask more questions than a hundred wise men could answer. I'm happy to > be that fool in this case :) > > > I hope this is useful. > > > Cheers, > > Rick van Rein > OpenFortress / 0cpm > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
