IK Multimedia TONEX

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).
The point is for IR capturing, it has no idea what you are capturing or how you intend to use it.

It has no bearing on ToneX or how it captures and aligns its models, because the variables are MUCH more controlled. It’s a solved problem that doesn’t need dwelling on.
 
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.
That's actually a reasonable thing to state IMHO.

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.

I would assume that the training model accounts for this in some way.
 
Doesn't get much better. Answering some genuine questions with memes is possibly telling more about you than you'd wish.
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.
 
The point is for IR capturing, it has no idea what you are capturing or how you intend to use 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.
 
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.
Yes. What I am saying is it has nothing to do with ToneX because they’ve already accounted for it.
 
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.

See, this is precisely why I was asking (or rather wondering).
Especially once heavier distortion comes into play, peaks could possibly be misinterpreted. Heck, the amp (or whatever) might even do something like that for its sonic signature, as in kinda squashing the very first transient. To solve that, you'd likely need a more or less precise "time window" which would then tell the capturing process where to look for the first peak. And with a certain noise present on the amp's signal, it certainly couldn't be "wait for the first signal to arrive" but would at least need some kinda threshold making it "wait for the first signal breaking the threshold level to arrive".

With DAW based alignment, you'd either do things yourself (see NAM) or the recording would line up with the trigger signal automatically (as the latency of your used hardware is transmitted to your host via the driver). With all sorts of unknown latencies turning up (let's say when capturing a digital device), that's not possible anymore - unless the Tonex Modeler app would be informed about the latency of your audio interface, just as your DAW is.

In fact, the latter is what I sort of suspected at first. But in that case, capturing, say, a plugin running on another computer (inserted instead of an amp), would be pretty much impossible due to the unknown latency this would add. So there must be other means of correcting the timing of the recorded file, unless you are only supposed to capture zero latency introducing devices, aka analog hardware.
 
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?
 
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 don't think so, and they are not necessarily simply relying on a single peak. There are multiple clicks and they can look for the peaks but also the rise above noise floor. The only way I see that there could be a problem is if there was variable latency, and I have yet to hear of anyone having a problem with that. Any type of distortion or frequency changes would not impact the timing so I don't see why a fuzz or highly distorted amp would cause problems and there is no evidence that they are.
 
At 48khz a single sample is ~20 microseconds (not ms) in length. Even if the analyzer is a sample or two off, which I doubt it is, I wouldn’t expect it to cause major issues. Alignment isn’t the issue. I assume if you try capturing something that has 30ms of latency, Tonex probably stops the attempt and yells at you.
 
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
I can say this is not true for Tonex.

Edit, referring to the auto alignment to the fixed length of the file.
 
Last edited:
Back
Top