This is how it works at 44.1kHz
This is how it “works” at 88.2kHz
I’ve got nothing to add. There are no repro steps because it just “works” this way.
And such a behavior I have on two different systems, I mean hardware.
Anyone else?
System, Hardware, and Software Details.
Full Recipe.
Videos of steps.
Project link.
Note 1: I’m not sure how many of these steps contribute to the bug, however all are included to ensure nothing is missed.
Note 2: The basic video capture in win10 doesn’t show the menu drop-downs or mouse cursor
System Details:
Windows 10 Pro
Fully patched and up to date as of 29/06/2018
Intel i7 980 @ 3.33Ghz, 24G RAM, SD Drives
64 Bit
RME Fireface UFX
Driver 04.05.18 v1.114 Hardware Rev: 357
Cubase Pro V9.5.30 Build 192 (64bit) May 7 2018
Test Scenario:
Single B58 Microphone (pointed at the studio monitors)
Cubase metronome set to “sticks”
Single Mono Audio Track, recording the B58 at 96k 32 bit
Record the metronome via the microphone to the audio track (in track linear mode) project tempo default: 120
Change the project global tempo to 155
Select the audio event, Project/Tempo Detection
Demonstrate the bug
Project Details:
File / New / Empty Project / New folder “Cubase Bug”
Project Settings: 96K 32 Bit
Added single Mono Input Bus “12 B58” on RME channel 12
Track is Time Linear
Output bus: default stereo (RME 1&2)
Ruler Mode: Bars/Beats, Time Linear
Tempo: manual, 120 bpm
Tempo Track: Disabled
Snap Enabled: Grid + Events + Cursor
Add Mono Audio Track
Moved Transport to bar 5
Activated Metronome
Enabled track record
Recorded the metronome for a while
(video 1)
Selected event
Selected lower editor
Selected hitpoints
Adjusted threshold, checking for correct detection
(Video 2)
Transport on Bar 5
Select event
Manually change global project tempo to 155
(Cursor still at start of event, but now sitting between bar 6 and 6.2 due tempo change)
Turn snap off
Project / Tempo Detection
BUG: Try to warp grid (snaps back ans breaks)
BUG: A few more attempts and more breaks
BUG: And never recovers
BUG: After resetting detection, it looks good - add a few points, re-analyze, ok, move points (bang!)
(Video 3 - Above)
Project Dropbox link: Dropbox - Cubase Bug - Simplify your life
Steinberg: This is getting very frustrating. This is not a community supported, open source product. It is commercial software. You now have several users reporting this bug (and according to your stipulated bug reporting procedure) and the response is utterly underwhelming. I first reported this bug in December last year.
Where should I send my invoice for the preparation of the above recipe and videos?
Seems like Steinberg doesn’t have time to fix Cubase bugs. Or perhaps this feature is deadly unimportant. Or nobody uses 88.2kHz files or nobody else has this bug.
But anyway everybody is busy as hell.
exactly the same here, except it doesn’t work at 48khz either
Reaching the same result, same process (48kHz / 64 bit here), same erratic results, any resolution or fix in sight?
Close the Tempo Detection Panel before editing using the warp tool. Then it works as expected at any sample rate.
It seems more likely to me that if there’s a bug here, it is allowing the user make any adjustments while the Tempo Detection is still in process. (while the panel is still open) because once those gross adjustments available in the panel are made, there’s nothing else for it to do. It should be closed, and then the warp grid tool should be applied where you need it.
Why close the pannel?? it should work WITH the pannel opend, thats whay theres a “Direction of reanalysis” anyone can edit tempo without reanalysis, but thats not the idea…
Ahah! 
Thanks galoz, for giving the info I needed (again) to understand this. As embarrassing as it is, I hadn’t understood, and even missed it in your first repro. My apologies to you. I think I was able to generate a crash dump too, (Cubase crashed after trying the repro,) which I sent along. Thank you for the brevity of your steps, and for not assaulting me! 
If you have a crash dump, or can generate one by running the repro, could you zip and upload it?
I was able to get this reported: CAN-16587.
Here’s what I asked the rep to report:
Attempting Tempo Detection at sample rates other than 44.1k appears to be broken.
Repro:
Set project and audio files to 48khz (or any value more than 44.1k)
do tempo detection
leave tempo detection panel active and reanalysis arrows where they are.
with the warp tool, move the grid.
Unexpected result follows, and Cubase becomes unstable.
Thank you -steve- for getting this reported.
Please excuse us as a community for getting frustrated with this. We have all been genuinely trying to explain this issue for about 8 months, and we’ve tried all forms of long, short, videos and crankiness. Bugs (no doubt related) exist in this functionality even when a crash dump is not generated.
Thank you Steve!!
I’ll try to generate a crash dump, but I think that my cubase doesn’t crush, it just gets erratic. But today at the studio I’ll check that!
Thanks again Steve for your time!
Is it possible this is also a problem with Process Tempo?
I run 48k projects, and could not get this simple thing to work and give a correct tempo.
EDIT: I found this out - that Process Tempo is broken completely and posted separate thread on this.
Are there any updates on the issue?
I can still reproduce this with the latest 9.5. release (9.5.50). And it looks like the bug exists in Cubase 10, too (see Tempo Detection via Tempo Detection Panel crashes Cubase 10.15 reliably - #3 by adc - Cubase - Steinberg Forums).
On my system with C9.5.50 I can’t reproduce this. No crash at 48k.
Have you tried to “fiddle” a bit with the “warp markers” after you did the analysis? For me, with 9.5.50, this works fine for 44.1kHz. On 48 kHz sampling rate, the markers tend to jump and overlay each other as soon as you try to move them. And after a few attempts, Cubase freezes.
I use a 4.20 minute long audio track - perhaps it is a matter of the size of the track, too?
There are other odd things to observe:
- Analysis is way faster on 44.1 kHz as it is on 48 kHz (I guess around factor 3 or 4)
- On 48 kHz, it seems to be less accurate (I get some positions in the song with wrong detection that raises the need to use the warp markers)
- The “smooth tempo” button is always deactivated for unknown reason
I followed the repro I spelled out above: Start Cubase in Cubase Safe Start mode to rule out corrupt pref problems. (You can also save a preset of your prefs)
This thread is about the one specific bug, and nothing else. Please, just start another thread for anything else.
Repro:
Set project and audio files to 48khz (or any value more than 44.1k)
do tempo detection
leave tempo detection panel active and reanalysis arrows where they are.
with the warp tool, move the grid.
Unexpected result follows, and Cubase becomes unstable.
I followed exactly the steps you describe in your last post, and I can still reproduce it.
The warp grid “markers” jump unexpectetly, and after a few moves, Cubase freezes.
Since you’re getting that result and I’m not, maybe verify the version you’re running? and rule out corrupt prefs by using Cubase Safe Start Mode… The audio file I used was about 5 minutes long.
Hi.
I used Safe Start Mode in the last tests already (disabled my preferences, middle Button in the dialogue that pops up on holding CTRL+ALT+SHIFT on startup).
In the “About Cubase” popup, it says it is Version 9.5.50 Build 345 - Built on Feb 2 2019.
I’m working with one track of MIDI and I get this bug. As others have said, when you change to 44.1k it works. (Checked in Cubase 10.0.15 and the latest version of 9.5)
The history shows two events each time I attempt to move a marker: ‘Warp Tempo’ and ‘Iterative Beat Correction’. It seems like the second stage is bugged as the bar/beat line shows at the intended position when you undo.