Hi,
On 24-10-12 14:10, Bruce wrote: >> In the list I got, the VQ (used by the 1200 bps codec) where at the same >> place of the LSPs for the 1400 bps codec. Would you place them higher? > My (very imperfect) understanding is that corrupting an LSP is like > distorting one filter tap while corrupting VQ can effect more than one. > Also, David noted that the first VQ index is the most sensitive. I'm sorry. It looks like some of our messages crossed eachother. (I sometimes write my email offline on the train which means they get posted a couple of hours later). Concerning the order of what to protect first, This is what would apply for the 1200 bps codec: - voicing bits (4 bits) - energy+Wo bits (16 bits) - VQ (27 bits) - spare bit (1 bit) (there are no LSPs on the 1200 bps codec, only VQ bits). The voice-bits clearly have top priority; so the remaining 20 bits that can be given FEC protection would then have to be chosen from either the Energy+Wo or VQ group. For me, it does does have to be "all or nothing". Perhaps we can protect some part of the Energy+Wo bits and part of the VQ bits. It this makes more sence, no problem. Perhaps a stupid question, would it make sence to use a different sceme for voiced or unvoiced frames? But, how do you then handle timeslots where there are both voiced and unvoiced 10-ms frames? > > Now, for the 1200 bps codec, the situation is relative simple: - if > there is no sync pattern, there is 48 bits of data and 48 bits of FEC, > so that is easy. - if there is a sync pattern, it's only possible to > protect up to 24 bits. > > Maybe I don't understand. Are you laboring under the misconception that > FEC must duplicate the data? Convolutional codes, even such old things > as CRC, will expand the data at less than a 1:1 ratio. I think you can > assume that we're using a more modern code like LDPC or turbo codes. Remember that we are using golay and hamming, because of the availability of open source code and we are pretty sure there are no patents applied here. Bill can probably elaburate better on that. If you take the example of golay, I have sofar only seen implementation of golay(12,24), i.e. a FEC of 1/2. If you take the example of D-STAR, they apply FEC on the voice part with a rate of 2/3 (per 20 ms frame: 48 bits become 72 bits), they just do a FEC 1/2 on two out of four of the 12-bit blocks: 2 * (12+12) + 2 * (12) = 72 bits. (At least, this is how I read it from the DTMF decoding software for the D-STAR repeaters). If my impression is right, this is actually pretty logical: If you would use a trick to reduce a (12,24) golay code to (12,18) (e.g. something simular to puncturing); this would impact the ability to decode errors on the FEC system, this equality for all bits in the golay block. So, if you would do (say) four times (12,18) (i.e. protect 48 bits with a 2/3 FEC and create 72 bits), you would apply FEC protection on all the bits; but with a limited protective power. If you do golay(12,24) on the first two blocks and no FEC on the latter two; you apply FEC on only half the information and no FEC on the other half. For codec2; this approach does make sence as certain information is simply more important then other. But, again, this is based on how I understand FEC. Anybody, feel free to correct me if I am wrong! > Thanks > Bruce Chééééério! Kristoff - ON1ARF ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
