I notice that Guru Sampler doesn't pick up loops embedded in audio files. Is there a possibility it might support this in future (please)?
I notice that Guru Sampler doesn't pick up loops embedded in audio files. Is there a possibility it might support this in future (please)?
If you include the tag
loop_end=0
on your <region> lines, Guru Sampler will attempt to find loop start/end in the WAV metadata.
Ah great, thanks. Would you know if there's a minimum number of samples that need to reside beyond the loop end marker in order to avoid problems in this case? I have found this with other sample players like sforzando and I'm seeing it with Guru Sampler where short samples loop properly on some notes but on other notes they effectively play one-shot. I thought I'd solved this by adding an excess of 32 samples but this doesn't appear to be cutting the Guru's mustard.
Would you know if there's a minimum number of samples that need to reside beyond the loop end marker in order to avoid problems in this case?
Well, I wrote the code, so yes, I'd know. There is no such minimum. Many samples have the loop-end right at the end of the file.
I have found this with other sample players like sforzando and I'm seeing it with Guru Sampler where short samples loop properly on some notes but on other notes they effectively play one-shot. I thought I'd solved this by adding an excess of 32 samples but this doesn't appear to be cutting the Guru's mustard.
If you'd like to zip and post a small example (e.g. SFZ using only one fairly short sample file), I can investigate.
If you'd like to zip and post a small example (e.g. SFZ using only one fairly short sample file), I can investigate.
Attached here.. thanks.
Thank you for the SFZ and samples. I see that Guru Sampler is able to pick up the loop-endpoints from some of the WAV files, but not others.
The root of the problem is that there is much variation among programs in how they write WAV files--so much so that some WAV-reading code may not be able to parse some files correctly. JUCE's WAV-reading code takes the WAV "standard" a bit too literally, and although I have made some changes (well, hacks) to the version Guru Sampler uses, it still doesn't work on every WAV file, and that's what's happening here.
A work-around is to use Bjorn Bojahr's Endless WAV utility to read the loop start/end points out of the files, and put them into your SFZ file with explicit loop_start and loop_end tags. Here's how I did it:
- Open your SFZ file in a text editor, and add "loop_start=0 " before every "loop_start=0"
- Open Endless WAV and drag/drop your entire sample folder (in this case 8-bit) into its "File List" window.
- Double-click the first file in the list; the loop start/end numbers will be displayed under the "Loop Edit" heading
- Manually replace the loop_start and loop_end numbers on the appropriate line of your SFZ file with these values
- Click the green right-arrow button at the top right, to advance to the next file, and repeat from step 4.
I have attached the resulting SFZ file, in which I have also taken the liberty to extend the range of the lowest sample all the way down to MIDI note 0.
Thanks for taking the time to look in to this. Perhaps interestingly I used Session2WAV and Endless WAV to create all those samples, if I recall correctly, having Endless WAV truncate at loop end marker and then using Awave to append 32 samples to avoid this problem in sforzando. Point being that all samples went through the same process with the same tools so one might expect the result in player to be either hit or miss but not both. With sforzando I have found that the same sample, mapped across a range of keys, may play ok on one key but not another, suggesting that it's a problem with resampling or whatever the player does to pitch a sample; as opposed to a problem with the WAV file per se.
Anyway thanks for the tip.
...suggesting that it's a problem with resampling or whatever the player does to pitch a sample; as opposed to a problem with the WAV file per se.
I'm 100% certain the sampler fails to read metadata from some files. I've watched this happen in the debugger.
I've discussed this issue with Bjorn, and he concurs that a lot of WAV-reading code is too limited. His is hand-tweaked and very good. At some point I'm hoping to collaborate with him to get better WAV-reading code, but it's not simple because I code in C++ and he doesn't.