Loop points clicking issue in HISE but not in other samplers

[d.healey]

@Yinxi Hmm that's strange, what sample rate are the samples?

[Yinxi]

@d-healey I also thought it might be a sample rate issue, but all my samples are at 44.1 kHz, and the project settings are the same.

[Yinxi]

@Yinxi I can send one of the samples if you want to test it on your side.CustomSine_C3.wav

[d.healey]

@Yinxi I'll take a look in the morning

[d.healey]

@Yinxi Checking this out now

[d.healey]

@Yinxi That loop is playing back completely smoothly here, no xfade applied

[Yinxi]

@d-healey Actually, I have to admit I didn’t use the sample that clicks the most, but if you play it at full volume you can still hear a small click in headphones.
However, the issue is still here, when I load the exact same sample into Falcon’s sampler, it sets the LoopEnd value correctly (263419 , not 18).

UVI Falcon info on the file :

[Yinxi]

I can conclude that it’s a more Hise general issue rather than my project being misconfigured.

[d.healey]

@Yinxi said in Loop points clicking issue in HISE but not in other samplers:

full volume you can still hear a small click in headphones.

My ears are not sensitive enough apparently. I can't hear a click.

[Yinxi]

@d-healey You can try with this sample if you want, this one makes the issue very obvious.
CustomSaw_G#6.wav
HISE shows the LoopEnd at 344278, but in reality it should be 344279.
When I correct the value in HISE, the click disappears.
For small projects it’s not really a problem, but for large projects with several thousand samples, it becomes quite annoying.
I’m wondering if I should add this thread to the bug reports list.

[d.healey]

@Yinxi said in Loop points clicking issue in HISE but not in other samplers:

You can try with this sample if you want, this one makes the issue very obvious.

Yes that one I hear it.

@Yinxi said in Loop points clicking issue in HISE but not in other samplers:

I’m wondering if I should add this thread to the bug reports list.

Yes make a bug report on github and link to this thread. It seems the import is off by 1 sample.

[dannytaurus]

This is the kind of thing that could be covered by unit tests. They would confirm functionality and prevent regressions.

(Not saying it's a HISE code issue, of course, just saying that unit tests could tell you if is or isn't)

Coming to HISE as a Ruby on Rails developer, it's always felt weird to me that there aren't any unit tests here.

But I guess that's the norm for C++ and/or HISE/JUCE-type projects, especially predominantly single-author projects?

[Yinxi]

I actually double-checked this using a small Python script generated by ChatGPT, which reads the smpl chunk directly from the WAV file, it reports the exact same LoopEnd value that HISE shows.

However, I think it would make more sense if this value were interpreted the same way as in other sample-based plugin tools (like Kontakt or Falcon) to ensure consistent loop behavior across different samplers.

Both Kontakt and Falcon interpret the LoopEnd value in the same way, which is also consistent with the looping software I use to create my samples, unlike HISE, which appears to handle it slightly differently.

From a compatibility standpoint, this could become an issue if a company wanted to migrate a large sample library from Kontakt to HISE, since all loops might develop small clicks due to this off-by-one interpretation difference.

That said, I have to admit I don’t have the technical knowledge to fully understand where this 1-unit difference comes from.

[Christoph Hart]

@Yinxi nice catch. Today I learned that the loop end is inclusive in the audio chunk metadata :)

Curiously the loading function for the audio looper already had that correction:

if (metadata.getProperty(MetadataIDs::LoopEnabled, false))
{
	// add 1 because of the offset
	lr->loopRange = { (int)metadata.getProperty(MetadataIDs::LoopStart, 0), (int)metadata.getProperty(MetadataIDs::LoopEnd, 0) + 1 };
}

but the metadata parser of the sampler didn't use this yet, but the fix is trivial. Note that this will only apply to samples that you import and use the metadata information for extracting loop points - existing sample maps will not be altered as this would break any existing project.

it's always felt weird to me that there aren't any unit tests here.

There are quite a few unit tests in deterministic parts of the codebase (eg. the SNEX compiler is almost fully covered by unit tests), but the nature of audio software makes it super hard to cover DSP things like this.