View Issue Details

IDProjectCategoryView StatusLast Update
0001007OpenMPT[All Projects] Generalpublic2017-08-31 13:05
ReporterPiotrAssigned To 
PrioritynormalSeveritytweakReproducibilityalways
Status closedResolutionno change required 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT 1.26.12.00 / libopenmpt 0.2-beta26 (upgrade first) 
Target VersionFixed in Version 
Summary0001007: Nearest Neighbor - wrong result
Description

If I have 2 samples, 1, -1 (8000Hz) and resample it to specific even numbers, such as 14 samples (56000Hz) with nearest neighbor, it gives me
1 1 1 1 1 1 1 1 -1 -1 -1 -1 -1 -1
with 8 1's and 6 -1's
It's supposed to give me
1 1 1 1 1 1 1 -1 -1 -1 -1 -1 -1 -1
with 7 1's and 7 -1's.
This has really bothered me for my custom "Period" frequency scale, where there are pitches 0-31 where their number determines number of 8000Hz samples looped.

Steps To Reproduce

Have 2 samples, 1, -1 (8000Hz) and resample it to specific integer multiple (such as 56000Hz for 14 samples) with no interpolation.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

Saga Musix

Saga Musix

2017-08-11 11:01

administrator   ~0003156

Computers are bad at periodic numbers. The ratio of 8/56 (or 1/7) is periodic (0.142857142857142857...) and thus cannot be stored perfectly. As a result, the sampler cannot hit every sampling point precisely and sometimes is of by +/-1. In any other resampling mode than Nearest Neighbour, this is not a problem because they look at the fractional part of the sample position as well, but it's in the definition of Nearest Neighbour that we do not look at fractional sample positions.

Hence, there is nothing we can do here. Resampling by almost three octaves using Nearest Neighbour is a very bad idea anyway. You will have to fix your sample yourself and live with that fact.

Piotr

Piotr

2017-08-11 12:54

viewer   ~0003159

I did not intend to resample. I intended to replace 2 period by 14 period.

Please show me debug log

Saga Musix

Saga Musix

2017-08-11 12:55

administrator   ~0003160

No matter what you wanted to do, you can manually fix the result by using the sample draw feature: Click the pen icon and correct the one offending sample point.

Piotr

Piotr

2017-08-31 05:49

viewer   ~0003198

Last edited: 2017-08-31 10:14

View 2 revisions

I don't see where the rounding error should be, and I don't see division by 7 either.
Resampling 2 to 14 samples - 14/2=7 factor
Sample 0*7=0
Sample 1*7=7
So won't that be 0 to 6 and 7 to 13 without rounding errors? I don't understand it.

Saga Musix

Saga Musix

2017-08-31 10:09

administrator   ~0003200

I don't see where the rounding error should be, and I don't see division by 7 either.

Upsampling by a factor of 7 means that the step increment is 1/7. So OpenMPT needs to step in increments of 0.142857142857142857... through the sample per sample, and that is a periodic number as said.
Computers cannot represent periodic numbers with infinite detail, so the period has to be cut off at some point. Let's assume 1/7 is represented as 0.142857142857142857, which is already a higher precision than what OpenMPT can represent internally.
At step 0, the sample position is 0.
At step 1, the sample position is 0.142857142857142857.
...
At step 7, then sample position is 0.999999999999999999 - NOT 1 as you would expect.
You see that even at a higher precision than what OpenMPT internally uses, the sample position will still not reach the first sampling point even though if the computer had infinite precision, it would have done so. These rounding errors become more obvious over time, leading to the problem you discovered.

Piotr, this is the last warning. I told you before that your behaviour of discussing with developers about things they have already justified is not welcome. If you do this once more, I will have to remove your access to the bug tracker. If you have specific questions about resampling, ask them on the forum, but not on the bug tracker.

Piotr

Piotr

2017-08-31 12:47

viewer   ~0003201

How about using different division, like 7/7, not multiplying 1/7 by 7?

Piotr

Piotr

2017-08-31 12:48

viewer   ~0003202

Also, once again, I'm not registered to forum!

Saga Musix

Saga Musix

2017-08-31 13:05

administrator   ~0003203

You can register at https://forum.openmpt.org/index.php?action=register
Or just stop commenting on this issue. I already explained everything that's to be explained.

Issue History

Date Modified Username Field Change
2017-08-11 04:36 Piotr New Issue
2017-08-11 11:01 Saga Musix Status new => closed
2017-08-11 11:01 Saga Musix Resolution open => no change required
2017-08-11 11:01 Saga Musix Note Added: 0003156
2017-08-11 12:54 Piotr Status closed => feedback
2017-08-11 12:54 Piotr Resolution no change required => reopened
2017-08-11 12:54 Piotr Note Added: 0003159
2017-08-11 12:55 Saga Musix Status feedback => closed
2017-08-11 12:55 Saga Musix Resolution reopened => no change required
2017-08-11 12:55 Saga Musix Note Added: 0003160
2017-08-31 05:49 Piotr Status closed => feedback
2017-08-31 05:49 Piotr Resolution no change required => reopened
2017-08-31 05:49 Piotr Note Added: 0003198
2017-08-31 05:54 Piotr Status feedback => new
2017-08-31 10:09 Saga Musix Note Added: 0003200
2017-08-31 10:10 Saga Musix Status new => closed
2017-08-31 10:10 Saga Musix Resolution reopened => no change required
2017-08-31 10:14 Saga Musix Note Edited: 0003198 View Revisions
2017-08-31 12:47 Piotr Status closed => feedback
2017-08-31 12:47 Piotr Resolution no change required => reopened
2017-08-31 12:47 Piotr Note Added: 0003201
2017-08-31 12:48 Piotr Note Added: 0003202
2017-08-31 12:48 Piotr Status feedback => new
2017-08-31 13:05 Saga Musix Note Added: 0003203
2017-08-31 13:05 Saga Musix Status new => closed
2017-08-31 13:05 Saga Musix Resolution reopened => no change required