Stems is a Stem Player (Sample Player) where all samples (tracks) are replayed in sync.
This can be useful for processing stems you export from another DAW, like Cubase or Ableton Live.
Use the right-click-menu to either load individual files, or load the first (in alphabetical order) 6 wave/flac-files from a folder.
Some DAWs will name track with a track-number at the end when exporting multiple tracks. You could say it’s optimized for the case described in this post:
As some might have noticed 48k(Hz) is becoming increasingly popular on more and more platforms, and many (most?) DAWs still default to 44.1k. I other words, there is a decent chance you will be faced with files of both sample rates. (And maybe you like to run your projects at 96k)
If a file has a sample rate that is not exactly the same as the engine sample-rate the sound will be re-sampled with a high quality algorithm.
Each Track has a vu-meter where the color describes some details about the sound.
- Green = Sound has same sample rate as project, no sample-rate-conversion has happened when loading this wave.
- Orange = Sound has been up-sampled. (no information present in the source data is being lost, but some very subtle change could occur)
- Red = Sound has been down-sampled. (high-frequency data in the source data is thrown away)
The inputs are:
- Stop (stop playback and reset play-head to beginning)
- (Re)-Play (play from the beginning)
- Play (play from current play-head position)
- Pause (stop playback and leave play-head position)
- Reset (reset play-head to beginning without stopping playback)
Beware of memory consumption with long pieces, since the entire file will be loaded into memory at 32 bit resolution. If it needs to be resampled the entire resampled sound will be in memory too.
As an example: a full hour of 48k stereo would eat 1GB of ram, if the project sample-rate is at 96k, the resampled copy would eat 2GB, so 3GB in total)
Also be aware that loading tracks that need resampling will spawn temporary worker threads (one per audio-channel). The resampling is CPU-intensive, and putting the work in threads is done to not block the GUI or cause audio-glitches. If you do not have many cores on your CPU you might notice the CPU-spike. Don’t be alarmed and there should be a “progress-bar” looking thing to indicate the progress.
Check it out here:
Hope you like it,
I’m playing a 15 minute 44 wav at 48, and it’s sounding good so far Thanks!
Is that the first 6 in alpha-numeric order? Would I need to name the files a particular way to load the ones I want?
Yes, sorted alphabetically. (edited the original post)
Nicely looking waveforms, how to read them ?
They are similar to an oscilloscope, but slightly different.
- They are “zoomed out” a bit, and the min/max is visualized per time-slice. So a sinewave near Nyquist would look like a solid block.
- They are also “normalized” to be clearly visible at quiet passages.
Other than that you could think of them as oscilloscopes visualizing what’s under the “play-head” of the player.
(EDIT: I replaced the “oscilloscope”-style view with a simpler VU-meter, to support files with high-channel-count)
Do you have somewhere for suggestions/feature requests?
This looks very cool! Two Q: 1) what is the “very high quality” sample-conversion algorithm? and 2) Why don’t you discard the original after you have processed it?
Its Windowed-Sinc (linear-phase) with 512 points… there are actually different things happening based on the ratio…
A. Simplest cases are up or down exactly 2x and 4x (like 48k → 96k, 48k → 192k)
B. Next is up-sample, where i:
- Up-sample 4x
- Use an “6-point 5th order optimal polynomial”-interpolation (Polynomial interpolation – iki.fi/o) to reach the exact sample-rate…
C. Worst case is down-sampling where I:
- First up-sample 4x,
- Then the polynomial (link above) to match 4x of the target-rate and then
- 4x decimation
I keep the original so that switching sample-rate wouldn’t trigger a reload… i realize (now) that seems like rare case… it was very common while testing
wow, that’s impressive! 512 point brute force, or some clever trick? 512 brute force would take a lot of cpu! And, yeah, optimizing for changing same rates - not so common…
oh, finally got it to load something (I was trying to load a folder of flac files!). CPU usage is super low! nice.
Some clever things are:
- When doubling sample-rate, every other sample is exactly the input, so only the new samples (every other) need calculating
- The sinc-function is symmetrical around its center, so you can add the left and right sample and only multiply with one coefficient (since left and right are the same).
If I was really clever I’m sure I would have put some FFT in the mix too…
Block convolution with fft isn’t so bad. Once you have your windowed impulse. I didn’t realize before that of course you only need to convert once, ahead of time. So of course the cpu usage is not affected. Brilliant module! Btw, at least for hacking it would be nice to be able to directly load a file, rather than a folder of them.
Thanks to @jue for reporting the Time display was busted past 60 seconds. The latest version “2.1.1” fixes that.
All great ideas… I really like the “one-file, poly-cable out” idea.
My SFZ Player has a flac decoder. There may be license issues if you static link it… you are closed source, right?
I use dr_wav for wav loading and would use dr_flac for flac… Both are Public Domain