Unable to import song at correct tempo if wrong tempo detected

[SteveDaulton]

Bug description

I have a music track with a tempo of 200 BPM. When I try to import it, the tempo is incorrectly detected as 100 BPM. It seems to be impossible to import the track at the correct tempo.

Steps to reproduce

1. Generate a click track using "Rhythm Track", all default settings except for "Tempo" which should be set at 200 BPM. This is to simulate my music track. Export the project as "click.wav"
2. Close and restart Audacity.
3. Set the tempo and time signature to 200 BPM, 4/4
4. Import "click.wav".
5. When prompted "Audacity detected this file to be 100 bpm. Would you like to enable music view and set the project tempo to 100?" , click "NO" (we already have the tempo set correctly and we do not want Audacity to change it).

Expected behavior

The file will be imported into the project without changing the tempo or time signature.

Actual behavior

The file is imported at double speed.

Audacity Version

current master / alpha / nightly build

Operating system

Linux, macOS, Windows

[SteveDaulton]

Even worse - if I change the Preference setting "Import / Export > Music Imports" to "Do Nothing", the track is imported at double speed without any indication that Audacity has changed the tempo.

[DavidBailes]

The behaviour for automatic tempo detection can be found in the pull request: https://github.com/audacity/audacity/pull/5570

In the steps to reproduce, in step 5, instead of clicking No, if you click Yes, and then press Ctrl+Z to undo, this will result in the desired outcome.

Note that if you're importing into a non-empty project, with the timeline view set to beats and measures, and the automatic tempo detection is incorrect, then the speed adjustment of the clip will be incorrect.

If the timeline view is set to beat and measures, then there is no way of turning automatic tempo detection off, despite what is stated in the current documentation for automatic tempo detection: https://support.audacityteam.org/additional-resources/changelog/audacity-3.5#automatic-tempo-detection

[dozzzzer]

FWIW I believe this is the exact same issue as #6285

[DavidBailes]

FWIW I believe this is the exact same issue as #6285

That issue was that automatic tempo detection was failing in an apparently simple case. I think that the current issue is about the user experience when automatic detection fails (which is will, at least occasionally).

[SteveDaulton]

FWIW I believe this is the exact same issue as #6285

No, it's a different issue. #6285 is about the accuracy of tempo detection. This issue is about the problem caused when tempo detection gets it wrong (as it inevitably will on occasion).

In the steps to reproduce, in step 5, instead of clicking No, if you click Yes, and then press Ctrl+Z to undo, this will result in the desired outcome.

Thanks David. A useful, though counterintuitive workaround for some cases.

[saintmatthieu]

@DavidBailes if you answer "No" or have settings saying "never", the auto-stretch happens only in Beats and Measures view. (Confusing probably is that if you're already in B&M view, the dialog will still says "enable music view and ...") It's important to realize that the automation is only about reconfiguring the view and tempo of the project, not about auto-stretching. The auto-stretching choice would need a separate question, which at the moment is not asked explicitly and decided upon the view instead.

[DavidBailes]

It's important to realize that the automation is only about reconfiguring the view and tempo of the project

I assume that by that you mean that the preference is only about reconfiguring the view and the temp of the project? The automatic tempo detection is used either for changing a clip's tempo or the project's tempo, depending on context and sometimes on user input. If the timeline view is already set to beats and measures, and the tempo is autodetected, then the preference (plus possible user input) determines whether the tempo of the clip or the project is changed. As Steve has already pointed out, the "do nothing" option doesn't do nothing. Your specification of the behaviour in your PR does define what is expected to happen. However, the current user documentation does not.

[SteveDaulton]

I think that users will typically expect import behavior to be consistent regardless of the display mode of the timeline.

[saintmatthieu]

If the timeline view is already set to beats and measures, and the tempo is autodetected, then the preference (plus possible user input) determines whether the tempo of the clip or the project is changed. As Steve has already pointed out, the "do nothing" option doesn't do nothing.

I have a different experience. My timeline is B&M, I import the previously exported 200bpm rhythm track, and this gets the clip stretched. Consistently with the preference, nothing happened with respect to project view or tempo.

Your specification of the behaviour in your PR does define what is expected to happen. However, the current user documentation does not.

That's another problem, isn't it?

[DavidBailes]

If the timeline view is already set to beats and measures, and the tempo is autodetected, then the preference (plus possible user input) determines whether the tempo of the clip or the project is changed. As Steve has already pointed out, the "do nothing" option doesn't do nothing.

I have a different experience. My timeline is B&M, I import the previously exported 200bpm rhythm track, and this gets the clip stretched. Consistently with the preference, nothing happened with respect to project view or tempo.

The preference is "When audacity detects music in file imported on empty project: option: do nothing - I read this to mean do nothing. (The option is not: do nothing to the timeline view or the project tempo, but change the clip's tempo if the timeline view is beats and measures.)

I guess our takes on this are different.

Your specification of the behaviour in your PR does define what is expected to happen. However, the current user documentation does not.

That's another problem, isn't it?

It probably is.

[SteveDaulton]

The auto-stretching choice would need a separate question, which at the moment is ... decided upon the view

Schrödinger would be proud.