Wishlist: Save analyzed BPM to id3 tag

Bug #1156868 reported by rob
28
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Mixxx
Low
Uwe Klotz

Bug Description

Since analysis takes so long, it would probably make sense to have the option to save the analyzed BPM to the id3 tag of the MP3 file itself, rather than just saving it in the Mixxx database - that would make it a lot less of a hassle to rescan a collection.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

This bug is blocked by Bug #728197

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
RJ Skerry-Ryan (rryan) wrote : Re: [Bug 1156868] Re: Wishlist: Save analyzed BPM to id3 tag

A problem with this is that Mixxx doesn't just detect a BPM, it detects the
actual beat locations. There's no universal standard for storing beat
locations in an ID3 tag so there's no way Mixxx will get around having to
re-analyze the file unless you use a specific set of assumptions (fixed
tempo assumption and assume offset is 0 to create a grid from the BPM).

On Mon, Mar 18, 2013 at 6:13 PM, Daniel Schürmann <
<email address hidden>> wrote:

> This bug is blocked by Bug #728197
>
> ** Changed in: mixxx
> Status: New => Confirmed
>
> ** Changed in: mixxx
> Importance: Undecided => Low
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1156868
>
> Title:
> Wishlist: Save analyzed BPM to id3 tag
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1156868/+subscriptions
>

Revision history for this message
rob (another-rob) wrote :

Didn't realize there isn't a standard... I wasn't thinking of replacing the BPM scan though - was just thinking that once you've spent all the time required to scan all your songs you may as well save the BPM data persistently somewhere.

I've got a big collection with a lot of songs I'll never play - for most songs, all I really need to know is what the BPM is - if it's close to what I'm working with, I might decide to use it, and I can wait a couple of seconds when a song first loads to do a full BPM scan. So once I've scanned my whole collection once, if the BPM data can be saved somewhere, then I've got all the info I really need about each song. I was thinking of this as sort of a stopgap measure in case someone has to rescan their collection at some point - during the time it takes to rescan the collection, at least you'll have the old BPM number saved somewhere...

Another side effect would be that you could then use the BPM data in other programs.

But, if there's no standard, then this is all probably moot.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Ah, gotcha. There is a standard for storing the BPM but not a beatgrid. We
plan to support writing the BPM to the ID3 tag but it's blocked on the
problems Daniel mentioned.

On Thu, Mar 21, 2013 at 10:39 PM, rob <email address hidden> wrote:

> Didn't realize there isn't a standard... I wasn't thinking of replacing
> the BPM scan though - was just thinking that once you've spent all the
> time required to scan all your songs you may as well save the BPM data
> persistently somewhere.
>
> I've got a big collection with a lot of songs I'll never play - for most
> songs, all I really need to know is what the BPM is - if it's close to
> what I'm working with, I might decide to use it, and I can wait a couple
> of seconds when a song first loads to do a full BPM scan. So once I've
> scanned my whole collection once, if the BPM data can be saved
> somewhere, then I've got all the info I really need about each song. I
> was thinking of this as sort of a stopgap measure in case someone has to
> rescan their collection at some point - during the time it takes to
> rescan the collection, at least you'll have the old BPM number saved
> somewhere...
>
> Another side effect would be that you could then use the BPM data in
> other programs.
>
> But, if there's no standard, then this is all probably moot.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1156868
>
> Title:
> Wishlist: Save analyzed BPM to id3 tag
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1156868/+subscriptions
>

Revision history for this message
cies (cies-breijs) wrote :

I think storing the BPM, even without storing the beatgrid, is very helpful. Today I spend a lot of time to get the BPMs right of my tunes: I'd love to save that work on the tags of my tracks, so i cannot loose it. (im considering to type it into the tracks since Mixx does not do it for me)

I understand the beatgrid issue; but is it not possible to use a "Mixx custom" property for the "offset" of the first beat?

Maybe such custom properties can also be used to save the 1-2-3-4 markers :)

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Relevant: http://xkcd.com/927/

We could look into storing properties with a custom prefix but then no
other app would interoperate with it.

On Sun, Oct 6, 2013 at 2:40 PM, cies <email address hidden> wrote:

> I think storing the BPM, even without storing the beatgrid, is very
> helpful. Today I spend a lot of time to get the BPMs right of my tunes:
> I'd love to save that work on the tags of my tracks, so i cannot loose
> it. (im considering to type it into the tracks since Mixx does not do it
> for me)
>
> I understand the beatgrid issue; but is it not possible to use a "Mixx
> custom" property for the "offset" of the first beat?
>
> Maybe such custom properties can also be used to save the 1-2-3-4
> markers :)
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1156868
>
> Title:
> Wishlist: Save analyzed BPM to id3 tag
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1156868/+subscriptions
>

Revision history for this message
Stéphane Guillou (stephane-guillou) wrote :

Hi all

Yes, this is something that would really help people mixing with large and/or diverse libraries.
I agree with cies that just storing the BPM is already helping a lot just to narrow down a collection in order to beat-match. The user can directly see what the BPM are, and even though they would have to wait again for the analysis to find where the beats actually are, at least the user does not have to lose time analysing dozens of track to find the one that could fit. I do not think the beat grid issue actually blocks the problem described here. Maybe fixing this would just lead to a different bug report about the beat grid not being saved as well.

I would extend on the proposition here with what I guess is a feature request that fits nicely in here: having the option in the preferences to either always save the analysed BPM or only saved them when "validated" by the user (with the little check-box).

Cheers

Revision history for this message
Uwe Klotz (uklotzde) wrote :

Relates to: https://bugs.launchpad.net/mixxx/+bug/728197

After any metadata of a track has been modified the tags in the file should optionally be updated when the track is finally "unloaded". A file manager or broker is needed that keeps track of which files are currently "loaded" (decks, analyzer, ...).

Revision history for this message
Uwe Klotz (uklotzde) wrote :

Is automatically fixed when writing back of metadata is re-enabled.

I've already enabled writing of metadata to files in my local builds and it works as expected. The BPM fields are now stored in conformance with the various tag type standards (with or without fractional digits) and are displayed correctly in external programs.

Changed in mixxx:
assignee: nobody → Uwe Klotz (uklotzde)
status: Confirmed → In Progress
Revision history for this message
Uwe Klotz (uklotzde) wrote :

Solution is part of this PR that re-enables tag writing:
https://github.com/mixxxdj/mixxx/pull/592

Revision history for this message
Uwe Klotz (uklotzde) wrote :
Uwe Klotz (uklotzde)
Changed in mixxx:
milestone: none → 2.1.0
Uwe Klotz (uklotzde)
Changed in mixxx:
status: In Progress → Fix Committed
Changed in mixxx:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers