Loop points clicking issue in HISE but not in other samplers

[Yinxi]

Hello,

I’m currently facing a pretty annoying issue...
I’m writing the loop points of my samples using my own external tool (outside Hise), and I’ve noticed that when I import these samples into HISE, the loops produce clicks.

I tested the exact same samples in UVI Falcon and Kontakt, and I don’t have any clicking problems there.

Has anyone experienced something similar?
I can see that the loop points are imported correctly, and the crossfades are already rendered directly into the samples, so I don’t really understand why it’s clicking only in HISE.

I really hope I won’t have to redo everything from scratch...

[d.healey]

@Yinxi does it occur once you've compressed the samples and exported the project or only in HISE?

[Yinxi]

@d-healey only in Hise, the samples are not compressed, and they are located outside of the project folder.

[d.healey]

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

and they are located outside of the project folder.

If you're making sample maps you should put them in the project's Samples folder.

Make a test project with 1 of the samples, compress it, export as a plugin or standalone and test if the issue is still there.

[Yinxi]

@d-healey said in Loop points clicking issue in HISE but not in other samplers:

you're making sample maps you should put them in the project's Samples folder.

Make a test project with 1 of the samples, compress it, export as a plugin or standalone and test if the issue is still there.

I started from a blank project with just one sample, exported it, and the issue was still there.
However, I think I’ve found the problem

When importing my samples, the LoopEnd value is always 1 sample lower than the value I set in my custom looping tool, which explains why I was hearing clicks on every sample on my project.

This difference only happens in HISE,
In Kontakt and Falcon everything was good, so it seems that HISE is always removing 1 unit from the LoopEnd value.

Kontakt :

Hise :

It might be interesting if other user could test this on their side to see if it’s a general issue or a small bug to fix.

[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.