[asterisk-users] Codec Conversion

[Steve Underwood]

  On 08/07/2010 03:15 AM, Jeff Brower wrote:
> Steve-
>
>>>>>> El 05/08/10 14:50, Tim Nelson escribió:
>>>>>>> ----- "michel freiha"<michofr at gmail.com>    wrote:
>>>>>>>> Dear Sir,
>>>>>>>>
>>>>>>>> I tried to convert ilbc to ulaw and get the same result...Bad Voice
>>>>>>> Quality
>>>>>>>> Regards
>>>>>>>>
>>>>>>> Again, iLBC is poor quality to begin with. You can't take a poor audio
>>>>>>> sample and make it better by converting it to a codec with better
>>>>>>> 'resolution'. An audio sample full of robot voice is going to sound
>>>>>>> like the same robot voice even if you transcode it to a better quality
>>>>>>> codec, whether that is G.729, G.711u, or the latest 'HD Voice' codecs.
>>>>>>>
>>>>>>> --Tim
>>>>>> This just made me remember some comment on the iax.conf sample file...
>>>>>>
>>>>>> disallow=lpc10            ; Icky sound quality...  Mr. Roboto.
>>>>> LPC10 is a very old codec, from early 1980s.  LPC10 doesn't do a good job with pitch detection so it tends to have
>>>>> a
>>>>> 'robotic' sound.  With advent of MELPe, anyone needing bitrates 2400 or less should not be using LPC10.
>>>>>
>>>>> -Jeff
>>>> MELPe is patent encumbered,
>>> Not if used for govt/defense purposes.  For commercial-only purposes, TI will waive royalty fees if their chip is
>>> used
>>> in the product.  It would have been nice if Digium had considered the many advantages of using a DSP pioneer such as
>>> TI before putting a Mindspeed chip on their TC400B card.
>> I think all the IP for MELP is now in the hands of Compandent, and TI no
>> longer has the ability to waive royalties.
> That is not correct.  Compandent has filed copyrights on certain files associated with a C549 chip assembly language
> implementation they did under contract to NSA around 2001.  TI has patent rights on 2400 bps, TI + Microsoft on 1200
> bps, and TI + Microsoft + Thales Group on 600 bps.  Microsoft's IP came about as a result of acquiring a company
> called SignalCom around 2001.  If the noise pre-processor is used, then there is some AT&T IP.  To verify this, you
> can search dsprelated.com (specifically, look for posts discussing this issue on comp.dsp), and you can also read the
> "Compandent IPR" section of the MELPe Wikipedia page
> (http://en.wikipedia.org/wiki/Mixed_Excitation_Linear_Prediction).  That section was authored by the Compandent's
> founder, Oded Gottesman.  Oded is a super sharp, very hard working guy.
>
> Compandent also claims a copyright on some C code in the file melp_syn.c (synthesis filter).  I have read discussions
> by DSP experts indicating the copyrighted section of code can be implemented in alternative ways, but Oded may say
> that's not accurate.
That guy is PITA. He must have driven a lot of people away from MELP by 
the way he acts. He really annoys the regulars in the comp.dsp group by 
posting astroturf questions about MELP, and giving astroturf replies 
about how fantastic it is. That probably shapes a lot of my attitude to 
MELP. :-)
>> Either way, government use
>> and use with TI silicon are two niches that might work out well, and
>> everything else is a problem for several more years. If you are going to
>> pay royalties for a low bit rate codec, IMBE is probably a better option.
> I would disagree because IMBE source is not available.  MELPe source is available and can be downloaded online.
Depends what you mean by available. IMBE is patented, just like MELP is 
patented. Licence either, and implementations are available. IMBE has 
the great benefit of being widely used for commercial and amateur low 
bit rate channels. For example, amateur radio uses IMBE - an anomaly 
which is one of the drivers for David Rowe's work on an open low bit 
rate codec. Transcoding at low bit rates is a disaster, so using a codec 
you won't need to transcode is a big plus.


>> TI is a good option, but what do you have against Mindspeed? Choosing a
>> good option for this kind of card is mostly about managing the patent
>> licence fees. I assume Mindspeed gave Digium the best option for doing
>> that, within Digium's volume constraints.
> My understanding in talking to Digium engineers at Globalcom and other trade shows back in 2006 is they were worried
> about interfacing the TI TNET series devices over the PCI bus.  They would have needed an FPGA with some non-trivial
> logic programming, so I understand their decision.  But if they had got past their FPGA "writer's block", they could
> have put one TNETV3010 chip on there, even smaller than the Mindspeed and without the heat sink, and had twice the
> channel capacity as they do now.
TI have had DSP chips with a PCI interface for years, so that 
explanation doesn't make a lot of sense. Of course, these days you need 
a PCI-E interface. I'm not so sure about the status of those in DSP chips.
>> so there is still a place for LPC10 [...]

> e>>  I haven't seen an LPC10 implementation with MOS higher than 2.5.  Due to its age and expiration of patents, LPC10
>>> might be a basis for a 2400 bps open source codec.  But enormous improvement would be needed to come close to MELPe
>>> performance.
>>>
>>>
>> MELPe is definitely a compandent thing, and TI cannot waive fees for
>> that. MELP and MELPe are derived from LPC10. Any attempt to improve
>> LPC10 would take you down a similar road, though you would need to skirt
>> around the patents.
> Again, not correct.  Suggest to research the many online independent sources, or contact NSA (who initiated the
> overall MELPe effort in the 1990s, in response to a need to significantly improve over LPC10) and who can give you a
> complete IP list.
>
>> Do you really consider MELPe to be an enormous improvement over LPC10?
>> Its still pretty lousy compared to a number of options at about 5kbps,
>> and RTP overheads mean the gain from going lower than 5k isn't that big.
>> The main reason LPC10 and MELPe offer a low bit rate in RTP is the
>> minimum packet you can pack 22.5ms frames into sanely is a 90ms one.
> In MOS terms, yes.  In VoIP terms, I agree it's not clear cut.  At 2400 bps, a 90 msec packet would be 27 payload
> bytes.  For IP/UDP/RTP usage, that much delay could well be counterproductive.  Places where I have seen MELPe
> effectively used for VoIP include applications where multiple channels are sent in one packet stream, non-Ethernet
> based channels (much less overhead, for example low bandwidth satellite connections), and combining voice and
> associated data into payloads.
>
>> 90ms RTP *really* cuts the overheads, compared to the more typical 20ms
>> or 30ms packets used for G.729.
>>
>> As others have mentioned, David Rowe is working on a modern 2400bps
>> codec. He did a burst of work some time ago, and then put it aside while
>> busy with other things. He recently told me he is restarting the work,
>> and he wants to get that codec into good shape before the end of this year.
> Yes, it's an ambitious project!  I've read about what David's trying to do and I hope he is successful.
Regards,
Steve