Monolith conversion problem = change sound !!!
-
Why are you using 27.8 kHz as samplerate?
-
because creating an "old" rompler (emulator/fairlight/etc. ...) that plays at 27.8 kHz (and some of my samples - free and open source on the net are shared to 27.8 kHz also)
Just to keep the "feeling" of the resulting sound.
But as far as i know now, i will convert all samples to 44.1 and use the bitcrusher module set to this samplerate.
what are the available samplerates by hise for monolith conversion (remember saw it somewhere but don't find it now) ?
-
If you use a bad resampling algorithm for the conversion, you won't need a bitcrusher.
Also bitcrushing has nothing to do with samplerate.
-
no, no. Just adding the "degrade" bitcrusher module to "color" the sound. set to 27.4 kHz - 8bits. the little subbtle white noise added is goog ;)
not really the same rendering than the real old vintage hardware, but ...
so, again, what are the accepted samplerates by hise for monolith conversion ? (44.1 minimum ?)
Batch converting software with loops preserved or 1 by 1 converted (or resampling again in 44.1, better way so ...) ?
-
AFAIK there is nothing in the code that limits the samples to 44,1kHz (and higher sample rates definitely work), so maybe it's a small fix to make it work so that you can use your loop points (which is a valid argument).
Can you upload one sample that plays back normally as .WAV and the wrong HLAC file?
-
https://drive.google.com/open?id=1-iUmPGzXMbg7EaEt3vmTytHF5d31jHwP
27778 kHz - 16 bits samples
when using raw samples, no problem. converting to monolith: problem.
if resampling it sample by sample in 44.100, then redoing an sfz with it, replacing the old sfz by the new one in hise, and redo the xml samplemap: all is fine.
so for now i must resamples all my samples one by one, redo sfz, reimport, resaving, reconverting. lot of work (and time) in perspective.
Anyway, there's always no problems, but just always solutions.
Next time i won't do that for my samples ;)
i read somewhere on the net that if the sample is a division (or multiple) of 44100 it's good. but 27778 is not a division of 44100, it's 1.58. Maybe the cause.
-
who tried this ?
who have the same problem with converted monolith ?;)
-
Will try it next week, but an odd sample ratio shouldn‘t be a problem - if you are detuning your samples down a semitone you get a playback ratio of something like 0.98462, and I think we would have noticed it if this didn‘t work :)
-
my video here:
https://drive.google.com/file/d/1IZYQcai0dcKt9K7ULTCWZtWSIBnHMd2B/view?usp=sharingwe can clearly see (and ear !!) that 27.8 kHz smaples are detuned when converted in monolith.
didn't do the same thing with 44.1 kHz samples in this video because it works in this samplerates.
:D
-
Okay...
i re-recorded my instruments in (min) 44100 kHz. redone the monolith and all is fine.NOTE: i first create an .sfz encapsulation in ESC, just because i feel it more fun to import my samples inside HISE than direct .wav (.sfz has root note, start end sample, start end loop, etc. .. that is automaticly set up in HISE when importing)
when creating monolith a line is added in the samplemap.xml:
"MonolithOffset="value" MonolithLength="value" SampleRate="44100"/>"
maybe something wrong beetween the 27.8 kHz data infos inside the wav, the .sfz info and this line created in the samplemap file ?
BTW, with brand new 44100 kHZ or above samplerate: all is good ;)
