View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001547OpenMPTGeneralpublic2022-01-10 11:322022-01-10 17:55
Reportercs127 Assigned ToSaga Musix  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Platformx64OSWindowsOS Version10
Product VersionOpenMPT 1.30.01.00 / libopenmpt 0.6.0 (upgrade first) 
Target VersionOpenMPT 1.30.02.00 / libopenmpt 0.6.1 (upgrade first)Fixed in VersionOpenMPT 1.30.02.00 / libopenmpt 0.6.1 (upgrade first) 
Summary0001547: Automatic Sample Trimmer destroys some samples with bidirectional loops
Description

If there are any samples with bidi loops that play long enough to loop at least once, the sample trimmer shortens them to only a few bytes, basically removing the sample.

I found out that the first version to have this bug is 1.30.00.54 revision 15933.
Every newer version (including 1.31.00.xx) is also affected.

I have attached an IT file that you can use to reproduce the issue.

In the IT file, if you replace the note in pattern 0 with C-5 or lower, the sample will not have enough time to do a full loop before that pattern restarts, so the problem only happens if the sample loops at least once, anywhere in the song.
However, this problem might be more general, and also occur in other situations. I haven't tested every possibility.

Steps To Reproduce
  1. Download the attached IT file and open it in OpenMPT 1.30.00.54 revision 15933 or newer.
  2. Use the Automatic Sample Trimmer. It's not supposed to trim the sample at all, but instead trims it to 4 bytes.
TagsNo tags attached.
Attached Files
bidi_loop.it.zip (252,107 bytes)
Has the bug occurred in previous versions?No
Tested code revision (in case you know it)15933 and newer

Activities

Saga Musix

Saga Musix

2022-01-10 12:17

administrator   ~0004986

The issue existed before r15933, but was exposed in a different way: The sample ends up with a negative play position when reaching the start of the loop, which previously was just interpreted as a very large unsigned integer, causing the sample not to be trimmed at all. Now with r15933 there is a small value added to that very large unsigned integer, so it overflows to a very small unsigned integer again, exposing a new problem.
Saga Musix

Saga Musix

2022-01-10 17:54

administrator   ~0004987

Fixed in r16482 by checking the sample position before advancing it, not after, if the sample is played in reverse. Previously (both before and after r15933) samples that were simply played in reverse (didn't need to have a bidi loop at all) were also affected by this bug, chopping off the last few bits of the sample each time the sample trimmer was run.

Issue History

Date Modified Username Field Change
2022-01-10 11:32 cs127 New Issue
2022-01-10 11:32 cs127 File Added: bidi_loop.it.zip
2022-01-10 11:34 Saga Musix Assigned To => Saga Musix
2022-01-10 11:34 Saga Musix Status new => assigned
2022-01-10 12:15 Saga Musix Target Version => OpenMPT 1.30.02.00 / libopenmpt 0.6.1 (upgrade first)
2022-01-10 12:17 Saga Musix Note Added: 0004986
2022-01-10 17:54 Saga Musix Note Added: 0004987
2022-01-10 17:55 Saga Musix Status assigned => resolved
2022-01-10 17:55 Saga Musix Resolution open => fixed
2022-01-10 17:55 Saga Musix Fixed in Version => OpenMPT 1.30.02.00 / libopenmpt 0.6.1 (upgrade first)