Re: Codec Conversion
Steve Underwood <steveu <at> coppice.org>
2010-08-07 02:42:22 GMT
On 08/07/2010 03:15 AM, Jeff Brower wrote:
>>>>>> 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
>>>>>>> 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.
>>>>>> 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
>>>>> 'robotic' sound. With advent of MELPe, anyone needing bitrates 2400 or less should not be using LPC10.
>>>> MELPe is patent encumbered,
>>> Not if used for govt/defense purposes. For commercial-only purposes, TI will waive royalty fees if
their chip is
>>> 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
> implementation they did under contract to NSA around 2001. TI has patent rights on 2400 bps, TI + Microsoft
> 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
> 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
>> 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
> 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",
> have put one TNETV3010 chip on there, even smaller than the Mindspeed and without the heat sink, and had
> 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
>>> might be a basis for a 2400 bps open source codec. But enormous improvement would be needed to come close
>> 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
> 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
> 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.
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
asterisk-users mailing list
To UNSUBSCRIBE or update options visit: