Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix gain issue with cloned tracks #12435

Merged
merged 3 commits into from Feb 4, 2024
Merged

Fix gain issue with cloned tracks #12435

merged 3 commits into from Feb 4, 2024

Conversation

daschuer
Copy link
Member

This PR fixes #10550 Via a couple of single fixes regarding using the right data at the right time.

This finally allows to play two cloned tracks with changing tempo without that the leader applies future or outdated tempo changes to the follower.

@JoergAtGithub
Copy link
Member

Does this also fix #11788 ?

@daschuer
Copy link
Member Author

No, @ywwg has a fix in #12431

EXPECT_DOUBLE_EQ(87.5,
ControlObject::getControl(ConfigKey(m_sGroup1, "bpm"))->get());

EXPECT_NEAR(
m_pChannel1->getEngineBuffer()->m_pSyncControl->getBeatDistance(),
m_pChannel2->getEngineBuffer()->m_pSyncControl->getBeatDistance(),
kMaxFloatingPointErrorHighPrecision);

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by removing these ProcessBuffers the two checks at the bottom are identical -- does it fail if play advances?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah Ok, I did not realize that this was a test. I will revert it.

@daschuer
Copy link
Member Author

Done.

@ronso0
Copy link
Member

ronso0 commented Dec 20, 2023

I confirm this fixes #10550

But it seems there is a difference in how clones are aligned (without Sync) in 2.4 compared to 2.3.6, there seems to be some tiny offset / flanger.
This zip contains some Flac files for comparison: -solo, -clone_2.3.6 and -clone_2.4-beta
zeitgeist-clone.tar.gz
edit The source is just some old, probably badly encoded mp3, I'll try reproduce with some suitable Flac source soonish.

@daschuer
Copy link
Member Author

Let's focus on #10550 which aims to fix all flanger effects, independent of sync and quantize.

There is no need for a recording. If you are able to create a flanger, please describe the steps and you may also share the file. Than I can hunt down the issue.

@ronso0
Copy link
Member

ronso0 commented Dec 20, 2023

Well, with two recordings you can compare the result of 2.3.6 and 2.4 much easier than running two Mixxx versions yourself.
Anyhow, Sync & quantize are off, play a track on deck1, clone it to deck2.

Yes, this needs to go to a separate issue.

@daschuer
Copy link
Member Author

There was a similar ssue, that is fixed in #10550 does that fix the issue for you?

@ronso0
Copy link
Member

ronso0 commented Dec 20, 2023

We're in the PR that fixes #10550 ;)

I noticed the effect with this PR, then I tested with 2.4 (identical) and with 2.3 from the ppa (issue not present).

@daschuer
Copy link
Member Author

Ah ok. Is it a fixed bpm track?

@ronso0
Copy link
Member

ronso0 commented Dec 20, 2023

Nope, variable BPM. Approx. 105-145
I'll write that report and send you the file via email.

@daschuer
Copy link
Member Author

I have discovered and fixed a ramping issue with ReplayGain that is now fixed.

I can reproduce the Flanger issue with Soundtouch + Keylock enabled. My guess is that the fresh initialized filters behave different compared to the established filters of the playing deck. Rubberband does not show the issue. Not sure if we can fix it from the Mixxx code. This is out of scope of this PR.

@ronso0 can you confirm this?

@daschuer
Copy link
Member Author

This should also fix the flipping test HotcueControlTest.CueGotoAndPlay on Launchpad, because the result original depends on thread timing.

@daschuer
Copy link
Member Author

daschuer commented Jan 4, 2024

@ronso0 can we merge this now?

@ronso0
Copy link
Member

ronso0 commented Jan 4, 2024

I don't understand the EnginePregain changes, sorry.
Diving into that will take time.

What about moving those commits to another PR?
Then we can merge the Sync fix right away.

@daschuer daschuer changed the title Fix pitch issue with dynamic tracks and sync Fix pitch and gain issue with dynamic tracks and sync Jan 5, 2024
@daschuer
Copy link
Member Author

daschuer commented Jan 5, 2024

You can find the first part of this PR here: #12515

@ronso0
Copy link
Member

ronso0 commented Jan 5, 2024

Okay, #12515 targets main, so please remove the pregain commits here.

@daschuer
Copy link
Member Author

daschuer commented Jan 5, 2024

#12515 is now for 2.4 with removed gain commits.
This one can be merged in a second step.

@daschuer
Copy link
Member Author

@ronso0 Will you find time to repeat you original tests with this branch soon? If not, let's remove this form the 2.4 milestone, since the gain issue is not a 2.4 regression. The sync part also contains in #12515 is the 2.4 part.

@ywwg
Copy link
Member

ywwg commented Jan 23, 2024

@daschuer now that #12515 is merged, can you update this PR? it's still showing all the diffs instead of the ones unique to this branch

@daschuer
Copy link
Member Author

Done.


if (m_bSmoothFade) {
float seconds = static_cast<float>(m_timer.elapsed().toDoubleSeconds());
if (seconds < kFadeSeconds) {
// Fade smoothly
if (seconds < kFadeSeconds && m_dSpeed != 0.0 && m_dOldSpeed != 0.0) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this mean that once the replaygain is calculated, mixxx will now change the gain while the track is playing back?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These condition applies the replay gain instantly without fading if the track is or was stopped. If it plays, fading is done.
The logic that a analyzer replay gain is not applied when playing is handled here:

// Do not change replay gain when track is playing because

0.00420177,0.00420177
0.00288188,0.00288188
0.00147617,0.00147617
0,0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are these all zeros now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems to be wrong. I will have a look.

0.00245179,0.00245179
0.00116233,0.00116233
0,0
0,0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are these all zeroes now?

@@ -527,7 +527,6 @@ void BaseTrackPlayerImpl::slotTrackLoaded(TrackPointer pNewTrack,
m_pDuration->set(0);
m_pFileBPM->set(0);
m_pKey->set(0);
setReplayGain(0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why was this the wrong place to put the replaygain setting?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it was too late, the first engine call uses the replay gain of the previous loaded track.

@daschuer daschuer changed the title Fix pitch and gain issue with dynamic tracks and sync Fix gain issue with cloned tracks Jan 25, 2024
@daschuer
Copy link
Member Author

@ywwg thank you for your good review. The test changes where wrong.
I have added a fixup commit. If this works for you I will rebase it.

@daschuer daschuer marked this pull request as draft January 26, 2024 07:32
@daschuer daschuer marked this pull request as ready for review January 26, 2024 07:44
@daschuer
Copy link
Member Author

@Swiftb0y @ronso0 I think this new fixup! checker suites good to prevent merging preliminary PRs.
What do you think?

@@ -1,6 +1,6 @@
-0.000926289,-0.000926289
-0.00185258,-0.00185258
-0.00277897,-0.00277897
-0.00277896,-0.00277896
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will revert this rounding artefact during fixup

@daschuer daschuer force-pushed the gh10550 branch 2 times, most recently from 988ddbd to c57c3ec Compare January 26, 2024 17:27
@Swiftb0y
Copy link
Member

@Swiftb0y @ronso0 I think this new fixup! checker suites good to prevent merging preliminary PRs.

Yup, I agree. Is there already PR for that I missed?

@daschuer
Copy link
Member Author

No, I will create one.

Copy link
Member

@ywwg ywwg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thank you!

@daschuer
Copy link
Member Author

daschuer commented Feb 4, 2024

All green after debase and an approval from @ywwg. So it is ready to go.

@daschuer daschuer merged commit b11437a into mixxxdj:2.4 Feb 4, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants