Bruce,
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?
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.
Based on the information I got, that would be 20 bits ("voiced" and
"energy or wo") plus 4 for the VQ information (once two MSB bits for one
VQ-index and one MSB bit for the two other VQ indeces).
I don't know the codec2 format in such a detail to determine if other
combinations would be better.
Thanks for doing to interleaving stuff.
I think it would be nice if you would either post a message in the list
to post some blog-entry to explain what you have done. It might be
interesting for other people to learn how you do this.
Chéééério!
Kristoff - ON1ARF
On 23-10-12 12:08, Bruce Perens wrote:
> Sorry. I mean that VQ is probably sensitive. Will hack on interleave code.
>
> Bruce Perens<[email protected]> wrote:
>
>> Remember VQ at 1200.
>>
>> Kristoff Bonne<[email protected]> wrote:
>>
>>> Hi all,
>>>
>>>
>>> For the development of the 2400 bps modem, we also need a FEC system
>>> that goes with it.
>>>
>>>
>>>
>>> Please find below a proposal for this.
>>> If somebody has any ideas or remarks about this, feel free to reply.
>>>
>>>
>>>
>>> Concidering,
>>>
>>> * the "production" codec2 gmsk modem specification is based on a number
>>> of different "profiles". These are "typical usage" senarios which match
>>> a certain choice of features provided by them mode. The goal is to
>>> reduce the complexity of the modem as it only needs to implement the
>>> features specified for this particular profile.
>>> Current profiles are "local communication" and "DX".
>>>
>>> * The "local communication" profile is designed for -as its name
>>> implies- local communication and has the least complexity. One of the
>>> elements of this profile is that everything related for FEC (forward
>>> error correction) and interleaving (changing the order of the bits to
>>> make it less vulnerable to burst errors) is only applied INSIDE the 40
>>> ms timeslot.
>>>
>>> * For reasons of syncronisation, a 24 bits "sync/type-of-frame" pattern
>>> has to be inserted into the stream and be repeated. This is send at
>>> least once per eight 40ms timeslots. If no sync/type-of-frame is send,
>>> the space can be used for voice (in this case, voice FEC).
>>> Future options of the specification will provide the possibility to
>>> encapsulate data into that place of the stream. However, the current
>>> version of the specification does not offer this possibility.
>>>
>>>
>>> * A 40 ms timeslot for a 2400 bps modem is equivalent to 96 bits. The 96
>>> bit structure depends on two factors:
>>> -> Is there a sync/type-of-frame pattern present in that timeslot
>>> -> Is the 1200 or 1400 bps voice codec used?
>>>
>>> The structure can be found further down this document.
>>>
>>>
>>>
>>> * A codec2 frame is based on a 40 ms timeslot, containing information
>>> about four 10 ms frames. It has the following structure:
>>>
>>> 1/ For the 1400 bps voice codec
>>> - 1 "voiced" bit for frame 0
>>> - 1 "voiced" bit for frame 1
>>> - 8 "energy or WoE" bits for frames 0 and 1
>>> - 1 "voiced" bit for frame 2
>>> - 1 "voiced" bit for frame 3
>>> - 8 "energy or WoE" bits for frames 2 and 3
>>> - 36 "LSP" bits for frames 0 up to 3
>>> Total: 56 bits
>>>
>>> The 36 LSP bits represent 10 values, using between 2 and 4 bits for
>>> every values.
>>>
>>>
>>> 2/ For the 1200 bps voice codec
>>> - 1 "voiced" bit for frame 0
>>> - 1 "voiced" bit for frame 1
>>> - 8 "energy+wo" bits for frames 0 and 1
>>> - 1 "voiced" bit for frame 2
>>> - 1 "voiced" bit for frame 3
>>> - 8 "energy+wo" bits for frames 2 and 3
>>> - 27 "LSP" bits for frames 0 up to 3
>>> - 1 "spare" bit
>>> Total: 48 bits
>>>
>>> The 27 bits "LSP" bits can be broken down into 3 x 9-bit VQ indexes.
>>>
>>>
>>>
>>>
>>> * Not all information in the codec2 voice frame is equaly important.
>>> Corrupting certain bits produces more audiable error then other bits.
>>> The importance of the different groups of bits is as follows (in
>>> descending order):
>>> - voicing bits
>>> - energy+Wo bits
>>> - MSB part of the LSPs
>>> - remaining part of the LSPs
>>> - spare bit
>>>
>>>
>>> * The current FEC systems can be applied:
>>> - golay(24,12,8): this uses 12 FEC bits to protect 12 data bits; with
>>> the ability to correct up to 3 bits and detect up to 7 bit errors
>>> (seehttp://en.wikipedia.org/wiki/Binary_Golay_code)
>>>
>>> - hamming(8,4,4): this uses 4 FEC bits to protect 4 data bits; with the
>>> ability to correct up to 1 bit and detect up to 2 bit errors
>>> (see
>>> http://en.wikipedia.org/wiki/Hamming_code#Hamming.287.2C4.29_code_with_an_additional_parity_bit)
>>>
>>>
>>> These FEC systems are chosen because they operate a relative small block
>>> of bits (as all FEC is done inside a 40 ms timeframe), free of patents
>>> and opensource source code for it is available.
>>>
>>>
>>>
>>> As a result, the following 96 bit frame-structures are defined:
>>>
>>> 1/ for the 1200 bps voice codec:
>>> 1a/ for a timeslot WITHOUT sync/type-of-frame pattern:
>>> - 48 bits codec2 voice
>>> - 48 bits FEC
>>>
>>> In this senario, four times golay(24,12,8) is applied on the complete
>>> codec2 frame.
>>>
>>>
>>> 1b/ for a timeslot WITH sync/type-of-frame pattern:
>>> - 24 bits sync/type-of-frame
>>> - 48 bits codec2 voice
>>> - 24 bits FEC
>>>
>>> In this senario, two times golay(24,12,8) is applied, with the ability
>>> to protect 24 bits. The following bits are be protected:
>>> - all 4 voiced bits
>>> - all 16 energy+wo bits
>>> - 4 MSB bits of LSPs (Which ones? Is there a preference for certain LSPs).
>>>
>>>
>>> 2/ for the 1400 bps voice codec:
>>> 2a/ for a timeslot WITHOUT sync/type-of-frame pattern:
>>> - 56 bits codec2 voice
>>> - 40 bits FEC,
>>>
>>> In this senario,
>>> . three times golay(24,12,8) is applied, with the ability to protect 36
>>> bits.
>>> . in addition, once hamming(8,4,4) is applied, with the ability to
>>> protect 4 bits
>>>
>>> The following bits are be protected
>>> - all 4 voiced bits
>>> - all 16 energy+wo bits
>>> - 20 MSB bits of LSPs (2 bits for every of the 10 values?)
>>>
>>>
>>> 2b/ For a timeslot WITH sync/type-of-frame pattern:
>>> - 24 bits sync/type-of-frame
>>> - 56 bits codec2 voice
>>> - 16 bits FEC
>>>
>>> In this senario,
>>> - once golay(24,12,8) is applied, with the ability to protect 12 bits
>>> - in addition, one hamming(8,4,4) is applied, with the ability to
>>> protect 4 bits.
>>>
>>> Firstly, the golay(24,12,8) is applied to the following bits:
>>> - all 4 voiced bits
>>> - the 8 energy/wo bits that apply to the first two codec2 frames of the
>>> (4 frame) codec2 timeslot
>>>
>>> For the 4 remaing FEC bits (the hamming(8,4,4) block), I would like to
>>> propose this:
>>> The hamming(8,4,4) is applied NOT 4 of the other eight energy+wo bits
>>> (for the 3th and 4th frame), but 4 of the MSBs of the LSPs.
>>>
>>> The reason for this is as follows:
>>> - the golay FEC decoding not only provides the ability to correct
>>> errors; but also check on the amount of errors found.
>>>
>>> - This means that the decoding process has knowledge of the quality of
>>> the link
>>>
>>> - If the decoding noticed that the quality is bad (high BER); the FEC
>>> decoder can decide that -as the 3th and 4th frame (where the enery+wo
>>> bits are not well protected) are going to be corrupted anyway- it will
>>> ignore these last frames frames and put a copy of first two frames
>>> (which do have FEC applied) in these frames.
>>>
>>> Based on that, it makes more sence to use the 4 FEC bits of the
>>> additional hamming(8,4) block to protect a part of the LSP-information
>>> as this applies for all 4 frames of the 40 ms timeslot.
>>>
>>>
>>>
>>>
>>> Please let me know if you have any remarks or questions.
>>>
>>> 73 - 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
>> ------------------------------------------------------------------------------
>> 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
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
