LMMS OVERSAMPLING EXPORT SOFTWARE

So I think there is no connection between playback and export in this sense. The sound is correct when played live and the exported files are also the same as with 44.1. Using jack, I changed the playback samplerate to 96kHz. The default 44.1kHz is only used during playback and is changed to the specified value when the export starts. There is no 'project sample rate', but the instruments themselves work at the samplerate specified for the current operation. The samplerate conversion would explain a lot of the problems, but as far as I know no such thing happens during export or live playback unless oversampling is set. But whether such a change would be possible without a major rewrite I have no idea. This way the output would be always consistent, no matter what machine LMMS is running on, no matter the export sample rate. Ideally, LMMS should do all its internal processing in a fixed sample rate selected by the user and then resample if needed as the last step, before passing samples to the output (be it speaker or a file writing library). So this may be just one of multiple issues caused by a single underlying 'design flaw'. Most often in connection to samples IIRC. I ended up ignoring it, since all my HW happens to 'agree' on 44.1 kHz, but during the time I spent lurking around this tracker and LMMS Discord I saw quite a few complaints of the type 'Why does my export sound differently than what I hear in LMMS?'.

LMMS OVERSAMPLING EXPORT SOFTWARE

That has been bothering me pretty much from the first time I opened LMMS: this approach is good for a simple media player (no configuration that the user could break), but not for audio processing software that should produce exact, repeatable and reliable outputs with technical parameters defined by the user. Whatever the system happens to be using is forced upon the user. The underlying problem, in my opinion, is that currently it is not possible to specify a sample rate for the project. I don't have much of a clue about these deep internals, so no idea about anything specific. maybe TripleOsc produces samples at 48 kHz, but before reaching the output they go back to 44.1 kHz without the necessary filter? And then the resulting garbage would be correctly upsampled to 48 Khz and saved? Something along these lines. That's the only difference between CLI and GUI I can think of being the cause. I would guess that since LMMS does not need to open any audio device during CLI export, it will use some default sample rate as the 'project sample rate', and something somewhere breaks and causes aliasing because of that.

If LMMS did not do it, the result would be what happens with the '_cli' versions - the frequencies from 22.05 to 24 kHz (or 22.05 to 48 kHz) would be 'reflected' down to the resulting spectrum due to aliasing.

The low pass (fading) before (or during?) downsampling on import is intentional and necessary. But there should be almost no audible difference. That's why the second spectrum fades out after 20 kHz. When the saved 48 kHz wav file is imported, LMMS apparently downsamples it to the current 'active' sample rate (44.1 kHz) and as a part of this process it applies a ~20 kHz low-pass filter. When the project is exported at 48 or 96 kHz through GUI, it is exported correctly - it sounds the same to me, and plotting the spectrum in Audacity shows the noise goes all the way up to the Nyquist limit. Looking at the original, it is clear that TripleOsc generates noise all the way up to 22050 Hz (since my sound card / system apparently runs at 44100 Hz sample rate and that's what LMMS uses). Here is what the spectrum looks like on my machine (top to bottom is _cli, _gui and original Triple Osc):

Lmms oversampling export