请问声音回声和噪音消除的算法,100分,不够再添

[aha0]

请问有谁知道声音回声和噪音消除的算法,源码最好,哪里找也可以,在线等候

[aha0]

to SnHnBn(大可达) :
就声音回声说说,希望不要只是说说什么取值比较之类的大概,呵呵,
to changzhiguo() :
对于环境要求我基本上不怎么考虑,毕竟不能把这些东西转嫁到用户身上去,那就失去意义了,是不?
感觉大多数声卡都没有回声消除,比如你上碧聊,qq语音聊之类的,都有很大的回声.而绝大多数的语音卡都有回声,噪音处理,但是那是硬件实现的.
我就是想讨论软件算法,而我找了一段时间了,只是找到一些大概的说明,而且绝大多数是DSP,只有"卓联半导体公司(Zarlink)的VEC(语音回声消除)软件算法",号称是:"保证与ITU-T的G.168(2000)数字回声消除器标准兼容",可是我到它公司网页上没找到什么有用的,呵呵,
to laogiang(我爱我家);
希望如此,前一段在哪儿看到的,说中国人的第一个互联网协议快出来了,可是,是什么关于汉字的?这也值得自豪吗?反正我不觉得.
to hugeship2002(flashing)
深有同感,现在我要找什么稍微底层一点的一般都是在国外找,可是说实在的,的确不能象找中文网页,哪个角落都找到,呵呵,
国内搞东西,没有纯粹搞东西的,包括所谓的研究院里面的,都是在"卧薪尝胆",一心想搞个东西出来,然后市场化,然后?当然是大发特发,听说过有人公开过自己的研究成果没有?反正我这个井底之蛙没听过,不过这个说实话,跟国内的环境有关,抄袭的太多了,谁叫中国人信奉"成王败寇"?只要成功了,谁管你抄不抄.

[pkzl888]

其实回声和噪音应该是高频的一种体现,在做回声的时候都会把声音进行所谓的加湿处理,以及反馈处理.如果把声波的某个频段的波滤掉的话，回声就可能会消除(具体实现我可能无法用算法来描述我也不清楚，但是你可以做一个实验，有一个软件叫cooledit的不知道你用过没有,上面有一个消除噪音的功能,你用那个功能对一段声音进行处理,选择高频和噪音接近的哪个波段,结果就会发现在降噪的同时回声也被削弱了)这就说明,回声和噪音其实都是一种相似频段上的声音,只要你找到了哪个频段的波形把它删掉就可能达到目的,当然在此之前肯定要进行一些规范的处理.可能算法就在其中吧.呵呵。

[changzhiguo]

我想说三个问题：

1、由于声卡采样频率的偏差，某台机器上采样N分钟的音频数据在另外一台机器（甚至同一台机器）上以同样的频率回放，其时长不一定就是N分钟,可能会相差很大，如果出现这种情况，通讯的某一端会出现很大的时延

2、声卡录音时可以选择音源，除了microphone外，千万不要选择其他音源，特别是waveout，否则本机回放的声音又会被录下传送给对方，这样对方机器就会产生回音！如果注意到这个问题那么一般情况下是不会有回声的，当然要保持话筒与音箱之间的距离。

3、令人晕倒的是有些恶心的声卡在录音时，其音源选择无法将waveout输出屏蔽！因此本机回放的声音都会被录下来传送给对方从而形成回声！！！这种情况下只有靠软件来处理掉回声了。

[aha0]

我不知道这些高手为什么没有关注,很奇怪的,CSDN上有几种帖子最受欢迎,一个就是发源码的,这是最受欢迎的,(其实,这些源码网上找找多的是),其次就是骂架的(呵呵,比如什么语言对什么语言)这些跟贴的也不少,其他的就是一些什么技巧些了,真正讨论基础技术的很少,有段时间,我甚至不愿上CSDN了,而愿意上驱动开发网站,感觉那儿学的东西还多一点,起码没有这里浮躁,为了个开发工具争的你死我活的,
说实在的,人贵自知,我知道我自己有些底层的东西没有发言权,比如现在我问的这个,但是,我现在是在请教,是在求教,为什么就没有专家出来,这里不是号称全国最大的程序员基地吗?我知道什么协议都不是中国人搞的,但是难道连学人家的都没有学的好的吗?为什么?给我一点信心好不好,让我知道,浮躁的中国除了我等浮躁的人外,还有沉下去的一批!

[laogiang]

许多协议中国还是在搞的。大唐的TD-SCDMA，还有许多ietf的draft还是
有中国人提的。大哥虽然要意识到严重性，但是也不必如此悲观

[hugeship2002]

这个问题我也曾经研究过，其实中国人搞东西很封闭，这种算法，你去国外的论坛上也许会很容易找到（我没找过，只是听说）。语音方面的开发，中国人很不统一，各搞各的，经常几个公司在搞一个相同的东西，很简单的一个东西，搞出来还不公开，结果下一个公司或者研究项目，还得重新来研究。比如去噪的算法就是其中之一，还有一些基本的语音库也是如此。其实公司研究完了不公开倒也罢了，可以说是商业机密；可是高校科研，这些东西也不公开，就让人很奇怪了，总怕别人知道了会赶上自己。

[clarknu]

回声的问题不想多说
关于噪音，一向是比较麻烦的问题，通常是具体情况具体分析，采用针对性比较强的方法，其实，集中在较高的频段只是噪音的一种表现情况而已，的确是很普遍，主要由于硬件的本身噪音和音源以及传输过程的干扰而致，在早期的分立元件收音机当中已经有用模拟的方法处理的了；还有一种形式的噪音属于背景干扰，效果就像你在宴会中听你邻座讲话的时候一样，这种情况比较复杂，计算机目前无法区分有用和无用的信息，一般是将能识别的声强较低的信号分离出来作处理，或者干脆做衰减；另外，对于这种噪声的处理往往采用软硬件结合的方式，从声音采集阶段开始就努力保持好的音质；还有一种是特征比较明显的固定干扰信号，往往在某方面具有周期性等某些特征，可以自己搞一个智能一点的算法处理掉。
以上只是个人的看法，我不是搞多媒体的，只是对模拟电子技术的音响和控制方面略有了解。
大家不要笑我，即使笑我也不要骂我，骂我别让我听到也成..

[opengl3d]

可以看看G.系列的音频编码

[mtome]

可以参考一下现在的语音聊天室程序，对噪音的消除还可以，不过回声还不行：
在OICQ上的语音聊天却刚好相反，没有什么回声，但噪音很大。你可以把他们的源码比较一下。

[wubenqi]

楼主，我在这上面也发过至少三次帖子，我比你惨多了，一个回应的都没有

[wubenqi]

我有一个回音消除的算法，但我不怎么看的懂，你如果感兴趣的话，我到可以发个给你一起研究。

[everwindforce]

"希望如此,前一段在哪儿看到的,说中国人的第一个互联网协议快出来了,可是,是什么关于汉字的?这也值得自豪吗?反正我不觉得."


rfc1922:
Chinese Character Encoding for Internet Messages. HF. Zhu, DY.
Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. March 1996.
^^^^
(Format: TXT=50995 bytes) (Status: INFORMATIONAL)

这个还不叫协议。（注意它的时间）
是清华和中科院联合的一个项目。

[xystus]

G.723.1 G.728 G.729语音编码没有参考价值?
印象中好像是可以抑制噪音和消除回音的呀！
我用过openh323中的开放包，g.723.1回音有些大，但噪音抑制感觉方面还可以！

[lance09]

hehe,学习并关注中..........


多多学习

[aha0]

很感谢各位朋友的关注,看得出,大家很认真的,因为,没有开骂的,呵呵,谢谢.
to pkzl888():
呵呵,我要解决的回声主要是voip上的,主要根源是播放出的又录入了,从我目前所知来说,消除方法是保存播放的一定长度,然后比较录入的,(我现在还只是知其然不知其所以然,呵呵).比如现在很多语音卡上都有选择比较时间的.当然这样的回声肯定跟噪音频率相似,消噪音也自然能消掉一点回声,但估计还是治标不治本.呵呵.
to clarknu(牛5):
谢谢.
to mtome(mailtome) :
怎么我用QQ有很大的回声?而且网上的通信源码,能找到我都看了,没有这方面处理,了不起用个H.323,还自以为很牛,呵呵
to wubenqi(wubenqi):
我的Email是[e-mail],谢谢,共同研究.
to everwindforce(windforce) :
具体什么我也记不清楚了,好像是CSDN的一篇新闻报道,说实在的,我对中国人的自吹自擂早麻木了,也没有了穷根究底的兴趣了,窃以为,与其为别人的空中楼阁鼓掌,还不如自己埋下头来小小的垒块砖.

[everwindforce]

ITU-T G.165/G.168 Echo Cancellers
这个我也不懂,只能帮你这么多了...

[everwindforce]

一片很好的文章,from vcc (vcc.urz.tu-dresden.de)

Hi,
I see in many of the company websites of VoIP specifying Echo cancellers
(ITU-G.165/G.168) standards. When it comes to delay it goes upto 128 msecs.
Now I understand a case where Mobile networks is involved, one can find
larger delays.
It takes lot of MIPS to run Echo cancellers for larger delays. Where do I
get information regarding the DELAY?
And also the necessity of an Echo canceller for say a residential gateway or
an enterprise gateway?

Hari

-----Original Message-----
From: Scott Keagy <[e-mail]>
To: [e-mail] <[e-mail]>
Cc: Hari Krishna Vuppaladhadiam <[e-mail]>; [e-mail]
<[e-mail]>
Date: Wednesday, April 26, 2000 2:58 PM
Subject: Re: Echo Cancellers


>Kevin et al,
>
>feel free to correct me if I'm wrong in the details below....
>
>I added more details to the diagrams to clarify what we're talking
>about.
><see diagrams at bottom>
>
>
>ITU Echo Canceller Requirements
>-------------------------------
>
>ITU-T Recommendation G.131 "Control of Talker Echo" (section 4.1) states
>the following:
>"In general, it is recommended that the active echo control devices
>shall be deployed on all connections which exceed the total one-way
>talker echo transmission path time of 25 ms."
>
>This implies that public phone networks may not provide echo
>cancellation for tail-end hop-off circuits that have up to 50 msec
>round-trip latency.
>
>
>Where echo originates
>---------------------
>Impedance mismatches at 2-wire/4-wire hybrids (transitions from 2-wire
>to 4-wire circuits) can cause signal reflections. The likely spots where
>these hybrids can cause problems for VoIP hop-off scenarios are
>illustrated below. Carrier equipment may not be optimally tuned, or
>customer equipment may not be optimally tuned. In addition to these
>spots, acoustic echoes may occur from the destination speaker/mic
>equipment (i.e. speakerphone or cheap telephone handset).
>
>I submit as proof that not all networks are ideally designed, that I
>frequently call residential locations in India from the U.S. I here my
>own echo on at least half of the conversations, which implies that some
>telco central offices in India have poor hybrid terminations.
>
>
>What a company can do about it
>-------------------------------
>Given the ITU recommendations that support a carrier's right to not
>employ echo cancellers in medium-delay networks (i.e. up to 50 msec
>round-trip), a company employing a VoIP solution has no recourse to
>block the echo other than to use echo cancellers with high delay
>coverage, as illustrated below. A given company can't fix the network
>problems for different calling destinations (i.e. adjust the impedance
>coupling at the hybrid to increase the return loss), but it can take
>personal action to defend the voice quality experienced by its
>employees.
>
>Note that this is an enterprise-centric approach to the problem. A
>carrier-centric approach might be to negotiate with the remote telco to
>fix the problem, so that the local carrier does not get stuck with the
>echo-canceller bill. So high delay echo cancellers may be useful for
>low-end and enterprise products, but not for carrier products. Also note
>that up to 64 msec is sufficient given that all networks are designed
>according to ITU spec.
>
>
>====: 4-wire circuit
>----: 2-wire circuit
>
>**************************************************************************
> ||=====<digital user
>C>
> ||
> ||
><user A>=====<VoIP cloud>===<long delay PSTN>====<PBX>-----<analog user
>B>
> ^ ^
> | |
> | |
> | (signal from A reflected here)
> |
> (High delay echo canceller needed here)
>
>**************************************************************************
>
><user A>=====<VoIP cloud>=====<long delay PSTN>-------<user B>
> ^ ^
> | |
> | |
> | (signal from A reflected here)
> |
> (High delay echo canceller needed here)
>
>***************************************************************************
>
>-Scott
>
>[e-mail] wrote:

[everwindforce]

>>
>> Scott:
>>
>> Thanks for you input to the group on this subject. There seems to be a
>> considerable amount of misunderstanding about echo control with VoIP
networks.
>> I repeat a label your networks below to make some points of discussion:
>>
>> Case 1:
>> <user A>----<VoIP network>----<PSTN>----<mobile network>---<userB>
>>
>> Case 2:
>>
>> <VoIP network>----<PSTN>-------<VoIP network>
>>
>> Case 3:
>>
>> <VoIP network>----<any high delay hop-off to PSTN>
>>
>> In case 1, user A has a four-wire connection to the network and user B
also has
>> a four-wire connection to the network. That is - unless somewhere in the
mobile
>> network or in the PSTN there is some two wire circuits. Unless user A is
using
>> a poor quality speakerphone, there should be no need for any echo
cancellation
>> at all.
>>
>> for case 2, there should also be no need for any echo cancellers unless,
again,
>> the PSTN has been poorly engineered and has two-wire connections
somewhere.
>>
>> For case 3, it the right side of the network has a Media Gateway. At
some point
>> to the right of that gateway there will be a two-four wire hybrid which
will be
>> the source of an echo. The echo would be user a "talker echo".
Therefore, the
>> media gateway has ther responsibility of echo cancelling this echo. This
is
>> typicaly short - as in certainly less than 20 msec. It is true - that
the
>> longer the VoIP network delay, the better the echo canceller in the
network must
>> work. This is why it is important for VoIP networks to manage their
delay
>> downwards as much as possible. To do otherwise causes a) the media
gateway echo
>> canceller to "work harder" than it should have to and b) cause
conversational
>> double-talking that is subjectively annoying even when the echo control
is
>> perfect.
>>
>> The basic misimpression that I see all too often is that people believe
that
>> "station side" or subscriber equipment echo cancellers need to be
deployed at
>> the subscriber or user's equipment. This is, for the most part, untrue.
If it
>> turns out to be true, someone architected their network poorly. Echo
cancellers
>> with long tail coverage are an expensive commitment to poor network
design.
>>
>> If I recall correctly, even with normal characteristic impedances in
cable (free
>> space is faster) a tail circuit across the country will not exceed 20
msecs.
>>
>> Kevin
>>
>> Scott Keagy <[e-mail]> on 04/26/2000 03:48:08 PM
>>
>> To: Hari Krishna Vuppaladhadiam <[e-mail]>
>> cc: [e-mail] (bcc: Kevin Bruemmer/Natural MicroSystems/US)
>> Subject: Re: Echo Cancellers
>>
>> I think there is a good application for high-delay echo cancellers.
>> Consider the following scenarios:
>>
>> <user A>----<VoIP network>----<PSTN>----<mobile network>---<userB>
>> or
>> <VoIP network>----<PSTN>-------<VoIP network>
>> or
>> <VoIP network>----<any high delay hop-off to PSTN>
>>
>> Typical echo cancellers at the edge of the VoIP network (e.g. Cisco
>> routers) only provide 32 msec of coverage. If a hop-off tail circuit has
>> a round-trip delay that exceeds the coverage of the echo canceller (on
>> the outbound edge of the VoIP network), then the additional delay of the
>> VoIP network (100 msec or more usually) exacerbates the echo problem.
>>
>> This is an intractable problem without the use of echo cancellers that
>> have longer coverage ability.
>>
>> -Scott
>>
>> Hari Krishna Vuppaladhadiam wrote:
>> >
>> > Hi,
>> > I am interested in knowing what kind of echo cancellers do we require
in
>> > typical VoIP applications. Is there a requirement for delays greater
than
>> > 64msecs?
>> >
>> > Regards
>> > Hari
>>
>> --
>> =======================================================
>> Scott Keagy, CCIE #3985
>> Senior Networking Consultant
>> SK Networks, Inc. mailto:[e-mail]
>> =======================================================
>
>--
>=======================================================
> Scott Keagy, CCIE #3985
> Senior Networking Consultant
> SK Networks, Inc. mailto:[e-mail]
>=======================================================

[everwindforce]

to aha0:
你指的是这一篇吗?
1922 Chinese Character Encoding for Internet Messages. HF. Zhu, DY.
Hu, ZG. Wang, TC. Kao, WCH. Chang, M. Crispin. March 1996. (Format: TXT=50995 bytes) (Status: INFORMATIONAL)
好像是清华和中科院联合做的一个项目，不过不是标准。
（请注意时间）

[aha0]

谢谢各位的参与,谢谢,小弟的EMail是[e-mail],如果有什么可以效劳的,请不要客气,谢谢.现在结贴