Nord User Forum

maxpiano wrote:
Unfortunately .wav loop points are ignored. Loops anyway are based on loop points which indicate specific samples positions, not time.

So the best you can do is to use a a good .wav editor to lookup the exact position of the loop points on the original .wav and then manually "match" them in the NSE (splitting the screen to have both the .wav editor and NSE visible at the same time, so you can help doing this with a visual check)

PS: 0.023 ms is 0.0000000023 so your calculation above is incorrect because you used 23ms = 0.000023 instead.
The error in analogika's approximation is much smaller, as he also has explained.

Anyway, to keep it simple, at 44.1KHz you need 44.100 samples to make exactly 1 second, easy.

This will be too time consuming for most cases. Too bad but thanks for the advice.

PS I believe you mix up milliseconds and microseconds and it's one decimal wrong even for microseconds. My calculation is correct.

analogika wrote:If i were to set a sample exactly one second long, I’d set it to 1000 ms.

If your precision is 0.03 ms, and the actual value of one sample is 0.023 ms, then the maximum difference between the value you’re setting and the actual sample is 0.007 MILLIseconds — for the entire sample loop.

In other words, the sample would have to loop almost 140 times to be off by ONE millisecond.

And that is assuming that the displayed resolution is what the system is actually doing, rather than just being an approximation for the human user, while the system itself is of course sample-exact. I don’t know this, but anything else wouldn’t make sense.

I think you might missunderstand the reason why I ask. From experience I know that a well crafted loop in a wav file from some library will often be ruined even if the loop is set only one sample wrong. Since it's impossible to know how rounding is performed when Nord translate the actual sample number to two decimal precision milliseconds each and every loop will have at least two possible millisecond values per point. This will lead to an extensive amount of trial and error (four cases per loop I believe) if I'm to import a great portion of sampledata.

It might be the compression method they use although non destructive for audio somehow affects resolution for sample points. If so then that's a reasonable explanation to the millisecond only display and why it won't import loops. But tha's only me guessing.

maxpiano wrote:

oortone wrote:

maxpiano wrote:
Unfortunately .wav loop points are ignored. Loops anyway are based on loop points which indicate specific samples positions, not time.

So the best you can do is to use a a good .wav editor to lookup the exact position of the loop points on the original .wav and then manually "match" them in the NSE (splitting the screen to have both the .wav editor and NSE visible at the same time, so you can help doing this with a visual check)

PS: 0.023 ms is 0.0000000023 so your calculation above is incorrect because you used 23ms = 0.000023 instead.
The error in analogika's approximation is much smaller, as he also has explained.

Anyway, to keep it simple, at 44.1KHz you need 44.100 samples to make exactly 1 second, easy.

This will be too time consuming for most cases. Too bad but thanks for the advice.

PS I believe you mix up milliseconds and microseconds and it's one decimal wrong even for microseconds. My calculation is correct.

You are right, I had a "0" more and I didn't verify that actually 1/44100 is 0,00023. Your calculation is correct, my apologies.

Anyway it still true that a 1 second loop at 44.1Khz samplimg rate means looping exactly 44100 samples.

No problem.
If one sample is 0,023 ms then 44100 is not exactly 1 second. That's the problem I meant to describe. That it's unclear which millisecond value that corresponds to a certain sample number.

One sample isn’t 0.023 ms, but, as we’ve both done the math, 0.02268…whatever.

44100 samples is one second at 44.1 kHz. That’s the definition of what a sample rate is.

Whether the interface rounds at two decimal places to make it manageable has zero influence upon what is actually happening with the sample.

If you think for a moment about all this, you cannot have, in discrete space, every possible value, so you might be off by some amount within a margin of error that is given by the clock or software resolution. If one of your sounds is based on samples, and you are trying to match to a drum machine, I bet that in the long run there will be always a drift. So I think you need a different approach to make sure that your sample loop in the long run keeps synchronised to another machine that has a clock with, most likely, with a different time resolution. For example not keep the sample looping forever (where the drift will at some point noticeable), but use MIDI clock to restart the sample more often, so you never reach the noticeable drift.

Mr_-G- wrote:If you think for a moment about all this, you cannot have, in discrete space, every possible value, so you might be off by some amount within a margin of error that is given by the clock or software resolution. If one of your sounds is based on samples, and you are trying to match to a drum machine, I bet that in the long run there will be always a drift. So I think you need a different approach to make sure that your sample loop in the long run keeps synchronised to another machine that has a clock with, most likely, with a different time resolution. For example not keep the sample looping forever (where the drift will at some point noticeable), but use MIDI clock to restart the sample more often, so you never reach the noticeable drift.

Hello.
My question is not about matching beats, it's a about getting loops in pads so they sound as intended from the designer of the sample library in question. Offsets, even small ones will often introduce pops.

But my initial question was if the loop point conversion could be done automatically which I've learned it can not.

My initial experiments however shows that when I enter the calculated loop point manually with one more digit than the Editor displays it seems to round it to it's internal resolution. The samples I tried will loop without clicks so that's at least a bit of good news although automatic reading of root key and loop points would have made sample import extremely more convenient. The corresponding software for Waldorf Blofeld: Spectre will do this without any problem. There's also a limit for how short samples can be in the Nord Sample Editor, 100 ms which makes import of some special libraries impossible.

By the way for any new reader of this thread. To convert a loop point at 44100 kHz sample frequency to Nord Sample Editor milliseconds this is the calculation to do.
Loop Start [ms]: (Loop Start)/44100
Length [ms]: (Loop End - Loop Start)/44100
XFade: 0

So for example if the loop is [sample number]:
Start: 70433
End: 158868

This is the result:
Loop Start = 70433/44100 = 1.597120 s (will be rounded to 1.59711)
Length = (158568 - 70433)/44100 = 88135/44100 = 1.998526 s (will be rounded to 1.99851)

Oops, apologies! I meant to answer to the loop out of sync issue reported in this thread:
nord-user-samples-nsmp-samples-f14/nord-sample-editor-issues-wish-list-t3046-30.html#p95860

I see, maybe I should have started my own thread? But since it was closely related I hijacked this. Apologies to the thread starter.