Timing drift caused by BPM changes about dtxmanianx HOT 3 CLOSED

Thanks @Jumprocks1 for the feedback.

I forgot to highlight that the measurements collected are limited to what the existing Debug Info on the UI, which always has the sound length round off to 2 decimal point in seconds. Therefore, the actual drift may not be as high as shown in the table. I will probably update Debug Info to show a few more decimals and update the comparison table to make it more accurate.

As for the default value being set to the new compute mode, it is chosen as a way to encourage players & simfile authors to try out the fix as I believe it should be the way moving forward to improve authoring experience with external audio tools. Opting out of it is made easy as it is placed as the last configurable option in under System:

from dtxmanianx.

Thanks @Jumprocks1 for highlighting this issue.
After several more in-depth testing with a handful of real simfiles, I found that not only BPM chips but any change in barLength will also result in the same time drift issue. I have created a sample chart based on the one prepared by @Jumprocks1 , but with alternating 0.5 and 1.5 bar lengths, while putting the same number of snares:
bad2_withBarLengthChangesOnly.zip

The time drift adds up to 0.04 seconds or 40 ms, with only bar length changes every bar, which is around 1 ms per change. Although the drift is quite small in this example, it will certainly add up to significant amount for very long songs with 100 or more bar length/BPM changes.

The following table shows the Song Length shown in the Debug Info during gameplay for both Original and the Improved Compute methods (updated to 3 decimal places in seconds):

In practical terms, only Soflan-chan Long Version has audible desync near the last quarter of song when switched to using the Improved Compute Method. This is because its BPM and Bar Lengths were manually sync and adjusted using DTXCreator with audio cues from the DTXViewer (@approvedtx please correct me if I am wrong). For songs with well-known BPMs and Time-Signatures, the Improved Computed Method will resolve the de-sync issue and compatibility issue with external tools.

Solution

As mentioned by @Jumprocks1, fixing this issue will cause incompatibility with other DTXMania variants such AL since they all have the same issue and cause existing BPM/Time-signature varying charts timed using DTXViewer to not play accurately. As such, I have to decided to add a new config field in config.ini tentatively named ChipPlayTime Compute Mode, implement both Original and Improved methods of computing playbackTimeMs, and let players choose which mode to use in the Config Option menu.

The implementation can be found in the misc_issues branch. Feedbacks and comments are welcomed.

from dtxmanianx.

Thank you for looking at this @fisyher. I reviewed the changes for CDTX.cs in misc_issues and the implementation looks correct as far as I can tell.

The measurements in your table also look correct. I would however recommend including another decimal place when discussing these changes, as the the difference between 10ms and 1ms is pretty large for audio. As an example, the default judgement window for a perfect is 34ms, so a 10ms drift reduces this window by a noticeable 29%. A 40ms drift completely destroys the window. For most basic simfiles though, the drift is closer to 1ms.

One thing you did not mention in your comment is that the default is set to the new compute mode. I have no opinion on what the default should be, just mentioning that for anyone else who is curious.

from dtxmanianx.