Skip to content
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

Optionally reset metadata on reimport if file tags are missing #4873

Merged
merged 8 commits into from
Jul 31, 2022
Merged

Optionally reset metadata on reimport if file tags are missing #4873

merged 8 commits into from
Jul 31, 2022

Conversation

uklotzde
Copy link
Contributor

Context:
https://mixxx.discourse.group/t/cannot-update-blank-tag-in-mixxx/25348
quodlibet/quodlibet#4065

The behavior is configurable, but the preference dialog has not been extended yet (I am not planning to do this). The default behavior is as before, i.e. missing fields in file tags are silently ignored and their metadata is preserved.

The only actual behavioral change affects the track properties dialog where missing fields in file tags are now reset unconditionally, independent of the new preference setting. The comment in the code explains why this behavior is suitable.

Context:
https://mixxx.discourse.group/t/cannot-update-blank-tag-in-mixxx/25348
quodlibet/quodlibet#4065

The behavior is configurable, but the preference dialog has not been
extended yet. The default behavior is as before, i.e. missing fields
in file tags are silently ignored and their metadata is preserved.

The only actual behavioral change affects the track properties dialog
where missing fields in file tags are reset unconditionally, independent
of the preference setting. The comment in the code explains why this
behavior suitable.
Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

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

Thanks. I have a couple questions.

@@ -146,6 +156,9 @@ void importTrackMetadataFromTag(TrackMetadata* pTrackMetadata, const TagLib::APE
&discTotal);
pTrackMetadata->refTrackInfo().setDiscNumber(discNumber);
pTrackMetadata->refTrackInfo().setDiscTotal(discTotal);
} else if (resetMissingTagMetadata) {
pTrackMetadata->refTrackInfo().setDiscNumber(QString{});
pTrackMetadata->refTrackInfo().setDiscTotal(QString{});
}
#endif // __EXTRA_METADATA__

Copy link
Member

Choose a reason for hiding this comment

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

Just curious, below we also parse bpm, trackgain, etc. Why are we not resetting those?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Would have been extra work and for those the tags don't matter. You could reset them in Mixxx. Slightly inconsistent but acceptable.

Copy link
Member

Choose a reason for hiding this comment

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

Sure. Would you mind adding a that sentence as a comment above the imports you didn't touch?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

A comment was already in place at the entry point. I have extended it: 5d1f73b

Copy link
Member

Choose a reason for hiding this comment

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

Sorry I seem to have read past that. Thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unfortunately, the code is a little bit scattered and the entry point is not obvious.

The boolean could be transformed into an enum for type safety, but the boolean was easier to handle while extending the implementation. That was a deliberate decision.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have decided to add the missing reset of both bpm and replay gain: c848725

src/track/taglib/trackmetadata_ape.cpp Show resolved Hide resolved
src/track/track_decl.h Outdated Show resolved Hide resolved
Copy link
Member

@Swiftb0y Swiftb0y left a comment

Choose a reason for hiding this comment

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

LGTM. anyone else willing to take a look?

@daschuer
Copy link
Member

I will have a look.

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

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

I have not yet understand why we treat reading from the file differently if it is called from the track properties dialog or from the context menu. Sure, the users have control via "Apply", but how will they find out that the context menu behaves differently? I would prefer that both behave the same for a reliable and predictable behavior.

I think we have originally not reset the not existing tags, because we where not able to write the data back. But now we can reconsider this.

There is a an issue with BPM, When I read from metadata, the BPM value is rest, but when I press apply it reappears. This should not happen.

Maybe we should treat the mandatory metadata that is Mixxx using itself differently.
I have BPM/Key and ReplayGain in mind.
I think we import these value only if Mixxx does not have them and we never reimport them again.
The same should also apply to a not existing value in the file tags.

There is clearly a use case for empty textual tags in a third party tool and pull that in as described in the forum, but there is IMHO no use case in clearing BPM, Kay and ReplayGain, read from file tags and than expect that Mixxx is analyzing this again.

@@ -162,10 +162,12 @@ void BrowseThread::populateModel() {
thisPath.token());
{
mixxx::TrackMetadata trackMetadata;
constexpr auto resetMissingTagMetadata = false; // no effect
Copy link
Member

Choose a reason for hiding this comment

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

I do not understand the comment. Can we remove that, or make it more verbose?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comments are needed: a607187

src/library/dlgtrackinfo.cpp Outdated Show resolved Hide resolved
bool isPeakValid = parseReplayGainPeak(&replayGain, strPeak);
if (isPeakValid) {
pTrackMetadata->refAlbumInfo().setReplayGain(replayGain);
ReplayGain* pReplayGain = pTrackMetadata->refAlbumInfo().ptrReplayGain();
Copy link
Member

Choose a reason for hiding this comment

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

This can be renamed to pAlbumReplayGain and the one above to pTrackReplayGain.

Did you consider to move the code into parseReplayGainPeak, to deduplicate it a bit?
The function is only used here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@uklotzde
Copy link
Contributor Author

There is clearly a use case for empty textual tags in a third party tool and pull that in as described in the forum, but there is IMHO no use case in clearing BPM, Kay and ReplayGain, read from file tags and than expect that Mixxx is analyzing this again.

These are all still regular tags. Introducing some special case handling for some of them will only cause confusion. The behavior should be predictable.

@uklotzde
Copy link
Contributor Author

uklotzde commented Jul 31, 2022

I think we have originally not reset the not existing tags, because we where not able to write the data back. But now we can reconsider this.

This PR allows to switch between 2 different modes of operation, i.e. lazy (traditional) or strict. I will not extend the scope.

@uklotzde
Copy link
Contributor Author

There is a an issue with BPM, When I read from metadata, the BPM value is rest, but when I press apply it reappears. This should not happen.

This is probably an unrelated issue with the dialog and should be resolved separately.

@github-actions github-actions bot added the ui label Jul 31, 2022
@uklotzde
Copy link
Contributor Author

I have not yet understand why we treat reading from the file differently if it is called from the track properties dialog or from the context menu. Sure, the users have control via "Apply", but how will they find out that the context menu behaves differently? I would prefer that both behave the same for a reliable and predictable behavior.

Restored the original behavior: de88868

Copy link
Member

@daschuer daschuer left a comment

Choose a reason for hiding this comment

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

Thank you. LGTM.

I think the underlying idea of removing non existing metadata is correct. However ther is an existing Bug with the BPM value that demonstrates the issue with the scalar BPM tag. This also applies to Key and partially to ReplayGain. I think after this is solved we have a clear view how to deal with this new preferences option.

@daschuer daschuer merged commit 2fe0fc5 into mixxxdj:main Jul 31, 2022
@uklotzde uklotzde deleted the reset-missing-tag-metadata branch July 31, 2022 20:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants