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

Analyze shouldn't show tracks that are already analyzed #6521

Open
mixxxbot opened this issue Aug 22, 2022 · 8 comments
Open

Analyze shouldn't show tracks that are already analyzed #6521

mixxxbot opened this issue Aug 22, 2022 · 8 comments

Comments

@mixxxbot
Copy link
Collaborator

Reported by: kain88-de
Date: 2012-06-10T20:57:47Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1011312


Analyze now shows also tracks that are already analyzed we should filter it to only show songs that are not analyzed

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2012-06-11T05:36:58Z


Additional thoughts:

  • What is the "New" button for?
  • Do we need an option to reanalyze?

@mixxxbot
Copy link
Collaborator Author

Commented by: esbrandt
Date: 2012-06-11T06:04:23Z


Just as the tooltip states the "New" radio button lists tracks added to the library within the last 7 day. The usefulness of the button is questionable.

Listing only tracks that have not already been analyzed sound reasonable as well as having an easy way to re-analyze tracks. The Analyze view is the natural place for that.

We have already a "Clear BPM and beatgrid" option in the tracks mouse menu but users would currently have to sort the library for tracks with 0 BPM to have a clue which tracks need to be (re)analyzed eventually..

@mixxxbot
Copy link
Collaborator Author

Commented by: kain88-de
Date: 2012-06-11T10:56:16Z


How about we change the two radio buttons in two checkboxes , 're-analyze' and 'not analyzed'.

Would it be useful to offer a re-analyze option for tracks that have already been analyzed by the current mixxx-version?

@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2012-06-20T17:24:58Z


One issue we will have to tackle with this bug is that we don't currently
have a good way of knowing that a track is analyzed (we could store the
tracks analysis status in the DB). Another issue is that if we mark a track
analyzed then in the future we might change the default analyzers (or the
user might change their analysis preferences) in which case we would want
to re-analyze even though we have analyzed it previously.

On Mon, Jun 11, 2012 at 6:56 AM, Max Linke wrote:

How about we change the two radio buttons in two checkboxes , 're-
analyze' and 'not analyzed'.

Would it be useful to offer a re-analyze option for tracks that have
already been analyzed by the current mixxx-version?

--
You received this bug notification because you are a member of Mixxx
Development Team, which is subscribed to Mixxx.
https://bugs.launchpad.net/bugs/1011312

Title:
Analyze shouldn't show tracks that are already analyzed

To manage notifications about this bug go to:
https://bugs.launchpad.net/mixxx/+bug/1011312/+subscriptions

@mixxxbot
Copy link
Collaborator Author

Commented by: kain88-de
Date: 2012-07-03T13:44:31Z


Instead of storing a boolean to know if a track is analyzed we could save a 32bit flag to also store which analyzer version was used. In case the analyse options are changed this flag in the library could be set to 0.

This way we would keep track of all tracks that currently need to be analyzed

@mixxxbot
Copy link
Collaborator Author

Commented by: rryan
Date: 2012-07-03T14:30:47Z


The main problem with this is that you don't know if the analyzer has been
run with the user's current preference settings on a given track. For
example, AnalyserBeats records a beats_version and beats_sub_version in the
library table and when checking whether to analyze a track (among other
preference options) it checks if the preferred beats_version or
beats_sub_version have changed. If they've changed then it may re-analyze
the track even though it has already been analyzed by the analyzer. So you
can't just represent whether the beat analyze should run on a track in a
bitvector.

On Tue, Jul 3, 2012 at 9:44 AM, Max Linke wrote:

Instead of storing a boolean to know if a track is analyzed we could
save a 32bit flag to also store which analyzer version was used. In case
the analyse options are changed this flag in the library could be set to
0.

This way we would keep track of all tracks that currently need to be
analyzed

--
You received this bug notification because you are a member of Mixxx
Development Team, which is subscribed to Mixxx.
https://bugs.launchpad.net/bugs/1011312

Title:
Analyze shouldn't show tracks that are already analyzed

To manage notifications about this bug go to:
https://bugs.launchpad.net/mixxx/+bug/1011312/+subscriptions

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2012-07-03T14:37:05Z


I have thought about something similar, but use the flags for single information like that:

#define REPLAY_GAIN_ANALYSIS_V1 0x00000001
#define WAVEFORM_ANALYSIS_V1 0x00000002
#define BEATGRID_ANALYSIS_V1 0x00000004
#define BEATGRID_ANALYSIS_V2 0x00000008
#define KEY_ANALYSIS_V1 0x00000010

@mixxxbot
Copy link
Collaborator Author

Commented by: daschuer
Date: 2012-07-03T14:56:32Z


Addition to post #⁠7 (Have not read RJs post until now)

If a new Mixxx version comes with a new or optimized analyzer task, It should use a new flag from the bit field.

If the user changes the preferences in for example beat detection, the BEATGRID_ANALYSIS_V2 bit is reset in all tracks after a warning.
With this solution will be possible to run only the specific analysis task which is really needed.

I am not sure if this covers all corner cases, but for me it is better than the current solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant