I am searching for a Fixed Point C implementation of G.728 codec.
Can anyone point me to it's free version or sell it to me?
Thanks.

i...@gmail.com wrote:

> I am searching for a Fixed Point C implementation of G.728 codec.
> Can anyone point me to it's free version or sell it to me?

That depends on what you mean as 'free'. I am sure I have seen freely 
downloadable fixed point code, but you cannot actually use G.728 in a product 
without licensing it due to patented algorithms.

Anyway, G.728 is not that great overall. It has very high CPU requirements, and 
other (real) free codecs have as good or better quality.

-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Phil Frisbie, Jr. wrote:
> i...@gmail.com wrote:
> 
>> I am searching for a Fixed Point C implementation of G.728 codec.
>> Can anyone point me to it's free version or sell it to me?
> 
> That depends on what you mean as 'free'. I am sure I have seen freely 
> downloadable fixed point code, but you cannot actually use G.728 in a 
> product without licensing it due to patented algorithms.

Are you sure about that? Can you quote any relevant patents? I think 
G.728 is pretty neat, so it seems like the ideas it uses should have 
been patentable.

Unencumbered source code has existed for G.728 for a long time. It uses 
a few floats, but those could easily be eliminated. You can find it 
easily by googling "G.728 source.code". I've never tried to use it for 
more than anything but playing, because I don't know its real status.

> Anyway, G.728 is not that great overall. It has very high CPU 
> requirements, and other (real) free codecs have as good or better quality.

That rather depends on what you need. G.728 has a delay of only 2.5ms. 
If you need that kind of low latency, I don't know of anything to match 
the performance of G.728. These days, with things moving to VoIP, such 
low latencies are not so important, and G.728 has kinda fallen by the 
wayside.

Regards,
Steve

Steve Underwood wrote:

> Phil Frisbie, Jr. wrote:
> 
>> That depends on what you mean as 'free'. I am sure I have seen freely 
>> downloadable fixed point code, but you cannot actually use G.728 in a 
>> product without licensing it due to patented algorithms.
> 
> Are you sure about that? Can you quote any relevant patents? I think 
> G.728 is pretty neat, so it seems like the ideas it uses should have 
> been patentable.

http://www.bell-labs.com/news/1997/april/29/1.html (Lucent Technologies 
announces the availability of licenses for its patents related to G.723.1, 
G.728, G.729 and G.729A)

http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_18/Docs/PDF/SP-020635.pdf (The chart 
shows that G.728 is 'licensable on Reasonable and Non-Discriminatory terms')

http://www.eetimes.com/article/showArticle.jhtml?articleId&806381 (CableLabs 
did not pick G.728 for its initial VoIP spec because of the per line license fee)

US Patent 6,834,293 (covers the fixed point version of G.728)

This is all I could find in 5 minutes on Google ;)

> Unencumbered source code has existed for G.728 for a long time. It uses 
> a few floats, but those could easily be eliminated. You can find it 
> easily by googling "G.728 source.code". I've never tried to use it for 
> more than anything but playing, because I don't know its real status.

Yes, the availability of 'unencumbered' source code is very misleading to many 
developers that do not understand the current state of patents.

-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Phil Frisbie, Jr. wrote:
> Steve Underwood wrote:
> 
>> Phil Frisbie, Jr. wrote:
>>
>>> That depends on what you mean as 'free'. I am sure I have seen freely 
>>> downloadable fixed point code, but you cannot actually use G.728 in a 
>>> product without licensing it due to patented algorithms.
>>
>>
>> Are you sure about that? Can you quote any relevant patents? I think 
>> G.728 is pretty neat, so it seems like the ideas it uses should have 
>> been patentable.
> 
> 
> http://www.bell-labs.com/news/1997/april/29/1.html (Lucent Technologies 
> announces the availability of licenses for its patents related to 
> G.723.1, G.728, G.729 and G.729A)
> 
> http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_18/Docs/PDF/SP-020635.pdf 
> (The chart shows that G.728 is 'licensable on Reasonable and 
> Non-Discriminatory terms')
> 
> http://www.eetimes.com/article/showArticle.jhtml?articleId&806381 
> (CableLabs did not pick G.728 for its initial VoIP spec because of the 
> per line license fee)
> 
> US Patent 6,834,293 (covers the fixed point version of G.728)
> 
> This is all I could find in 5 minutes on Google ;)
> 
>> Unencumbered source code has existed for G.728 for a long time. It 
>> uses a few floats, but those could easily be eliminated. You can find 
>> it easily by googling "G.728 source.code". I've never tried to use it 
>> for more than anything but playing, because I don't know its real status.
> 
> 
> Yes, the availability of 'unencumbered' source code is very misleading 
> to many developers that do not understand the current state of patents.
> 
That much is easy to find, but really doesn't say a lot. Those vague IPR 
statements are everywhere, with nothing to back them up in most cases. 
The ITU patent database is a mess. People put claims of IPR in their 
database, but trying to find out which patents they are claiming can be 
hard. Why doesn't the ITU demand patent numbers when claims are made? 
Often the claim is totally spurious. This might be something only 
vaguely possibly relevant, or they might be something that was a week 
away from expiry the day the claim was put into the ITU database. I find 
that database is almost useless.

G.728 dates back to the late 1980s. Outside the US I'm pretty sure most 
relevant patents essential to it must have expired. In the US, the 20 
year life of patents might mean some patents are still. 6,834,293 
doesn't seem relevant. It seems to be merely a non-essential short cut, 
which I don't think the widely available code uses. You have to be 
careful to separate useful patents from essential ones. Often the merely 
useful ones are US only, since they are algorithmic speedups, which most 
countries won't grant patents for.

Quickly googling for G.728 and patents doesn't really get you very far.

Regards,
Steve

Steve Underwood wrote:

> That much is easy to find, but really doesn't say a lot. Those vague IPR 
> statements are everywhere, with nothing to back them up in most cases. 
> The ITU patent database is a mess. People put claims of IPR in their 
> database, but trying to find out which patents they are claiming can be 
> hard. Why doesn't the ITU demand patent numbers when claims are made? 
> Often the claim is totally spurious. This might be something only 
> vaguely possibly relevant, or they might be something that was a week 
> away from expiry the day the claim was put into the ITU database. I find 
> that database is almost useless.

Tell me about it! ETSI is almost as bad with their 'Essential, or potentially 
Essential, IPRs' list. Now, that list DOES contain patent numbers, but they are 
still 'potential' patents. For THREE months I have been in contact with three 
large companies attempting to clarify patents concerning GSM 06.20 (GSM Half 
Rate), and so far they have blown me off! You see, I am asking them to tell me 
WHERE in the reference source code they have patented algorithms. Only one 
company has replied to me, and then it was to ask me WHY I wanted to know. But 
when I told them I was working for a client that wanted a patent free variation 
of GSM-HR they stopped replying......That reminds me...Time for another round of 
emails...

-- 
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com

Phil Frisbie, Jr. wrote:
> Steve Underwood wrote:
> 
>> That much is easy to find, but really doesn't say a lot. Those vague 
>> IPR statements are everywhere, with nothing to back them up in most 
>> cases. The ITU patent database is a mess. People put claims of IPR in 
>> their database, but trying to find out which patents they are claiming 
>> can be hard. Why doesn't the ITU demand patent numbers when claims are 
>> made? Often the claim is totally spurious. This might be something 
>> only vaguely possibly relevant, or they might be something that was a 
>> week away from expiry the day the claim was put into the ITU database. 
>> I find that database is almost useless.
> 
> 
> Tell me about it! ETSI is almost as bad with their 'Essential, or 
> potentially Essential, IPRs' list. Now, that list DOES contain patent 
> numbers, but they are still 'potential' patents. For THREE months I have 
> been in contact with three large companies attempting to clarify patents 
> concerning GSM 06.20 (GSM Half Rate), and so far they have blown me off! 
> You see, I am asking them to tell me WHERE in the reference source code 
> they have patented algorithms. Only one company has replied to me, and 
> then it was to ask me WHY I wanted to know. But when I told them I was 
> working for a client that wanted a patent free variation of GSM-HR they 
> stopped replying......That reminds me...Time for another round of emails...
> 
I worked on 06.20 (well, not actually on 06.20, but on adapting a 
preliminary version of it for another purpose). As an employee of 
Motorola I didn't need to care about patent issues, since we either 
owned any patents or fully expected we could cross licence them with no 
hassle. I was amazed to see later just how many people claim a piece of 
the pie in the ETSI documentation. Its a different world when you are 
inside a big company. The feeding frenzy on patentable ideas for voice 
coding in the late 80s and early 90s was just amazing, and very very sad.

Most of 06.20 dates from about 1991/1992, though the final bells and 
whistles to tweak up the quality were more like 1994/1995. Patents on 
the 1991 stuff should have expired by now in most countries (i.e. 
anywhere but the US). The final bells and whistles probably include some 
patented things, and those probably have a few years to go.

The ETSI reference code for 06.20 is incredibly slow. On a good DSP it 
takes something 15MIPs to encode and 3M to decode. Lets says 100MIPs 
total for a Pentium. It shouldrun a lot lot faster than that reference code.

06.20 was a great codec for its time. You can slow it down to 30ms 
blocks, and still get good quality at about 4kbps. AMR is a better 
solution today, though.

Regards,
Steve