Skip to content

Add support for calculating ReplayGain on unidentified clusters #392

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

Merged
merged 1 commit into from
Jun 12, 2025

Conversation

emersonrp
Copy link
Contributor

This commit allows unidentified clusters in the "left pane" to be run through the plugin and have their ReplayGain calculated. Previously the plugin could only be used on identified tracks and albums in the "right pane."

With this commit, one or more clusters can be scanned as albums, and the album and track ReplayGain added to the files. There is no change to the existing / previous functionality for identified albums and tracks.

This commit allows unidentified clusters in the "left pane" to be run
through the plugin and have their ReplayGain calculated.  Previously the
plugin could only be used on identified tracks and albums in the "right
pane."

With this commit, one or more clusters can be scanned as albums, and the
album and track ReplayGain added to the files.  There is no change to
the existing / previous functionality for identified albums and tracks.
@emersonrp
Copy link
Contributor Author

I see that Codacy is saying that the "calculate_replaygain" method is too complex. I think it's not appreciably more complex than it used to be, though it of course is a bit longer. I can refactor this to get around the Codacy issue, but that expands the scope of the change, and has more possible impact on the existing functionality. Happy to do the right thing, be it refactoring or just living with the Codacy issue, as y'all see fit. Thanks.

@emersonrp
Copy link
Contributor Author

Also I have just noticed that this is actually an open issue, #344

@phw
Copy link
Member

phw commented Jun 12, 2025

Thanks a lot, this is very helpful.

I see that Codacy is saying that the "calculate_replaygain" method is too complex. I think it's not appreciably more complex than it used to be, though it of course is a bit longer. I can refactor this to get around the Codacy issue, but that expands the scope of the change, and has more possible impact on the existing functionality.

Yes, I think the codacy check is a bit too strict here. It calculates complexity by considering the different possible code paths in some way. And because your change introduces several "if" conditions it now got above the threshold.

We could address this by splitting the function calculate_replaygain further up into separate functions, e.g. extracting building the file list or applying the metadata to files, but I don't think it does help much for the code readability in this case.

I think we can raise the codacy complexity limit or ignore the complaint for this case.

Otherwise the code looks fine to me. I'll test run this and then I think we can merge this change.

Also I have just noticed that this is actually an open issue, #344

Yes, exactly, this is the fix for this issue. As mentioned it was initially left out intentionally, but has been requested frequently since then. Great you provided this fix.

Copy link
Member

@phw phw left a comment

Choose a reason for hiding this comment

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

Everything working as expected. Thanks again for this contribution

@phw phw merged commit acb303a into metabrainz:2.0 Jun 12, 2025
5 of 6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants