FLAG (free) Stems (Multi Channel Wav/Flac Stem Player with High-Quality-Resampling)

Hi Again,

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 track). 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 :smiley: Thanks!

1 Like

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?

1 Like


1 Like

Yes, sorted alphabetically. (edited the original post)

Nicely looking waveforms, how to read them ?

1 Like

They are similar to an oscilloscope, but slightly different.

  1. 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.
  2. 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.

Do you have somewhere for suggestions/feature requests?

1 Like

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?


How about right here?

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:

  1. Up-sample 4x
  2. 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:

  1. First up-sample 4x,
  2. Then the polynomial (link above) to match 4x of the target-rate and then
  3. 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 :slight_smile:

1 Like

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…

1 Like

oh, finally got it to load something (I was trying to load a folder of flac files!). CPU usage is super low! nice.

1 Like

Some clever things are:

  1. When doubling sample-rate, every other sample is exactly the input, so only the new samples (every other) need calculating
  2. 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.

1 Like

Thanks again.

  • Any chance of FLAC support?

  • The browse for folder dialog that appears on Windows doesn’t start at the previously selected folder but at the root. So you need to drill down all the way again if you want to pick a different sub-folder

  • My personal preference is to select the individual files specifically rather than have the module pick the first six in a folder. As it is, I need to construct a dedicated folder for a patch to get the right files. E.g. the way you can pick files in NYSTHI QuadSimpler

  • I have multichannel FLAC files I have created for surround, e.g. 5.1 (6 channels), 7.1 (8 channels). With my Dolby Atmos experiments I might even have a few more channels. I’d like a variation of the player module that could take a multichannel audio file and output all the channels. It could have a single poly out jack rather than needing separate jacks for each channel, which would avoid hard-coding a limited number of output jacks. I don’t think the module would need to handle more than one file, since I could use more than one instance of the module if needed. If it could handle FLAC and WAV that would be great. [N.B. For anyone interested, NYSTHI’s PolyRec/PolyRec64 save multichannel WAV files]


All great ideas… I really like the “one-file, poly-cable out” idea.

1 Like

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