Add support for stem edit or update

[acolombier]

Add the ability for Mixxx to create/edit stem info. This will enable the creation of a new stem file.

Screencast.From.2026-01-21.02-32-08.mp4

DAO+proto for stem info is still todo.

Depends taglib/taglib#1299 and #16095
Closes #13710

[ronso0]

Nice!
The Track Info can be opened by double-clicking deck labels. Would be cool if double-clicking stem labels does that, too, and focuses the Stem tab.

[acolombier]

Thanks for your feedback! Added the behaviour, as well as the DAO, proto and MP4 tags persistence.

Screencast.From.2026-01-21.19-46-58.mp4

Just testing is remaining.

[acolombier]

@JoergAtGithub any idea why the embedded taglib solution fails on Windows ARM?

[JoergAtGithub]

Does it link if you embedd the unmodified taglib?
Does it link if you only use the CMakelist.txt from this PR on main?

[acolombier]

It works well on Windows 2022 x64 with the current version. I haven't had a chance to test further usecase on Windows machine and was wondering if this type error looked familiar and could maybe benefit from a quick fix

[acolombier]

Tried to get Windows ARM to use shared lining instead, but this seems to be a dead end.
Going park this and add a patch on VCPKG's taglib instead, so we can reserve this solution for Linux and lagging distros.
We need to see what we do for Debian tho, and potentially ship a tarball with the custom taglib version.

[JoergAtGithub]

Note that we use still taglib 1.x on Windows, as there was a port overlay until mixxxdj/vcpkg#198 that overwrote the upstream version.

[acolombier]

Taglib 2.2 was announced with STEM support!

[JoergAtGithub]

Taglib 2.2beta got tagged. The usual beta period of taglib is 1 month, the changelog lists the 18th of Feb as release date.

[acolombier]

This now depends on VCPKG update: mixxxdj/vcpkg#209

[acolombier]

This PR should now be ready to merge.

One outstanding question is how to deal with the the required 2.2.0 TagLib version on Ubuntu. From @daschuer's comment on the SignalSmith Stretch PR, I understand we are not supposed to to download external libraries, does this mean we should not include this PR on Ubuntu? I could introduce a separate __STEM_EDIT__ macros and disable that feature on Ubuntu, tho this means that feature stem generation won't be available in there, which feels like a big miss. What can we do there?

[JoergAtGithub]

Please move the commits with the VCPKG update to a separate PR! Updating dependencies and implementing a feature are two separate items that should be reviewed and tested independently.

[JoergAtGithub]

Regarding the Ubuntu topic, the requirements are mostly defined in our Minimum Requirements Policy:

The main branch must build with the packages in the latest Ubuntu LTS...

New features can be committed to the main branch which depend on packages not yet available in that Ubuntu version, but the main branch must build without the new feature

Means that a __STEM_EDIT__ macro that is set depending on the TAGLIB-Version is fully compliant with our guidelines. This would allow users of newer Linux distributions to use the feature before we update to a new Ubuntu LTS version.

Leaving the policy aside, I agree that code with too many such macros is ugly and difficult to maintain.

[acolombier]

Please move the commits with the VCPKG update to a separate PR! Updating dependencies and implementing a feature are two separate items that should be reviewed and tested independently.

Not sure to understand why. I need the VCPKG update to confirm this features works, and updating VCPKG on its own could lead to it not working (as proven by the current state, which suggest I will need to release a new VCPKG build).

Could you explain what value does this extra effort brings?

Leaving the policy aside, I agree that code with too many such macros is ugly and difficult to maintain.

It also a massive blowback for Mixxx. As the reference for DJing on Linux and Ubuntu (and derivative) being the most popular distro, it feels like leaving users behind when it comes to stem generation (which this feature is a requirement for) is potentially bad press.

I guess we could keep the "TagLib from Git" ON on release builds, and disable it (+macros) for PPA builds so we can still distribute Mixxx via Debian/Ubuntu PPA, and user who want to use advanced stem feature can install the .deb manually, with the statically linked TagLib.
Can you think of a better solution @daschuer ?

[acolombier]

Just realised that Fedora is also blocked on TagLib 1.13 ...