In some circumstances, demixing a song results in an undesirable broad-frequency “buzzing” that can be very noticeable when you separate stems. It sounds a bit like a noisy guitar amp. It cannot be heard when you play all layers together, but it can be heard when you isolate or rebalance.
Here’s a visual example. The display contrast has been adjusted, but remains the same for all three examples.
Here is an imported wav, which is just a 1kHz tone:
OK. Here’s a real world example. This was a recent unmix. This is just the “other” from the tone at the start of the source file. There is no noise audible or visible on the source file:
The noise “rings” after the tone has stopped and is very clearly audible to me - even on this mp3 - with my monitors at standard mix level (calibrated for TV mixing). It appears to be “triggered” by something, but can occur with music or vocals or dialogue. Clearly audible on quiet sections of a remix, particularly - as I discovered - in the higher registers to an editor with rather younger ears than mine.
It cancels out in a flat down-mix of course. But it’s exposed as soon as you start using eq, or moving things around in surround.
Thanks for this bit of context - the use-case is a bit more clear (to me). I think you’re just seeing natural artifacts in any unmix process. While a contrived example, say the original mix is from a 2-mic amped guitar with two separately processed tracks (and effects), but the final mix still contains some manner of phase cancellation because of mic placement. The “Unmix” of the guitars here will undoubtedly result an “other” track containing now-audible artifacts which cancel during playback. To me, this is normal and expected, particularly in heavily processed mixes with lots of effects. You could try slight phase adjustments on the “other” track to bring it “back in” to the mix and EQ it, or you could try other processes against “other” (dereverb) and/or different mixes of the other and your primary track(s).
I would work on a small key segment of audio as a test to make the process quicker, but I wouldn’t expect unmix to yield “stem-ready surround tracks” without a good amount of processing.
I’m interested to see how production-house users approach this as well.
" The “Unmix” of the guitars here will undoubtedly result an “other” track containing now-audible artifacts which cancel during playback. To me, this is normal and expected, particularly in heavily processed mixes with lots of effects."
This is 1kHz tone. As simple as it gets. As I say, the same artefact rears its head on other sources during the mix. There is no buzz on the source track. So why is there a buzz on the unmix?
As I said, it was a contrived example to illustrate a point. A simple “1kHz tone” to you is, depending on rate and FFT frames, a series of tens-of-thousands of amplitude variations. There’s no such thing as a “1kHz tone” until after it becomes a 1kHz tone. The algorithm doesn’t know that a 10k sine wave is “about to become 10k once it figures out infinite cycling occurs at the 10,001 cycle.” A 40Hz “tone” isn’t a tone but probably perceived as a rhythm to you and me - it’s a dramatic difference. To an algorithm, it’s sampling of amplitudes, and in this case, a sampling of amplitudes processed via FFT.
My reply was to help scope the overall unmix operation on the “real” track you were talking about.
And I 100% agree with you. In “real-world” use-cases, you should expect this, irrespective of what algorithm, or even what application, you’re using to “unmix.” It’s a natural result of deconstructing composite audio signals. I didn’t mean to get too technical, but just let you know that this is all expected, and YMMV depending on multiple factors.
I guess a last example would be to just identify when you say nothing is simpler than a “1kHz tone,” I would disagree with that. If you said a “1kHz sine wave,” then sure. But not a 1kHz saw wave, or even square wave. If you look at the spectrometer or frequency analysis for each of those 3 different waveforms, you’ll see the resultant harmonics comprising the signal are all very different even though it’s “1kHz.”
That’s really all I was saying - you should expect a certain amount of post-processing. Have fun
Well, sure there is no 1kHz tune of finite length, true.
But as longer as the tone gets, it becomes a better and better aproximation of this 1kHz.
So, we should at least see an improvement of unmixing, when we increase the length of the tone, right?
This is not the case here!
For this - and lots of other reasons (which I mentioned in foregoing threads), I consider SL, as in its todays version 11.0.60 Build 405, as a mere toy, with many good usescases, of course. But in no way a serious tool for precise scientific work. It is just unreliable and the outcome of many tasks seem to have some random artifacts, which might be byproducts of inconclusive implementation of the algorithms from a pure mathematical viewpoint.
Spectral editing of sound today seems to me in its infancy, as maybe picture editing was in the early 90s of the last century. This is in no way meant offensively, just stating my personal view on this.
SL is an ingenious, lovable and priceworthy concept, but its actual implementation needs much quality improvement on the codebasis, imho.
I agree that this kind of processing is still taking baby steps. But SL (and RX) are nevertheless very useful tools. But in this case we are getting a very specific side effect that sounds rather like a humming guitar amp - lots of harmonics (and enharmonics!). The point of this forum is to raise issues and discuss. I’ve raised, and we are discussing. I’d like to know what it is (mathematically) that causes this artefact. And if the discussion helps development of the algorithm - excellent.
Oh man, this “toy” is vital to what I am doing day-in and day day-out; a game-changer in professional terms.
Personally, I’ve no interest in science experiments as a use case; I need to control recorded unwanted sounds with the least intrusive artefacts and SL 11 delivers that in spades and beyond. I understand my use case is different to other users. SL was designed for my specific use case.
