LÖVE

Hello there,

I've finally gotten around to actually trying to get my XM files working properly in love again (see previous thread ), and everything is going along just fine other than a resampling problem I'm having.

When I'm making/listening to my tracker files (XM files made in MilkyTracker) I set the resampling to "No Interpolation" as I don't want any resampling, but when I play that same xm file in love, it is clearly doing some resampling as the more complex samples sound much worse. When I set MilkyTracker to use "Linear Interpolation" as the resampling algo, it sounds pretty much exactly how love outputs it.

So my question is, is there a way to set the resampling algorithm for tracker files with a love api call or anything accessible in Lua? Or would this change require some C code changes or something in the source? I know love uses libmodplug which has resampling algo settings.

Thanks so much for the help!

"No interpolation" does not mean "No resampling". It's just the lowest quality resampling method.

I don't think there's a way to play an XM without resampling. You would basically need an audio player without different notes, just always the same note for each sample. Different notes mean the samples are resampled at different frequencies.

Okay, thanks for that clarification. Though I am confused by no resampling being the lowest quality, it doesn't seem that way to me in terms of sound quality. No interpolation preserves the sample quality and does not make it sound flat or altered in any way.

That said, the resampling algorithm being used by love is still different than what I would like it to use.

manadream wrote: ↑Tue Aug 25, 2020 7:50 pm Okay, thanks for that clarification. Though I am confused by no resampling being the lowest quality, it doesn't seem that way to me in terms of sound quality. No interpolation preserves the sample quality and does not make it sound flat or altered in any way.
That said, the resampling algorithm being used by love is still different than what I would like it to use.

No resampling would only happen if the sampling rate of the system is equal to the sampling rate of the music file you want to play back... this is true for stuff like PCM-encoded wav files, but less for mp3, and for tracker modules specifically, the samples used in those are most definitely never anything even near today's 44.1 and 48 kHz rates (most ST-** samples are 8000 Hz or less)

Besides, all trackers do resampling; otherwise you couldn't play notes other than the base note, which is the one that doesn't modify the playback speed (pitch) of a sample.

That said, "no interpolation" is also known as zero-order hold and nearest-neighbour interpolation, where no matter where the cursor/pointer that says what value to return is, it won't calculate any intermediate values from the nearest samplepoints; it'll just return the closest one.

The reason it "sounds better" is mostly subjective... the fact being that interpolating samples that have low sampling rates means removing high-end artifacts from the sound; in some samples (mainly percussions), that will muddy up the sound basically.
However, technically, sinc-interpolation with enough points is the highest quality method one can implement; difference is, it won't alias/reflect sound around the Nyquist limit (sampling rate / 2), and the higher you pitch something with that method, the more it'll become a single sine wave (no overtones due to them being outside the freq. range the sampling rate can represent) instead of keeping the artifacts in, which'll sound tinny/metallic... usually.




Unfortunately, löve treats tracked music the same way as other non-notation-based formats, meaning it doesn't expose any special controls for any decoders.

However, someone made a library wrapping most of libOpenMPT, that you can find here which might be a solution (though not on windows, atm), however i must point out that while i quickly read through the docs in 3 places, i didn't find a way to change the interpolation, or "mixing mode" setting: https://love2d.org/forums/viewtopic.php?f=5&t=89317

manadream wrote: ↑Tue Aug 25, 2020 7:50 pm Okay, thanks for that clarification. Though I am confused by no resampling being the lowest quality, it doesn't seem that way to me in terms of sound quality. No interpolation preserves the sample quality and does not make it sound flat or altered in any way.

It seems you keep confusing resampling with interpolation.

No interpolation is the lowest quality interpolation method (there's actually no such thing, see below).

No resampling preserves the original sample's quality, but that can only happen when the original sound's sample rate matches the sound card's output frequency.

Remember that typical sound cards have output frequencies of 44100 or 48000 Hz, therefore to preserve this quality, all samples must have been sampled at that frequency and played without any frequency change, which means you can't get different notes from the same sample, and that you have to use a different set of samples depending on the sound card's output frequency. It's possible to have a module consisting of one sample per note, and all samples at the same frequency, and play a different sample whenever you want to change the note, and then have one module per typical output frequency, but it would take much more space and time to prepare. In this scenario, interpolation would be useless, as it would do nothing by definition (or it can even alter the sound if it isn't real interpolation).

In order to generate different notes, a tracker must be able to play each of the samples at many different frequencies, and since the audio card has a fixed output frequency, the only way to do this is by resampling, and to do that, in almost every case you need to interpolate (the only exception is if you need to downsample to a frequency that is the original sample frequency divided by an integer, which in practice almost never happens).

"No interpolation" is actually a misnomer. Interpolation, by definition, consists of determining values between existing samples, and is needed when you resample a sound such that some of the new samples lie between two of the samples of the original sound, which will happen in all cases except the rare one mentioned above. The interpolation algorithm that we usually call "no interpolation" is actually "left neighbour" interpolation (or it can refer to another one which is rarer in audio, but more common in imaging: "nearest neighbour").

It's similar to the case of images. Say you have an original "analogue" image (not an image file, but a real life scene) and you want to convert it to a bitmap by taking a photo with a digital camera (let's assume it's a B/W photo for the analogy to be closer). You need to choose a resolution (equivalent to the sampling frequency in audio). Then the camera converts it by approximately averaging the light in each small square pixel and turning it into one sample value for that pixel. This bitmap is our original sample. Say it's a 512x288 image. In our audio equivalent, for this example it will be a 16KHz sound.

But LCD monitors (sound cards) have a fixed resolution (output frequency). You can't draw that 512x288 image (16KHz sound) at full size in a 1920x1080 monitor (48KHz card) without scaling (resampling). At best you can show (play) it at its original scale (sampling rate) so that each image pixel is in one LCD pixel (so that each audio sample corresponds to one sound card's output sample). Here the analogy breaks a bit because if you display the image at 512x288, it's still recognizable, but if you play the 16KHz sound at 48KHz, it will sound extremely high-pitched. But please bear with me.

But in order to make collages (music notes) you need to be able to place the image at different sizes (play the sound at different rates), and unless you took one picture for each resolution (one audio for each note) that you're going to use, you're going to need an interpolation algorithm in order to scale (resample) the image (sound).

In terms of preserving the original image's (sound's) quality, the nearest neighbour method is pretty bad. It has visible (audible) squares (artifacts). Remember that we're not talking about pixel art, but real world images. In most cases, a better interpolation algorithm can help making the image (sound) be more pleasant to look at (hear). Still, if your original image (sample) has a poor resolution (sampling rate), it's going to look (sound) bad; probably blurred (muffled).

pgimeno wrote: ↑Wed Aug 26, 2020 2:39 pm In order to generate different notes, a tracker must be able to play each of the samples at many different frequencies, and since the audio card has a fixed output frequency, the only way to do this is by resampling, and to do that, in almost every case you need to interpolate (the only exception is if you need to downsample to a frequency that is the original sample frequency divided by an integer, which in practice almost never happens).

Emphasis mine, and i wanted to mention a historic tidbit here; originally, trackers existed on the Amiga (Chris Hülsbeck's C64 tracker coming out around or before Karsten Obarski's Ultimate Soundtracker, the first Amiga one, but i digress), and the Amiga's Paula chip actually had 4 hardware channels with the sampling rate being adjustable; it wasn't fixed like in our "modern" cards, and due to that, the tracker software just set the correct rate with which to output the samples at.

Apart from this detail though, even then, setting the rate also had its own precision limit, but since the samples' rates were (if i remember correctly) integers, and could be set as they were as the sampling rate to the hardware channels, there were no need to implement any kind of interpolation (other than it doing nearest neighbor by default... or at most linear, due to that being about as processing heavy as nearest neighbor)... this did mean that most trackers during that time had the sound never be muffled due to higher order interpolation... a taste people learned to like and expect, no doubt.


...sadly no solution for the thread's issue still... XM's a buggy format though, i could tell you to use S3M instead and plug my tracker library that can replay S3M modules, where you can indeed select the interpolation method... but it's incomplete for now, sadly. :v

Thanks to you both for the info and clarification. I see how I was mistaken and confused.

That said,

zorg wrote: ↑Wed Aug 26, 2020 7:43 am The reason it "sounds better" is mostly subjective... the fact being that interpolating samples that have low sampling rates means removing high-end artifacts from the sound; in some samples (mainly percussions), that will muddy up the sound basically.

This is exactly my problem, my instruments, especially percussion, are getting muddied up, and I prefer for that not to be the case

zorg wrote: ↑Wed Aug 26, 2020 7:43 am However, someone made a library wrapping most of libOpenMPT, that you can find here which might be a solution (though not on windows, atm), however i must point out that while i quickly read through the docs in 3 places, i didn't find a way to change the interpolation, or "mixing mode" setting: https://love2d.org/forums/viewtopic.php?f=5&t=89317

I looked into this and I can change the interpolation algo using this library by calling and setting the OpenMPT render param OPENMPT_MODULE_RENDER_INTERPOLATIONFILTER_LENGTH to However, since this does not work in Windows, I won't use it in my project since I target Linux, Mac and Windows. So it looks like I'll just have to keep using wav files for now

manadream wrote: ↑Sat Sep 05, 2020 6:47 am I looked into this and I can change the interpolation algo using this library by calling

Code: Select all

OpenMpt:set_render_param(param, value)

and setting the OpenMPT render param OPENMPT_MODULE_RENDER_INTERPOLATIONFILTER_LENGTH to

Code: Select all

1: no interpolation (zero order hold)

However, since this does not work in Windows, I won't use it in my project since I target Linux, Mac and Windows. So it looks like I'll just have to keep using wav files for now

To be fair, it might work on windows, i just haven't had the opportunity to set it up and test it yet; there might be ways to have it be supported. If i get around to it, then it might very well be the best current solution.

Ah, I see, I see. Okay cool. If I find the time I may give it a test on Windows myself, and if I do I'll be sure to post here with my results. (I don't have a Windows machine on hand, but a friend does so I might eventually give it a shot).