Stretch markers audio quality degredation.

[Airal]

Stretch markers have a logic bug in them, IMO. They are constant on their interval but they should be linear(sort of like envelopes but here, we end up with timing issues because of the way time works).

For example, suppose you play a steady beat on a snare that changes tempo linearly.

Now if you use stretch markers to make the time constant then basically ever point after the stretch marker, any notes will get more and more off depending on how far they are in the bar. You are effectively quantizing the tempo but only at the points where the stretch markers exist will it be exact. Any notes in between will be off because they were actually at a different tempo. If the tempo was increasing then the notes will be delayed and if it was decreasing then it would be anticipated from where it would have actually been if played at a constant tempo.

e.g., suppose we have a "note" at t = 0, at t = 0.7 and at t = 1.2. If these notes were suppose to be equally spaced we'ed expect them at t = 0, t = 0.5 and t = 1.

we put a stretch marker at t = 0 and t = 1.2 and move the t = 1.2 to t = 1. This "squishes" everything between t = 0 and t = 1.2 down to t = 0 and t = 1.

But the note in the middle? It should be 0.5, but is it? It's easy to calculate where it is when we use a constant change:

(1.2 + 0)/2 = 0.6 and we'd expect it to be at 0.5 when squished but what we actually see is that it is at 0.7*(1 - 0)/(1.2 - 0) = 0.58.

This means with the constant stretching per interval, our note that is suppose to be at 0.5 is at 0.58 and this is can be enough to make the music very off rhythmically(a weird feel).

You might say that this doesn't matter because we can add a stretch marker to the notes in between and fix the middle note... but then what about the middle notes of the middle note? (the note at 0.3, say?) Basically everything ends up off and we'd have to add an infinite number of stretch markers to make everything correct... or just allow for linear transitions in stretch markers.

Basically linear transitions require far fewer stretch markers to properly correct timing. Almost tempo changes are gradual and so are linearly approximated well as long as the resolution of the stretch markers are "close"(maybe over a bar), which they tend to be.

You might not think that this is a big musical problem but try it and see. Find some music that has clearly defined notes in the wave form and has tempo drifts and try to correct them to exact consistency(you can use midi to know where the notes are exactly)... you'l find that notes are off and there is no easy way to fix them. If you are time correcting a long track, you'll expend an order of magnitude of time adding stretch markers than you need to if they linearly(or better yet, a higher order interpolate) transition.

Maybe a better thing to do would be simply to have an envelope be able to act as time stretching. This should be easy to implement and leverages all the things reaper already has for envelopes. This then makes it easy for someone to select how they want to deal with the problem.

[heda]

If I understand correctly, stretch markers have a rate modifier that can be used to create those ramps you mention.
Look for stretch marker rate in mouse modifiers.

[juliansader]

Originally Posted by Airal

e.g., suppose we have a "note" at t = 0, at t = 0.7 and at t = 1.2. If these notes were suppose to be equally spaced we'ed expect them at t = 0, t = 0.5 and t = 1.

I do not quite understand? t = 0.7 is not in the middle between 0 and 1.2, so I would not expect it to end up at 0.5 after stretching.

[Airal]

Heda: thanks, I'll check it out and see

Julian:

let | be a note event and the space is approximately proportional to time.

So a steady note pattern at some tempo could be represented like

| | | | | |

Now, suppose the pattern ramps in such a way that the average tempo's are the same:


| | | | | |


Now, add in a middle hit represented by *(approximately above due to the resolution limitation):

| * | * | * | * | * |
| * | * | * | * | * |

Now, when a human is performing, his tempo is never constantly perfect. He is making these little ramps up and down over every level of his playing.

E.g., there are minute changes and large scale changes. So, a human generally falls in to the second category, although it is really just a generalization of the first(since the ramp could be horizontal... I'm simply saying that humans don't play that way even if they have great time so we have to analyze the second case). Of course, even higher levels might be required to do it more accurately but linearity covers a lot of ground.

To see how the scaling is wrong for "square"(constant), scale the second note event down so that the event matches with the "perfect" case:


| * | * | * | * | * |
| * | * | * | * | * |

The two middle events are off. You said 0.7 shouldn't become 0.5 because it's not in the middle! Yes, 0.7 is not in the middle, BUT IT SHOULD BE!

So, it's not that your math is wrong, it's that you assume that the result represents the correct case, and it is not.

WE want both *'s to align.

If we are trying to correct the bad performer who plays from 100bpm to 110bpm change over a single bar so that it is a constant 100bpm, we put a stretch marker on the bars and scale the bar so that it's end corresponds exactly to the end of what it should be. Right? This is what I did above using a different notation.

But when we do it only at the bar, the notes between the bars are off. Like you said, 0.7 when scaled doesn't become 0.5! BUT IT SHOULD! If the drummer is playing in perfect linear time, then when he it at "0.7" it's the same as if he hit at 0.5 in perfect constant time.... but the mathematics that reaper uses is wrong because it treats everything as perfect constant time... which it is not.

In perfect linear time, the middle of a bar is not equally spaced... yet stretch markers treat it that way because it treats everything as if it were perfect constant time. Again, which virtually no human performed music is.

What's more is that perfect linear time covers perfect constant time so it doesn't hurt to use it, it only helps correcting the timing issues.

Another way to see this.

Suppose you have a 1m song in perfect constant time at 100bpm. You then "linearize it" by having it's tempo increase constantly from 100bpm to 110 bpm over the 1m.

You render that song, import it back in to reaper. Now, you know the song was at 100bpm and is 1 min long, so that means new version is 1*110/100 = 55s

That means, if you use stretch markers, place one at the start, and one at the end and stretch the end so that the new song length is now 1m again and compare to the original song you will hear the flaw in your logic.


If you want a quick demo:

0. Set proj to 60bpm.
1. Create a 1m long click source.
2. Render it to a stem.
3. create tempo markers at start and end. Set end to 70bpm.
4. select stem and change rate back to 1.
5. scroll to end and notice how the hits are not lined up.

Why? the stem is in 60bpm, it did not change. The project is in a 60bpm to 70bpm ramp. This should be obvious. This is just like one person playing at 60bpm and another coming in and playing at 60bpm but having a linear tempo change of 10bpm.

5.5. Use stretch markers at the start and end the item to scale it to end where it "should be"(which is at the 70bpm stretch marker.


6. Create another click source same as before but to this new tempo.
7. Render it.
8. Delete the tempo markers so you are back in to a constant 60bpm project.
9. Fix up the rate changes of the stems back to 1. Make sure they start on the same beat and bar.

From here, you can rescale the second item using stretch markers so that the last beat is aligned with the last beat of the other. You should realize immediately that almost all the beats between the start and end are off. This is what is happening to your music when you use stretch markers! Every note between the two stretch markers is going to be off. The more the timing deviates from perfect constant time(the mode stretch markers work in) the more your music is going to sound jumbly when you try to correct it. You might think you have the tempo correct but it's only correct at the stretch markers.

It's simply the wrong mathematics, or at least an oversimplification. constant interpolation is rarely good unless done at high resolution... which we don't use in reaper. It would be nice if reaper addressed this issue, it's not the only problem. Reaper has sound quality issues... many daws do, but I think reaper needs more work in this department rather than feature requests. To many people with too little observations jump to the same conclusions you have and it leads to poorer quality music. These little timing errors are a big deal. It might not seem like much or is too subtle, but they add up to produce a certain "feel".