Sascha Franck
Rock Star
- Messages
- 9,498
That’s where you’re wrong, apt response to apt questions![]()
Doesn't get much better. Answering some genuine questions with memes is possibly telling more about you than you'd wish.
That’s where you’re wrong, apt response to apt questions![]()
The point is for IR capturing, it has no idea what you are capturing or how you intend to use it.IMO that isn't true. You want the sweep (or whatever you've used) to align perfectly with the recorded file, even if the source impulse (sweep, gunshot, etc) is completely masked by the recording. Sure, you also want to capture the timing properties of whatever you capture, but for that to come out accurately, you have to make sure the returning file is lined up properly (as in only containing the offset of the captured thing but no additional latency).
That's actually a reasonable thing to state IMHO.I get that. But I'm still wondering (see last post) whether this could be the source of some inaccuracies. I mean, if you really, really smash the input file (kinda like beyond recognition), the alignment could possibly be less exact.
Well you’re asking about a process that’s been solved for NAM and tonex since inception. If you wanted to really dive into the weeds the NAM crowd like Steve and a bunch of his orbiters are pretty in tune with every step of the process.Doesn't get much better. Answering some genuine questions with memes is possibly telling more about you than you'd wish.
The point is for IR capturing, it has no idea what you are capturing or how you intend to use it.
Yes. What I am saying is it has nothing to do with ToneX because they’ve already accounted for it.I'm aware of that. And yet, for the results to be accurate, the recorded file needs to line up properly with the original impulse (or rather the, even if inaudible, position of the original impulse). Otherwise, if you'd capture, say a delay of 100ms, it'd be a 102ms delay in case your hardware added 2ms of latency. And it'd possibly get worse in case you were using a sweep impulse. As said, I've been running into this very issue some years back.
Now here's my understanding of it: Typically alignment requires a process called peak-picking. Doesn't matter whether you're doing it on raw sample-data, or FFT-bin data, or some sort of novelty envelope data that you've extracted from the audio. At a core level, you need to find the loudest point within a local window. So yes, if you smash the absolute living shit out of the input file, thus compressing the noise-floor and the actual signal so that they're harder to distinguish, you absolutely could end up with a reference peak that isn't the correct one; at the sample level I mean.
If you applied a gnarly as fuck fuzz or distortion pedal that performed some waveshaping on the input, and turned your crisp 'click' sound into a rounded-out sine-wave shape... then yes, that could also have an impact on the resulting peak-picking process.
This video pretty much explains the process I follow using VB cable. On Mac.Having said all this, @Dimiguitar, you said you were "tonex-ing" some plugins already. What exactly was your procedure? Did you use any kind of internal loopback of your interface? Or did you just do it the analog way, as in inserting one interface in the loop of the capturing interface?
This video pretty much explains the process I follow using VB cable. On Mac.
See, this is precisely why I was asking (or rather wondering).
Especially once heavier distortion comes into play, peaks could possibly be misinterpreted.
I can say this is not true for Tonex.The training file is a certain length
You pump it into your amp then back out via cab/mic or loadbox back into your interface
It auto aligns the training file to the fixed length of recording
Latency for this doesnt come into the equation at all, its just auto aligning the files