Add analyser support for stem

[acolombier]

Make analysers compatible with multi channel and use the best channel for specific features.

As per the NI spec, the first stem is always the drum or rhythmic channel.

This means that:

• Beat and BPM matching will always be using the first stem
• Key will use all other channels

All other analyser perform a stereo mix, except if multichannel is supported internally.

Finally, the waveform analyser will gather EQ samples for the mixed track and per-stem samples.

Depends on #13070

[JoergAtGithub]

I think there's no need to support the Serato format, because it's only used for Seratos internal caching. We don't know if they store additional metadata in their library.
Calculating the replay gain from the 4 stems mixed together makes sense to me. Unless we've a compressor/limiter stage, this seems to be the replay gain, that matters.

[daschuer]

Can you rebase that onto main?

[daschuer]

The first eatDetectionSettings::StemStrategy settimg alters the analyzer results and shall therefore also be part of the analyzer metadata so that we can later deal with existing analysis of alpha testers. To not put extra work on you for this intermediate solution, it would be also OK to disable or hide the feature to now.

How are existing analysis treated by the way? They have been probably done from the stereo downmix. Do we need to deal with it?

[acolombier]

The first eatDetectionSettings::StemStrategy settimg alters the analyzer results and shall therefore also be part of the analyzer metadata

Is that already supported for the others beats and key settings such as the algorithm used for either? If yes, happy to add this as part of that PR too as well.

[daschuer]

For beats, it is implemented here:

mixxx/src/analyzer/analyzerbeats.cpp

Line 181 in 5ced2de

if (version == newVersion && subVersion == newSubVersion) {

I am not sure if we have similar for keys.

[acolombier]

For beats, it is implemented here:

mixxx/src/analyzer/analyzerbeats.cpp

Line 181 in 5ced2de

if (version == newVersion && subVersion == newSubVersion) {

I am not sure if we have similar for keys.

AFAICS, this is only taken protobuf serialisation version into account, this doesn't invalidate analyses with different settings. Or am I missing something?

On a side note, I'm just wondering, do we want to invalidate older analyses upon analyser changes? I'm thinking it actually sounds wrong since you may want to change your settings temporarily (e.g with our use case, to analyse a non compliant stem) without invalidate other valid analyses. In case you wanted to redo the analyses you always get the option to do so in the context menu. Wdyt?

[daschuer]

We already have a preference option for this:

mixxx/src/preferences/dialog/dlgprefbeatsdlg.ui

Line 78 in d9d23dc

<string>Re-analyze beats when settings change or beat detection data is outdated</string>

But anyway, can we postpone all this and merge this with the unoptimized Analysis?

In case of beats we have the const and the non const detection and version numbers. We must not automatically reanalyze a track, because beat markers may shift away from the cue points, which may creates surprising effects when mixing.

I think we should optimize this workflow:

• Use reasonable defaults in the preferences
• Track settings in the analysis metadata to be able to destingush/filter tracks using a certain setting.
• Allow to reanalyze single tracks with a different setting to fix special issues with a couple of tracks.
• Allow to reanalyze all tracks in case of improved analyzers on demand.

I think we should not recommend to alter the preference options to fix single tracks.

[acolombier]

can we postpone all this and merge this with the unoptimized Analysis?

Yeah that's fine - I'll hide the option in the setting, so I can still use it via config file, if that's okay with you.

Use reasonable defaults in the preferences

Do you think that Disabled is not the best option here?

I think we should not recommend to alter the preference options to fix single tracks

Agreed - but this is currently how you would deal with tracks needing different options (e.g key plugin). It is suboptimal, but reworking the whole flow is an entire feature so I guess that workaround remain the only way, and thus we should still take it into account.

[daschuer]

Yeah that's fine - I'll hide the option in the setting, so I can still use it via config file, if that's okay with you.

Yes that's fine. The preferences pane needs anyway some love.

Do you think that Disabled is not the best option here?

For the vast majority of the tracks the optimized analysis will be the best option. Unfortunately we need to deal with the exceptions.
Without that in place let's keep it disabled as a safe default known good form stereo tracks.

It is suboptimal, but reworking the whole flow is an entire feature.

Yes. Since it should work without optimization, postponing is a good idea.

I see the following solution/iterations:

1. Add a stem mode to the analysis metadata to distinguish it later. (We need it anyway for further improvements of the analyzer)
2. Only optimize when a the first stem is reasonable labeled.
3. Add a context menu option to the analyze menu to reanalyze problematic tracks differently.
4. Allow to add custom Labels that enable optimizations

Does that work for you? (I don't want to put the work on you, just plan possible steps)

[daschuer]

Thank you. LGTM. Please give a hint when I can press merge

[daschuer]

@JoergAtGithub is there something open form your review?

[acolombier]

All good from my end @daschuer

[JoergAtGithub]

Yes all is fine now! Thank you very much!