Incorrect playrate calculation with imported media (embedded tempo?) (FIXED)

[PitchSlap]

So I've noticed a bug importing media items.

It might have to do with the recently introduced options to time-stretch based on embedded tempo info, but I tried turning off the options I thought were relevant.

As the LICEcap shows the Media Explorer is playing the item at a sensible playrate that works with the project tempo and is almost the items regular playrate, but when it's inserted into the project the playrate is halved (it's the same when dragged from the waveform preview as well).

The expected behaviour is that the playrate would both match the Media Explorer and use a matching value that keeps the item the least altered.


My guess is Reaper is assuming an incorrect number of bars as there was a similar issue when calculating project tempo from time selection.
Changing "measure beats" in the items playrate:set setting fixes the issue, but the Reaper should assume the correct number like the Media Explorer does.

I've also had another issue where imported tempo-matched selections will be slightly less than the expected 2 or 4 bars. I haven't had a chance to use Reaper much since late 5.x so don't know when these issues were introduced.

[PitchSlap]

*Update* Strangely with the same steps that reliably showed the issue yesterday, it now works as expected so it may not be so easy to figure out.

Here's some exact steps to reproduce the issue with an example wave file.

1) Start a new project with a BPM of 80.

2) In the Media Explorer with Tempo Match on browse to the file below and preview:

https://drive.google.com/open?id=1YD...4AC0giSIln0ezM

3) The playrate should say 1.455.

4) Insert the file into the project by dragging or with an action.

5) The playrate will now be half what it just was. 0.727.

The expected behavior is the inserted item always matches the preview.


How to fix it:
-Click "Set" beside the playrate display in the item properties.
-Change "Measure Beats" from 8 to 4.

This doesn't always happen, but it happens often and is definitely a new issue as I'd never encountered until recently. Maybe a bug with embedded or implied tempo information?

The other issue mentioned in the original post seems similar as an imported item may have a "Measure Beats" setting of 0.2.2 etc, when the Media Explorer was tempo-matching at 0.2 etc.

**EDIT**
If I drag the file from Windows Explorer Reaper asks if I want to use the tempo suggested by the filename, choosing yes gives the same result as inserting from the Media Explorer. What could be happening is that when the file is inserted from the Media Explorer Reaper acts as if I'd agreed to that (even though the setting is turned off). The media import settings for embedded tempo say the Media Explorer overrides, but perhaps in some instances it doesn't?

The detect tempo from time selection had a similar problem, it always assumed the wrong number of bars. In my experience 4 bar loops are most common, but Reaper assumes 8, which halves the playrate.

Maybe here?
+ Media items: add preference to set imported media items with embedded tempo to auto-stretch at project tempo changes
+ Media items: support calculating playback rate from user-supplied tempo or length in beats

[z.curve]

I've also noticed awry tempo-matching of imported media, specifically REX files with tempo information in their filename. Please see the very simple attached project, which features two identical REX files with the only difference being their filename. One imported file is tempo-matched correctly, but the other file appears to have tempo-matching *applied twice*.

The issue is hard to pin down, but there are some necessary conditions:

- The imported media tempo needs to differ from the Project tempo.
- Tempo match needs to be on. Half and double modes are also affected.
- When the prompt appears asking how to handle embedded tempo information, it only fails on option #2 (A single loopable media item that adjusts to project tempo) or option #3 (A single loopable media item with transient markers). Whereas option #1 (Beat slices that dynamically adjust...) and option #4 (Ignore slice and embedded tempo...) never exhibit the issue.

I didn't notice this pre-v6, and suspect it relates to this version's handling of tempo information in filenames.

Since REX authoring tools always embed super-accurate tempo *metadata*, I would suggest there's no need to pay any attention to the *filename* tempo information under any circumstances for REX files (.REX, .RCY, .RX2). But more broadly, potentially this tempo-matching issue is broader than just REX files, and this info adds something to the OP's reported issue with importing WAV files.

Edited 13-May-2020: Removed incorrect assumption about Media Explorer needing to be in Windows Explorer mode.

[PitchSlap]

This just isn't right. The calculation is assuming the wrong number of bars, and doesn't have upper/lower bounds as a sanity check.

With a project tempo of 115BPM (or any really), the chances that a loop is intended to be 240BPM are exceedingly low (sorry breakcore folks).



There was a similar issue in the past where Reaper would calculate project tempos of ~30BPM so likely a similar solution.

If (TempoCalculation > 175)
Measure.beats / 2;
else if (TempoCalculation < 60)
Measure.beats * 2;

Basing the upper number on the current project tempo would make the most sense as 170-175 is common for drum and bass and some people produce in double-time to increase the resolution of step sequencers like FL Studio.

[vanhaze]

Just digging this up.

I experience the very same here in OSX version of Reaper.
Really annoying ..

[schwa]

I believe the media explorer will only display the bpm if the file has embedded tempo information. Otherwise, tempo matching will display something like "1.1x" in the lower right.

If you think the explorer is incorrectly displaying the embedded tempo information for that file, could you share the file?

[z.curve]

Here's a couple of test projects, each with hard evidence of an incorrectly tempo-matched import - a single media item that previewed one way but imported another way.

(You can browse to the project folder and compare previewing and importing for yourself. I find tempo-matched importing of WAV files and REX loops often works as expected/previewed, but not all the time. I swear sometimes it's the same files that initially don't work, then later do.)

Tempo-match-fail-REX-01.RPP
Contains a 1-bar 140bpm REX file, imported with tempo match on, into a 160bpm project. It previewed correctly, sounding at 160bpm, with the Media Explorer status bar reading "140bpm x 1.143". That adjustment figure is correct, but when imported (using slice import option "A single loopable media item that adjusts to project tempo") it doesn't fit a full bar of the project. The Item Properties show a playback rate of 1.142857 - but I think REX files should always be set to 1.0, as it's the slice positioning which govern the tempo, not the playback rate. And thanks to that wrong rate, the item length is too short.

Tempo-match-fail-WAV-01.RPP
Contains a 1-bar 60bpm WAV file, imported with tempo match on, into a 160bpm project. It previewed nicely with the Media Explorer status bar reading "x1.333"; no BPM is displayed as there's no embedded tempo information. But when imported, it plays back twice as fast as the preview. The Item Properties show a playback rate of 2.666667. Leaving aside which one is right or wrong, basically the preview doesn't match the end result.

[schwa]

Thanks for the specific examples! It's actually the media explorer that is wrong in your second example, but regardless we should be able to fix this inconsistency.

[talustalus]

Same problem here - tempo match preview works in Media Explorer. But after inserting the item into the project, the rate change does not carry over. The item reverts to its original tempo and the tempo match in media explorer is completely ignored.

See attach1: how media explorer previews the item with Tempo Match on (with rate change)

Attach2: after inserting into project, these rate changes are completely ignored!