Audio fade-in always late by one frame

I was hoping this would be my first bug fix, but I was immediately baffled by the code.

Reproducing this is easy; I created some noise and silence with audacity, then with a 24 fps profile (to make it easy to find frame boundaries later), added a one-second clip of noise, then a one-second clip of silence right after it, then faded in/out the noise by one frame.

The output was as I expected, based on experience; the fade-in was late by one frame. Looking at the output in audacity, frame 0 was silent, and the sound faded in between the beginning of frame 1 and the beginning of frame 2. It faded out accurately, though.

What was baffling is, in the mlt file, the first fade was in="0" out="1" (with "in" missing because apparently its default value is 0). That would make sense; the fade is supposed to start at the beginning of frame 0 and end at the beginning of frame 1. But like I said, the actual fade is late by one frame. The baffling part was the fade-out transition; it was in="22" out="23"; the one-second noise clip actually ends before frame 24.

So it seems that either the in/out frames for volume transitions aren't very intuitive, or kdenlive is (inadvertently?) working around an mlt bug. I would expect frame numbers to represent a specific point, e.g. the time of the beginning of the given frame. But the frame values that represent the fade-out transition are not intuitive to me.

The "easy" fix would be to move the fade-in transition frames back one, but in my example, that leads to an "in" of -1, which appears to represent the end of the output; the result was the sound faded in evenly from the beginning of the output to the end of the output. So, although this easy fix could work for most fade-in transitions, it won't work for a fade-in starting at frame 0.

My mlt file was generated with kdenlive 18, but the same issue happens in kdenlive 20; instead of frame numbers, there are frame times with millisecond resolution. But the same nonintuitive frame coordinate system is in use, and fade-ins are still one frame late.

So it appears that I can't move forward with this analysis, until I get some clarity on the meaning of the coordinate system.

Sorry to lean on you again like this...I was really hoping this would be the first bug fix I contributed.

Start by reproducing the 24 fps example described in Audacity and inspect the generated MLT file, especially the fade-in and fade-out transition coordinates. Trace how those frame or millisecond values are interpreted, then verify that the fade-in starts at frame 0 without breaking the fade-out behavior.