DSPRelated.com
Forums

Separation of speech from multiple speakers speaking in different microphones connected to a mixer

Started by rajesh May 2, 2008
On 6 Mai, 23:32, "markt" <tak...@pericle.com> wrote:
> Is it > worth investigating, particularly with this problem? &#4294967295;Yes, and it even > works, in spite of complaints to the contrary in this thread.
Some quotes from http://en.wikipedia.org/wiki/Independent_component_analysis: A) "Independent component analysis (ICA) is a computational method for separating a multivariate signal into additive subcomponents" What task ICA is supposed to do. Always good to know. B) "An important note to consider is that if N sources are present, at least N observations (i.e., microphones) are needed to get the original signals." This basically disqualifies ICA as a tool for the cocktail party problem - and yes, that *is* mentioned as one application for ICA in that article. If you need at least as many mics as there are people, then you can just as well crowd the hall with mics and track any conversation on the closest mic. No need for ICA. C) "Most ICA methods are not able to extract the actual number of source signals, the order of the source signals, nor the signs or the scales of the sources." Contemplate that one for a bit, particularly in view of quote A) at the top: "Most" ICA methods can't do the job ICA is supposed to do! Mind you, in line with the great academic tradition, the word 'most' is here used in one of two functions: 1) No working algorithm has yet been found, but the author is wise enough not to use the term 'all' as in 'all ICA methods fail.' 2) Those ICA methods which don't fail, work in highly idealized situations. The quotes A)-C) above are enough to let the experienced data analyst understand that ICA for all intents and purposes is a university funding generator rater than an operational analysis tool. As somebody already said in this thread, the skill to spot idealized test conditions is a valuable one, when looking for usable (or even working) methods. Rune
On May 7, 12:22 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 6 Mai, 23:32, "markt" <tak...@pericle.com> wrote: > > > Is it > > worth investigating, particularly with this problem? Yes, and it even > > works, in spite of complaints to the contrary in this thread. > > Some quotes from > > http://en.wikipedia.org/wiki/Independent_component_analysis: > > A) "Independent component analysis (ICA) is a computational method > for separating a multivariate signal into additive subcomponents" > > What task ICA is supposed to do. Always good to know. > > B) "An important note to consider is that if N sources are present, > at least N observations (i.e., microphones) are needed to get > the original signals." > > This basically disqualifies ICA as a tool for the cocktail party > problem - and yes, that *is* mentioned as one application > for ICA in that article. If you need at least as many mics as > there are people, then you can just as well crowd the hall with > mics and track any conversation on the closest mic. No need > for ICA. > > C) "Most ICA methods are not able to extract the actual number of > source signals, the order of the source signals, nor the signs > or the scales of the sources." > > Contemplate that one for a bit, particularly in view of > quote A) at the top: "Most" ICA methods can't do the job > ICA is supposed to do! Mind you, in line with the great > academic tradition, the word 'most' is here used in one > of two functions: > > 1) No working algorithm has yet been found, but the author > is wise enough not to use the term 'all' as in 'all ICA > methods fail.' > > 2) Those ICA methods which don't fail, work in highly > idealized situations. > > The quotes A)-C) above are enough to let the experienced > data analyst understand that ICA for all intents and > purposes is a university funding generator rater than an > operational analysis tool. > > As somebody already said in this thread, the skill to spot > idealized test conditions is a valuable one, when looking > for usable (or even working) methods. > > Rune
hi, I have used PCA for face recognition and the performance wasnt that bad . Is this same as ICA that you are talking about?
On 7 Mai, 09:28, rajesh <getrajes...@gmail.com> wrote:
> On May 7, 12:22 pm, Rune Allnor <all...@tele.ntnu.no> wrote: > > > > > > > On 6 Mai, 23:32, "markt" <tak...@pericle.com> wrote: > > > > Is it > > > worth investigating, particularly with this problem? &#4294967295;Yes, and it even > > > works, in spite of complaints to the contrary in this thread. > > > Some quotes from > > >http://en.wikipedia.org/wiki/Independent_component_analysis: > > > A) "Independent component analysis (ICA) is a computational method > > &#4294967295; &#4294967295; for separating a multivariate signal into additive subcomponents" > > > What task ICA is supposed to do. Always good to know. > > > B) "An important note to consider is that if N sources are present, > > &#4294967295; &#4294967295; at least N observations (i.e., microphones) are needed to get > > &#4294967295; &#4294967295; the original signals." > > > This basically disqualifies ICA as a tool for the cocktail party > > problem - and yes, that *is* mentioned as one application > > for ICA in that article. If you need at least as many mics as > > there are people, then you can just as well crowd the hall with > > mics and track any conversation on the closest mic. No need > > for ICA. > > > C) "Most ICA methods are not able to extract the actual number of > > &#4294967295; &#4294967295; source signals, the order of the source signals, nor the signs > > &#4294967295; &#4294967295; or the scales of the sources." > > > Contemplate that one for a bit, particularly in view of > > quote A) at the top: "Most" ICA methods can't do the job > > ICA is supposed to do! Mind you, in line with the great > > academic tradition, the word 'most' is here used in one > > of two functions: > > > 1) No working algorithm has yet been found, but the author > > &#4294967295; &#4294967295;is wise enough not to use the term 'all' as in 'all ICA > > &#4294967295; &#4294967295;methods fail.' > > > 2) Those ICA methods which don't fail, work in highly > > &#4294967295; &#4294967295;idealized situations. > > > The quotes A)-C) above are enough to let the experienced > > data analyst understand that ICA for all intents and > > purposes is a university funding generator rater than an > > operational analysis tool. > > > As somebody already said in this thread, the skill to spot > > idealized test conditions is a valuable one, when looking > > for usable (or even working) methods. > > > Rune > > hi, > &#4294967295; &#4294967295; I have used PCA for face recognition and the performance wasnt > that bad . > > &#4294967295; &#4294967295;Is this same as ICA that you are talking about?
No. While the computational methods involved might be similar, the task to be solved is different. ICA takes an arbitrary signal as input and is supposed to separate it into its linear components. Pattern recognition methods take a signal as input and test how well it matches some criterion. The difference might seem superfcial at first glanc, but the implications are huge: Pattern *matching* is a near-trivial task. Finding *good* patterns that represent faces well and detect them robustly may or may not be trivial. Assuming such patterns can be found, mathching the signal to the patterns is easy. Separating a linar sum ito its 'true' components is not at all easy: Given f(t1)+g(t1) = 5 f(t2)+g(t2) =10 find the functions f(t) and g(t). This is, in effect, the task ICA is supposed to solve. Don't know 'bout you, but I wouldn't touch that sort of thing with a red-hot poker. Rune
>Sorry..I am a rookie here... I want to know what is the difference >between > > 1. signals from two ppl from two different microphones(not present >in the same scene) mixed linearly > > 2. two ppl's speech(spoken simultanously) recorded on same >microphone .(does this resemble cocktail party!). > > I dont see any difference between these two problems. If i am wrong >then what is the difference? > >regards >Rajesh >
Are you saying that the recordings are mixed after being spoken into the microphone in the first? The "cocktail party problem" is simply a mixture of signals, though typically you assume both speakers are in the same scene when using the room analogy. In general, the biggest difference between these two setups, assuming the answer to my first question is a "yes," is that each speaker,s recording will have independent noise/distortion. In the latter, both speakers are going into the same receiver, and hence both are affected by the same noise/distortion. Mark
>This basically disqualifies ICA as a tool for the cocktail party >problem - and yes, that *is* mentioned as one application >for ICA in that article. If you need at least as many mics as >there are people, then you can just as well crowd the hall with >mics and track any conversation on the closest mic. No need >for ICA.
This is a common misconception/misinterpretation of what the statement means. If you read a bit deeper into the ICA methods, once you have ordered samples, i.e., a time series, the "more observations than sources" requirement can be relaxed by taking a vector of samples and treating each element of the vector as a separate "observation." You can also relax independence assumptions as well. Recall that radio receivers are typically (though not always) a single element, yet multipath (multiple sources) can be resolved quite well via ICA (or similar) methods. The MOE detector as well as the decorrelating detector, which work quite well for resolving multipath, are both equivalent to a negentropy-based cost function derivation with regularization.
>C) "Most ICA methods are not able to extract the actual number of > source signals, the order of the source signals, nor the signs > or the scales of the sources." > >Contemplate that one for a bit, particularly in view of >quote A) at the top: "Most" ICA methods can't do the job >ICA is supposed to do! Mind you, in line with the great >academic tradition, the word 'most' is here used in one >of two functions:
The first part of this is a bit nebulous since there is a point at which some sources are simply lost in the background. You have to have some a priori guess with any blind detection method as to how large your spread is, e.g., you sort of need to know how large your delay spread in a comm channel is before deciding how many multipaths there actually are.
>1) No working algorithm has yet been found, but the author > is wise enough not to use the term 'all' as in 'all ICA > methods fail.' > >2) Those ICA methods which don't fail, work in highly > idealized situations.
Heavy research is still being done in a lot of these areas, so statements made in online tutorials may already be out of date.
>The quotes A)-C) above are enough to let the experienced >data analyst understand that ICA for all intents and >purposes is a university funding generator rater than an >operational analysis tool.
Perhaps.
>As somebody already said in this thread, the skill to spot >idealized test conditions is a valuable one, when looking >for usable (or even working) methods. > >Rune
I agree that most methods that are developed are primarily useful in ideal situations, but that goes for many other algorithms as well. ICA is merely a path for research. Algorithms exist that will do what is required, the question is whether they are practically useful. I've not commented on the quality of the result, just that it exists and can work. The work I've done performs outstandingly well for low fade-rate applications, and degrades as fading increases (still a rather large increase over a simple RAKE even with perfect channel estimation, however). This is done on multiple, asynchronous users with arbitrary phase and amplitude as well as overall channel impulse response (multipath conditions). I'm not fully blind as I actually regularize using known code sequences, but I referenced many fully blind applications that have - supposedly - similar performance as I found. The fully blind methods I looked at often use the method of Lagrange multipliers with a dual-optimization on the channel estimate as well as the weight update. I already had a channel estimate so I didn't dig to deep in the fully blind methods. They are harder to balance either way. Mark
>hi, > I have used PCA for face recognition and the performance wasnt >that bad . > > Is this same as ICA that you are talking about? >
PCA is principal component analysis and it is based on correlations, i.e., second-order statistics. PCA only requires uncorrelated sources, rather than independent sources. It is a cousin of ICA and often used to pre-whiten data prior to the ICA estimation method. The terms PCA and ICA often are used as if they each represent a singular method for resolving a problem when in fact, they really represent a class of algorithms. Singular value decomposition can be used for PCA, for example. The Hyvarinen book uses SVD to pre-whiten the received data vector in the DS-CDMA detection chapter. Mark
On 7 Mai, 17:42, "markt" <tak...@pericle.com> wrote:
> >This basically disqualifies ICA as a tool for the cocktail party > >problem - and yes, that *is* mentioned as one application > >for ICA in that article. If you need at least as many mics as > >there are people, then you can just as well crowd the hall with > >mics and track any conversation on the closest mic. No need > >for ICA. > > This is a common misconception/misinterpretation of what the statement > means. &#4294967295;If you read a bit deeper into the ICA methods, once you have > ordered samples, i.e., a time series, the "more observations than sources" > requirement can be relaxed by taking a vector of samples and treating each > element of the vector as a separate "observation." &#4294967295;You can also relax > independence assumptions as well. &#4294967295;
I don't buy that, unless you come up with an anal definition of the problem ICA is supposed to solve. My experience is with Direction of Arrival problems which aims at separating multiple sources in a spatial domain. MUSIC is a very popular choise as basis for investigations, and in that case it is a trivial excercise to show that the maxmum number of sources is strongly related to the number of sensors in the array. The reason is that MUSIC and similar methods is based on examining certain eigenvectors of the signal covariance matrix. The dimension of that covariance matrix is given by the number of sensors, which in turn govern the whole analysis. I would be cerys surprised if the analysis of ICA is fundamentally different.
> Recall that radio receivers are typically (though not always) a single > element, yet multipath (multiple sources) can be resolved quite well via > ICA (or similar) methods.
I have expereience with multipath in sonar environments. There is nothing available which comes even remotely close to work 'quite well' in multipath scenarios.
> >C) "Most ICA methods are not able to extract the actual number of > > &#4294967295; &#4294967295;source signals, the order of the source signals, nor the signs > > &#4294967295; &#4294967295;or the scales of the sources." > > >Contemplate that one for a bit, particularly in view of > >quote A) at the top: "Most" ICA methods can't do the job > >ICA is supposed to do! Mind you, in line with the great > >academic tradition, the word 'most' is here used in one > >of two functions: > > The first part of this is a bit nebulous since there is a point at which > some sources are simply lost in the background.
I don't trust the details supplied by a method which misses a main parameter like the number of sources present.
>&#4294967295;You have to have some a > priori guess with any blind detection method as to how large your spread > is, e.g., you sort of need to know how large your delay spread in a comm > channel is before deciding how many multipaths there actually are.
So you don't learn anything new from that sort of analysis, but rather get your prejudice confirmed? If you need to 'guess' or 'assume' major parameters of the scenario you have already lost. If you use a deterministic parametric model you state your assumptions clearly up front and is able to analyze them, and also have a fair chance of spotting flaws when such occur. "Blind" methods hides such factors from the analysi, obfuscating the whole picture. Rune
>>C) "Most ICA methods are not able to extract the actual number of >> source signals, the order of the source signals, nor the signs >> or the scales of the sources." >> >>Contemplate that one for a bit, particularly in view of >>quote A) at the top: "Most" ICA methods can't do the job >>ICA is supposed to do! Mind you, in line with the great >>academic tradition, the word 'most' is here used in one >>of two functions: > >The first part of this is a bit nebulous since there is a point at which >some sources are simply lost in the background. You have to have some a >priori guess with any blind detection method as to how large your spread >is, e.g., you sort of need to know how large your delay spread in a comm >channel is before deciding how many multipaths there actually are.
I should add, the "nebulous" part of the statement is that you have to run ICA repeatedly until you get to a point you think you have resolved all of the individual sources. This requires either a priori information (as I mentioned) about the number of sources, e.g., you know there are 10 sources so you find 10 independent results and quit, or some criteria to test each output. For speech, the test could be something like checking for an intelligible output, or perhaps that the output signals actually contain formants that resemble speech. Both would require a pattern matching algorithm of sorts, as I see it, on the output. Since PCA is variance-based, you can collect enough vectors that describe some pre-determined amount of the total signal variance, say 95%, and assume the rest is either unrecoverable or noise. Mark
>I don't buy that, unless you come up with an anal definition >of the problem ICA is supposed to solve. My experience is >with Direction of Arrival problems which aims at separating >multiple sources in a spatial domain. MUSIC is a very popular >choise as basis for investigations, and in that case it is >a trivial excercise to show that the maxmum number of sources >is strongly related to the number of sensors in the array.
I made it pretty clear that with a single receiver you lose spatial resolution, i.e., you no longer have DOA information. I'm not talking about exploiting DOA, but independence. An MMSE receiver for a comm system, for example, exploits the fact that users/multipaths are uncorrelated. You start with an input signal, r, and your symbol length, M, as well as delay spread, P. You collect a vector r_vec(n) = [r(n+M+P-1) r(n+M+P-2) ... r(n)]^T, which gives you M+P "observations" used to estimate the channel impulse response. The MMSE result is given by the solution to the Wiener-Hopf equation w = inv(R)*p where R is E{r_vec*r_vec^H} and p is E{r*conj(r_vec)};
>The reason is that MUSIC and similar methods is based on >examining certain eigenvectors of the signal covariance >matrix. The dimension of that covariance matrix is given >by the number of sensors, which in turn govern the whole >analysis. I would be cerys surprised if the analysis of >ICA is fundamentally different.
Depends upon how you implement it. All ICA does (essentially) is use higher-order statistics. Nothing magical, just an extension of the fact that if you have a linear combination of independent vectors, there is only one solution that results in independent vector outputs. If you have multiple receivers, you also have DOA information which can only help.
>I have expereience with multipath in sonar environments. >There is nothing available which comes even remotely >close to work 'quite well' in multipath scenarios.
I'm sorry to hear that. Comm systems (DS-CDMA) employ a RAKE on the forward link which is typically implemented with a bank of correlator receivers to estimate each of the multipaths. Of course, you have the pilot sequence, which is known, to base your estimation on. The correlator receiver is not optimal (w.r.t. MSE) in the presence of multipath or anything other than an AWGN channel. The MMSE receiver above, is, however, and knowledge of the pilot is unnecessary. I suspect, perhaps, that the delay spread in sonar is very large? That might make a solution in that realm very difficult.
>I don't trust the details supplied by a method which misses >a main parameter like the number of sources present.
Well, it is "blind," so this is hardly a surprise. That's why there's research in the area, because applications in which a priori information is not available are more common than not. I also pointed out that PCA provides a means for determining the number of sources, which is typically applied on the front-end of an ICA system. For example, besides pre-whitening, you could examine the autocorrelation matrix and come to conclusions about the number of sources present. There is no one method that's going to universally solve all of these (and other) problems.
>So you don't learn anything new from that sort of analysis, >but rather get your prejudice confirmed? If you need to >'guess' or 'assume' major parameters of the scenario you >have already lost. If you use a deterministic parametric >model you state your assumptions clearly up front and is >able to analyze them, and also have a fair chance of >spotting flaws when such occur. "Blind" methods hides >such factors from the analysi, obfuscating the whole >picture.
I'm not sure what you're getting at here. ICA will separate the sources if they are independent (or nearly so). Couple the ICA with other methods (PCA) and you have good estimates of the parameters you request. The real-world isn't so kind as to provide all the answers automatically. The whole purpose of blind methods is exactly to deal with scenarios in which you do not have complete information. The reverse link of a comm system has to guess how many users are present before they are acquired. There is no deterministic way to make this assumption a priori, yet my cell phone works quite well (most of the time). How is this any different? Mark