Currently, OpenMPT takes a magic number. In case of 2 samples to 14 samples, it's 0.142857142857142857. The mistake? Sample 7 incorrectly is done as 7 times this magic number, or 0.999999999999999999. Instead, directly the division 7/7 should be used instead.
For everyone missing the context of this cryptic post, you can find it here, including the explanation why this is not going to change: https://bugs.openmpt.org/view.php?id=1007
QuoteInstead, directly the division 7/7 should be used instead.
This is simply not possible. What you want OpenMPT to be is a symbolic calculator, i.e. a calculator that does not immediately calculate the result of a "lossy" operation, but there is no reason in the world why a sampler should do such expensive operations. Upsampling or downsampling by 7 octaves at great precision is way out of the intended resampling range of OpenMPT. If you really insist on having such perfect resampling of a square wave, you will have to draw the square wave yourself.
Then I blame you for telling me to use the forum.
Wouldn't it possible to give users the option to use fast version or accurate version, like in the pitch and tempo change in Audacity?
If you start by taking e.g. a square wave sample that is 256 points long instead of a combination of 2-point, 4-point, 8-point, etc. samples, you won't have any of these problems. We won't add another analytically "correct" (the current one is not any less correct) resampling mode just for this use case. Please re-read and understand manx' comment (https://bugs.openmpt.org/view.php?id=1006#c3183) on this matter, it also applies to this issue.
I want a real solution, not a workaround. Please add a Symbolic Calculator resampling, which is like No Interpolation but correct. Your method (use a magic number and multiply it) simply fails. It's twice the issue than normally because there is no generator of any type, in this case, square wave type of generator is needed.
Also, note that if you make a 2x2 image in Paint and resize it to 14x2, it's correct. Magic? I think not.
It's not a workaround if it produces the correct solution. What you want to be done is simply beyond anything that's remotely sensible. We do not use any magic numbers, we simply use 64-bit fractional integers which is already very high precision. OpenMPT is not suitable for your wish of analytical perfection, please use another piece of software for such things.
I'm sure 256 samples square wave instead of 2 is a workaround. I'm sure it will still fail for some astronomic size.
Audacity told me to use another program for 8-bit PCM
OpenMPT told me to use another program for correct nearest neighbor
What's next? I don't like lazy developers.
There IS a magic number. In case of that 2 to 14 resampling, it's 0.1428571428571429. Isn't it a magic number that's multiplied (or added) each time?
If you call developers lazy, do not expect to get any help from them. We are not your coding slaves. We decide what's reasonable to implement and what you propose is absolutely unreasonable in the context of OpenMPT.
If both programs are not suitable for your needs, you will need to find another program, or write your own. Maybe then you will realize how difficult the things you want to be implemented are, and why pretty much everyone else is happy enough with almost-perfect solutions.
If they ask people to use another program instead of implementing it themselves, they are by definition lazy. Why in the world would anyone think there is another program with same features?
Roses are red
Violets are blue
Paint does it right
And so should you
Neither OpenMPT nor Audacity are meant to be "Swiss Army Knives" of audio processing. They both can do a lot but there is also a lot they cannot do (intentionally). Generally you can assume that both projects implement features they consider to be worthwhile for the majority of users. If they implemented every single feature that was ever requested (and if they actually had the time to, which they don't!), they would be unusable bloatware because their menus would be filled with options and features that only a single person ever needs. OpenMPT also cannot import Cubase project files. Does that mean that its developers are lazy? No, absolutely not. It's reasonable that such a feature doesn't exist.
If you call me or any other open-source developer lazy, then you have zero understanding that I have a live too that is not only about implementing your wishes about OpenMPT. OpenMPT is a spare time project, not my job, and while I already invest more time than is probably healthy, the last thing I need is being called lazy. You have no demands from me unless you pay me for implementing features (and believe me, you cannot afford that).
And before you call the developers anything else in addition to "lazy", I would recommend you to the read the forum rules (https://forum.openmpt.org/index.php?topic=880.0).
Not being able to import Cubase project files is not lazy because it wasn't requested. But an actually good nearest neighbor filter is requested, and you told me to use another program, which is being lazy.
Saga Musix I envy your patience.
8-bit PCM is a legacy feature, and so is Nearest Neighbor that works. So it would make OpenMPT consistent.
QuoteWhat's next? I don't like lazy developers.
Considering the amount of work Saga and manx are putting into MPT's development, and how many smaller or bigger improvements are being made every iteration of it "lazy" is the last thing that comes into mind, especially given the fact that they do this
in their damned spare time.
I'm genuinely curious at this point tho; Why do you insist on this feature so much? Is it stopping you from making quality music with OpenMPT anyhow, or you want it just for the sake of unnecessary perfection?
That's because the current "No Interpolation" filter is simply wrong.
"No interpolation" is strictly speaking mathematically wrong already by the very definition of what it does. The only remaining sensible goal is to make it fast. The implementation you request would require an unbounded amount of processing time and an unbounded amount of memory (the symbolic fractions could grow arbitrarily large in case of continuing pitch changes). This makes no sense whatsoever.
Why 64-bit floating point division would need unbounded memory? If you type 7/7 into calculator, it works. So please for my sake please make it mathematically correct operation instead of rounding errors introduced by adding a magic number over and over. While adding 0.1428571428571429 7 times may not be exact, 7/7 is.
There is no sliding resampling option, like there is sliding time scale/pitch shift in Audacity. So I don't see why this would need to support sliding. The current algorithm has an issue with integer scaling, but sliding resampling will cause a lot of aliasing anyway, not so with integer scaling if the nearest neighbor worked.
Solving the one single special case where there is actually no remainder does not solve the problem in the general case. This is completely and utterly useless as an implementation. I have already explained that in order to devise an implementation you absolutely have to consider ALL POSSIBLE input parameter instead of just one single (or a group of) special case. In the general case, the pitch CAN change during playback, and the fraction will not evaluate without a remainder in almost all cases. The fraction can in fact grow arbitrarily large, as already stated.
Floating point does not solve anything here. Any non-power-of-2 fraction remainder will already have rounding errors by the very definition of how binary floating point works.
For reference: The way this actually works is that, for every output sample frame (i.e. counting output sample rate), the playback position of the sample is incremented by the amount calculated from the sample playback rate relative to output sample rate. Mathematically you have:
pos(n) = Sum(increment(0) + increment(1) + increment(1) + ... + increment(n-1)) ; (n is output sample frame). The sample playback rate can change arbitrarily over time, thus increment can also change dynamically, and is a fraction with (in the precise case) varying denominator. Adding fractions with arbitrary denominator precisely requires unbounded memory and compute time.
As Saga Musix already explained, OpenMPT 1.27 uses 64 bit (32.32) integer fixed-point here, which already has better precision and rounding characteristics as 64bit floating point would have.
Quote
There is no sliding resampling option, like there is sliding time scale/pitch shift in Audacity. So I don't see why this would need to support sliding. The current algorithm has an issue with integer scaling, but sliding resampling will cause a lot of aliasing anyway, not so with integer scaling if the nearest neighbor worked.
https://wiki.openmpt.org/Manual:_Effect_Reference (https://wiki.openmpt.org/Manual:_Effect_Reference)
Portamento, Vibrato, Arpeggio, Pitch Envelope, ...
32.32 fixed point? That's even worse! It only supports less than 10 decimal places (2^32 is less than 10^10) and only numbers from -2 billion to 2 billion. Only the old and destroyed PCs do that.
Even though pitch may change in the song, the sample rate does not. The data of the song doesn't matter in nearest neighbor.
"The way this actually works is that, for every output sample frame (i.e. counting output sample rate), the playback position of the sample is incremented by the amount calculated from the sample playback rate relative to output sample rate."
I already know that adding magic number thing.
My idea, is, that, for resampling, nearest neighbor should use correct (7/7), not risky (0.14285714+0.14285714+...) operations. If the conversion to number storage always rounds down (can be an issue if division algorithm generates 0.1111... in binary) it should be calculated to one more bit which determines rounding.
If you don't use integer resamplings, this: (n*x)/y is the right operation. n is current sample, x is old sample rate, y is new sample rate.
You do understand that a symbolic calculator is an insanely complex undertaking, particularly for such miniscule and irrelevant goals? It is like insisting on positioning objects in a 3D scene correct down to the molecule and therefore requiring bigint libraries for everything.
The human ear cannot perceive this supposed "error". Perhaps if you remastered the audio a billion times it would become relevant, but pretty much *everything* else is more relevant than *that*.
Quote32.32 fixed point? That's even worse! It only supports less than 10 decimal places (2^32 is less than 10^10) and only numbers from -2 billion to 2 billion. Only the old and destroyed PCs do that.
The decimal precision is more than enough and is in fact identical to what many other samplers use. Even if we used 64-bit floating point, the exactly same problem would exist - (1/7)*7 would still not equal 1.0.
Also, OpenMPT does not support samples longer than 256 megasamples at the moment so it does not matter that the integer part of the position cannot exceed 4 (not 2) billion.
QuoteIf you don't use integer resamplings, this: (n*x)/y is the right operation. n is current sample, x is old sample rate, y is new sample rate.
Division is the slowest arithmetic operation even on a modern CPU and while it may not matter if you are playing a single channel, it very much can still matter if you are playing hundreds of channels at the same time, which is what OpenMPT is designed for.
If you assume that we are lazy and know nothing about audio programming after spending (more than) ten years in this field, then please learn how to program and create a better sampler. I will be excited to see it and how well it performs on the type of hardware that OpenMPT supports.
I am fed up with this topic now. Call me lazy as much as you want but I will ignore any further replies that tell me how to write my sampler.
Wow Saga Musix. It took you this long to get fed up. That must be a new record. :)
I totally agree with you though. Precision is one thing, but optimization for performance is another. And they often don't go hand-in-hand.
How can I spend (more than) ten years when I'm 12? Serious? Use your common sense.
Do you think it's not noticeable? Clearly a wave with 11111111000000 is different than 11111110000000 at 8000Hz, clearly not a square wave. It's noticeable in loops if you use integer scaling, as you get 8777...7776 instead of 7777...7777, and the transition from end to beginning makes the loop imperfect.
Quote from: PiotrGrochowski on September 13, 2017, 05:41:14How can I spend (more than) ten years when I'm 12? Serious? Use your common sense
I was talking about the OpenMPT developers. Both OpenMPT developers have spent more than ten years developing audio software. Do you really think that you are an expert on audio programming and know what you are saying while we don't know what we're doing?
I learned to program when I was at your age. You should do the same and prove that you are better than us.
Quote from: Saga Musix on September 13, 2017, 09:38:51
Quote from: PiotrGrochowski on September 13, 2017, 05:41:14How can I spend (more than) ten years when I'm 12? Serious? Use your common sense
I was talking about the OpenMPT developers. Both OpenMPT developers have spent more than ten years developing audio software. Do you really think that you are an expert on audio programming and know what you are saying while we don't know what we're doing?
I learned to program when I was at your age. You should do the same and prove that you are better than us.
Actually that would be very bad. I shouldn't do 18+ things at age of 12.
OpenMPT is open source, fix it yourself.
Quote from: PiotrGrochowski on September 13, 2017, 09:48:47
Actually that would be very bad. I shouldn't do 18+ things at age of 12.
Programming is not (only) an occupation for adults. It can be an exciting hobby if you learn it early and open the doors to your future, since more and more jobs will require programming knowledge. The later you start with it, the harder it will become to understand it.
Quote from: PiotrGrochowski on September 12, 2017, 17:56:13
32.32 fixed point? That's even worse!
Wrong. In the general case (long samples), 32.32 fixed point provides better precision than 64bit floating point.
Quote from: PiotrGrochowski on September 12, 2017, 17:56:13
If you don't use integer resamplings, this: (n*x)/y is the right operation. n is current sample, x is old sample rate, y is new sample rate.
And again you are trying to solve the general case by providing an example for a special case. The sample playback rate might change at a point n that does not allow the fraction to be reduced. You cannot devise a LCM for all possible denominators, you either have to choose a time base and round, or store arbitrarily large integers.
Quote from: PiotrGrochowski on September 13, 2017, 05:41:14
Do you think it's not noticeable?
Yes, it is not noticeable. The precision error in pitch is less than 1 cent even for extreme resampling ratios. This is not noticeable: https://en.wikipedia.org/wiki/Cent_(music) (https://en.wikipedia.org/wiki/Cent_(music)). Stop thinking in the time domain, this will get you nowhere here. And if you do not know what I am talking about, you absolutely will have to do the required background research, even if it takes you multiple years.
The case you describe is AGAIN a special case. The general case has varying pitches where nearest neighbour interpolation is by definition already broken way more than a single sample phase difference or rounding error.
If you for whatever reason need sample-accurate nearest neighbour resampling, and do not care about varying pitches whatsoever at all, use some software that actually tries to solve that use case. OpenMPT surely does not. Your usecase is absolutely meaningless in practice.
However, all of that is even completely irrelevant if you take a closer look at what the sample playback rate actually is supposed to be in practice. It is not an integer and not even a precise fraction. In the nowadays overwhelmingly common default case of equal temperament scale tuning, all but one of the note playback rates per octave are non-integer and non-rational. Your idea is already flawed at the preconditions. There is no precise fraction to even work with in the first place.
Quote from: PiotrGrochowski on September 13, 2017, 05:41:14
How can I spend (more than) ten years when I'm 12? Serious? Use your common sense.
So, it should not be that surprising at all to you that people who have worked more than 10 years in the field actually know things better than you, right? You have demonstrated multiple times that you did not think through your ideas thoroughly (which is totally fine, given the age), but when we tell you multiple times that your ideas are flawed, you absolutely have to step back somewhen and accept that you do not have the required background knowledge yet to fully understand all aspects (which again would be fine). But then, you not only expect us to explain things in a couple of forum posts that would normally take years to learn, and additionally also keep insisting on the same flawed concept over and over again? How are we supposed to solve that? By now, you are honestly only wasting everyones time, including your own, here.
Also, kindly asking how and why the mixer and resampler is implemented the way it is would probably have been more helpful for you and everyone else, rather than repeatedly insulting the developers and insisting on impractical ideas. Please reconsider your attitude.
Stop thinking in frequency domain, it's not relevant.
Please kindly add that nearest neighbor that even works as an option and everything will be okay. No other program has rounding errors with integer scaling, so copy source code of them.
@PiotrGrochowski: Just because you want a feature in doesn't mean it will happen.
It has been said enough times that it won't happen and that the difference are insignificant, but you seem to think that your opinion is more important than the developers and other users.
Frankly, as administrator of this forum, I feel the duty to step in, and therefor I'm going to lock the topic. If you want this feature so badly, learn to program and add it in yourself. But be warned, OpenMPT may become slow and crash often as a result.