Feature: Rename additional files (cover art, lyrics) to match audio file name

[mshelbz]

Summary

• This is a…
  • Bug fix
  • Feature addition
  • Refactoring
  • Minor / simple change (like a typo)
  • Other
• Describe this change in 1-2 sentences: When "Move additional files" is enabled, additional files (cover art, lyrics, etc.) are now renamed to match the parent audio file's new name while preserving their original extensions.

Problem

• JIRA ticket (optional): PICARD-XXX

When using the "Move additional files" option, additional files (such as cover art images, lyrics files, etc.) are moved to the same directory as the audio file but retain their original filenames. This can lead to inconsistent naming in music libraries where the audio file is properly named according to the user's naming script, but associated files keep their original names (e.g., cover.jpg, lyrics.lrc, etc.).

Solution

Modified the _move_additional_files() and _get_additional_files_moves() methods in picard/file.py to rename additional files to match the parent audio file's new name while preserving their original file extensions.

Changes:

• _move_additional_files(): Extracts the base name from the renamed audio file and passes it to the move function
• _get_additional_files_moves(): Now generates new filenames using the parent audio file's base name with the original file's extension
• _get_unique_additional_filename(): New helper method to handle filename conflicts by adding counters (e.g., song (1).jpg)

Example behavior:

• Before: old_song.mp3 + cover.jpg → new_song.mp3 + cover.jpg
• After: old_song.mp3 + cover.jpg → new_song.mp3 + new_song.jpg

Features:

• Preserves original file extensions (including case)
• Handles multiple files with the same extension using counters
• Maintains existing pattern matching behavior for hidden files
• All existing tests updated and passing

AI Usage

In accordance with the AI use policy portion of the MetaBrainz Contribution Guidelines, the level of AI/LLM use in the development of this Pull Request is:

• No AI/LLM use
• Minimal use (e.g. autocompletion)
• Moderate use (e.g. suggestions regarding code fragments)
• Significant use (e.g. code structure, tests development, etc.)
• Primarily AI developed
• Other (please specify below)

AI was used to explore the codebase structure, identify relevant files and methods for the file moving functionality, and assist with implementing the renaming logic and updating test cases.

Action

Additional actions required:

• Update Picard documentation (please include a reference to this PR)
• Other (please specify below)

The documentation for the "Move additional files" option should be updated to reflect that additional files are now renamed to match the audio file name.

[phw]

Thank you for the contribution. But the feature, as presented here, is not something we will merge. It is definitely not the intention to rename all additional files to the file basename. Also additional file moving happens on each file save, but often times such files (e.g. booklets or artwork) are generally for the release. In this case the result would depend on which file gets saved first.

There are several cases where there are files that should be renamed together with the audio file. There are several well known cases, such as lyrics or metadata "sidecar" files. One specific example, where Picard has actually hard-coded support for, are WavPack correction files (an additional ".wvc" file). And of course probably some user specific use cases.

What I'd like to see as a feature in Picard is generalized support for such files. Ideally with some options to add your own. My idea would be that one can define certain file extensions that would be checked. If there are existing files, that already have the basename of a file (probably allowing some variation, such as appended numbering) and match the extension, then they would be renamed together with this file.

If you would like to work on such a feature that would be welcomed. But this PR as it is right now can't be accepted, I'm sorry.

[phw]

Please don't update the NEWS file directly. Especially not by adding the feature to already released versions.

Instead please create a ticket for the feature or look for an existing ticket. We use the tickets to generate the changelog.

[phw]

There is an existing utility function get_available_filename to gnerate such names. It should be checked whether this could be used instead.