Fixes issue with track length mismatch after resample

[vsverchinsky]

It could happen so that after resampling number of samples contained in GetPlayEndTime() - GetPlayStartTime()
didn't match to number of samples in GetPlayEndSample() - GetPlayStartSample()

Resolves: #2113

• I signed CLA
• The title of the pull request describes an issue it addresses
• If changes are extensive, then there is a sequence of easily reviewable commits
• Each commit's message describes its purpose and effects
• There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• Each commit compiles and runs on my machine without known undesirable changes of behavior

[Paul-Licameli]

The small changes look harmless, but I don't understand why they fix a crash.

Would it be better to apply the small corrections in mTrimLeft and mTrimRight within WaveClip::Resample?

[vsverchinsky]

The small changes look harmless, but I don't understand why they fix a crash.

Because the amount of samples returned by WaveClip::TimeToSamples(trim) depends on current sample rate. When applying resampling it may happen so that trim value does not exactly match the beginning of the sample any more. And the bug comes from difference in the way number of samples is calculated: WaveClip::GetPlaySamplesCount adjusts trimmings to the sample rate, and WaveClip::GetPlayEndTime() and others - do not, so WaveClip::TimeToSamples(WaveClip::GetPlayEndTime() - WaveClip::GetPlayStartTime()) may not be equal to WaveClip::GetPlaySamplesCount, sometimes leading to an OOR.

Would it be better to apply the small corrections in mTrimLeft and mTrimRight within WaveClip::Resample?

It may work in that particular case, but I don't see why it's better. Functions mentioned above still return different values, which should be fixed anyway, so it becomes unnecessary to fix Resample. Also, resample(newSampleRate)->resample(originalSampleRate) may change original trimming values, while with this fix preserves them.