library: add subtitle (id3 TIT3) field

[daniele-athome]

Description

Adds support for a subtitle field, corresponding to the TIT3 id3 tag. Requires beetbox/mediafile#82

I don't think tests are required for this - I can't really see a comprehensive test suite for all available fields - but I might be wrong.

I'll add the changelog entry after your review.

To Do

• Documentation. (If you've added a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
• Changelog. (Add an entry to docs/changelog.rst to the bottom of one of the lists near the top of the document.)
• Tests. (Very much encouraged but not strictly required.)

[github-actions]

Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry.

[github-actions]

Thank you for the PR! The changelog has not been updated, so here is a friendly reminder to check if you need to add an entry.

[Copilot]

Copilot reviewed 1 out of 2 changed files in this pull request and generated no comments.

Files not reviewed (1)

• docs/reference/pathformat.rst: Language not supported

[michaelkrieger]

The musicbrainz plugin should also be updated to pull the field and populate it as well.

Did this addition stall? Seems increasingly commonly used with Picard and now Navidrome’s metadata enhancements.

[daniele-athome]

Did this addition stall?

I don't know... there are frequent commits on the main branch but some PRs are ignored. There must surely be a reason but the core devs would have to share that. Or they simply forgot about this :-)

[snejus]

Added a comment. I reckon this change should be included in the changelog too

[daniele-athome]

I added a changelog entry.

[snejus]

Aw snap just realised this depends on an unmerged PR in mediafile repo :/

[semohr]

I just merged beetbox/mediafile#82 🙃. You up to rebase and revive this?

[daniele-athome]

Rebased!! 🚀

[semohr]

Awesome! Let me see if I'm able to create a new mediafile version and how to do that 😨

[semohr]

I don't think I'm able to do a version bump for mediafile. I raised the issue in our internal chat tho. We will have to wait some more, sorry 🙈

[daniele-athome]

Hi there! Any luck in releasing a new version of mediafile? We are like a meter from the finish line! 😄

I'm ready to rebase this whenever needed.

[semohr]

We should be able to do that in the near future 🎉 We sill need to create a (maintainable) release workflow but other than that we should be able to create a release.

[snejus]

@daniele-athome new mediafile version 0.14.0 has been released, try updating with

$ uv tool run 'poetry<2' update mediafile

[daniele-athome]

On it!

[daniele-athome]

It took some time - sorry, life got in the way - but I'm finally there. Rebased on latest master and mediafile upgraded.

[snejus]

I actually wanted to ask about the following:

• Add support for importing and writing

It doesn't seem like this PR adds support for importing this field? Currently, this field is ignored - it can only be populated manually using beet modify ... subtitle=....

What is your use case for it?

[daniele-athome]

It doesn't work when importing metadata from an external source (e.g. MusicBrainz), but it worked for importing the field from source files (e.g. an existing TIT3 field in an mp3 file).

My specific use case was to edit the field after import (I wanted to remove it).

[snejus]

Have you considered removing this field from your music files before importing them?

For mp3 files you could use id3v2 --remove-frame TIT3 <files> and for flacs you may use metaflac --remove-tag SUBTITLE

[daniele-athome]

I did consider it, but since I use beets for anything related to my music collection, I thought it would be nice to implement it directly in beets and contribute it.

I know this is not 100% complete (because there is no way to actually import the field from sources, e.g. MusicBrainz), but it can pave the way for the next person to implement that (or I might even implement it myself if I find the time).

[snejus]

I share that concern. Adding a field to the core database just to remove it feels wrong architecturally.

The scrub plugin is designed exactly for this—stripping unwanted metadata before writing. But it has a limitation: it removes all unknown tags, with no way to selectively target specific ones.

Your actual need is granular control: remove TIT3 without touching other tags. Neither scrub nor zero supports that today.[4][5]

Rather than adding subtitle to the schema, consider extending scrub with a blacklist option to remove specific frames by name. Something like:[3]

scrub:
  auto: yes
  remove_frames: [TIT3, COMM, USLT]

This solves the problem cleanly for anyone managing legacy metadata, not just subtitle fields. It's also better than shelling out to id3v2 or metaflac externally.

What do you think?

[daniele-athome]

Rather than adding subtitle to the schema, consider extending scrub with a blacklist option to remove specific frames by name.

It's a nice idea and I might do that as well, another time.

I share that concern. Adding a field to the core database just to remove it feels wrong architecturally.

After your explanation about scrub, I totally agree. Does that mean that you are considering not adding support for the field in beets afterall? Despite its intended use by me, the new field can be used for importing (given someone - or myself - implement it in the MusicBrainz plugin for example).

[daniele-athome]

(I was about to rebase again but at this point I think I'll wait for an answer before doing it)