Increase speed of track analysis.

[DGMurdockIII]

it would be nice if analyzing of BPM did not take so long if you have a lot of files when doing it the first time or even just doing one song

[RJ Skerry-Ryan (rryan)]

Once beats are analyzed for a song then they are stored in the DB so we don't repeat the work.

I'll just leave this open as a long-term "increase the speed of the analyzer". We could do this via a couple of different strategies:

1) Reduce repeated work across our analyzers (e.g. if both QM and keyfinder do an FFT, maybe we can hack them up so that we compute the FFT in Mixxx and pass it to them so only one FFT is done).

2) Contribute to the analysis libraries to speed them up.

[RJ Skerry-Ryan (rryan)]

3) Allow the option of only analyzing a particular sub-chunk of the track and generalizing that to the rest of the track (for example for beats or key we could do this.. but not for waveform).

[rob (another-rob)]

How about adding an option to just analyze for BPM, and then only create the waveform summaries when the user loads the song for the first time (or an option to do waveform analysis at a later time.) Personally, when I'm scanning in a collection, the most important thing is the BPM - I can wait a second or three for a waveform summary when I load the track the first time.

(I'm assuming doing just BPM would speed up analysis, but I'm not familiar with the code so it's possible it wouldn't...)

This would also save disk space, since a lot of users probably have huge collections and don't ever play many of the songs, so they don't really need pre-saved waveform summaries for a boatload of songs they'll never play...)

[RJ Skerry-Ryan (rryan)]

The vast majority of analysis time is spent in audio decoding and BPM
detection. The waveform calculation is pretty lightweight because it uses
the same decoded audio that goes into BPM detection. It would make the
analysis run faster though, it's just not going to be a massive speed
improvement.

On Mon, Mar 18, 2013 at 5:22 PM, rob <email address hidden> wrote:

> How about adding an option to just analyze for BPM, and then only create
> the waveform summaries when the user loads the song for the first time
> (or an option to do waveform analysis at a later time.) Personally,
> when I'm scanning in a collection, the most important thing is the BPM -
> I can wait a second or three for a waveform summary when I load the
> track the first time.
>
> (I'm assuming doing just BPM would speed up analysis, but I'm not
> familiar with the code so it's possible it wouldn't...)
>
> This would also save disk space, since a lot of users probably have huge
> collections and don't ever play many of the songs, so they don't really
> need pre-saved waveform summaries for a boatload of songs they'll never
> play...)
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1101281
>
> Title:
> Increase speed of track analysis.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1101281/+subscriptions
>

[shalty (neogeo-dc)]

Some time ago, tinkering with the 1.11 code, i made a pool of analyzer threads, so that you could analyze more tracks in parallel.

This worked (and without much code), but it was a very ugly hack and it was interfering with the analyzer UI part (songs analyzed/total), and, most importantly, would take a hit on the performance if done while ... well... performing ;), easly eating the available cpus (yes, you can control the number of threads to leave-a-space, but...)

But for fast offline analyze of a bunch of songs before "performing", was great ;)

Just an idea.

[Uwe Klotz (uklotzde-deactivatedaccount)]

The issue should be fixed with the introduction of multi-threaded analysis in 2.3.

Please file a bug for tuning individual analyzers, if this is possible. We already have options that enable a faster but less accurate analysis, e.g. for BPM.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/6856