add mass and advanced tagging capabilites

A crucial question in this topic is: What is the main task of Mixxx?

For my feeling Mixxx focuses clearly the live situations.

It will ever be a crutch in managing the music library compared to other music management solutions.

There are several other applications that are suitable for managing music libraries and they are doing a quiet good job.
Unfortunately not focused on the DJ needs.

Why not re-use one of them for Mixxx?

My idea of an ideal solution is an integrated DJing-MediaPlayer-MusicLibrary-Application.

For me it is important to manage my music collection in one central place.
I want to listen my music desktop player and organize it for the next gig.
Its out of the Mixxx focus, to be a media player.

I think it's one part of the open source idea to develop as a community for the best solution, instead of competit with different products doing the same.

I am just working on the integration of the Banshee database in Mixxx.
Currently as read only solution.
One idea might be that Mixxx works entirely with the banshee database.
All additional information from Mixxx should be stored with a reference to the song in Banschee.
We might provide a Banschee Plugin to manage these Mixxx information within Bnashee as well.

I've also had a brief look to Clementine player. He is compared to Banshee something in its infancy, but it looks veeeery promising.
.. and it's based on QT. This fact would allow us to merge it with Mixxx.
This would solve many Bugs we have currently on our wishlist, like display cover art, lyrics and last.fm infos.

http://www.clementine-player.org

What do you think? It it worth going such a way?

Bug #839501 issues the same.

Bug #678173 is the Banshee bug.

Thanks for your reply Daniel.

I think it's a good way to follow. For me Banshee still lacks some advanced features (like custom tags, in order to be able to create a key field for example or other custom one's). But I like the idea to delegate that work to another solid more general project, because these are features not only useful for DJs.

In my opinion the best implementation would be to rely completely on Banshee's database. This is: not to having two clone databases (one in each program), but using only banshee's one and let Mixxx read and modify it. But I would like to know your technical opinion about that.

I would like to happen the same with tags. I would like them to be synchronized bidirectionally between Mixxx and the audio file on my computer.

I will star using Banshee more seriously to test it's usability and report any bug and suggestions to it's project too.

I agree in general with not spending too much time adding advanced tagging
/ organization features to Mixxx since it's kind of out of scope of the
project.

The problem with delegating to an external project (e.g. just using
Banshee's database as the Mixxx library) is that Banshee is not cross
platform and there is no single external program that is cross platform and
very popular. I think we should aim to allow external libraries to be
treated natively in Mixxx but do it in a general way.

On Wed, Jan 4, 2012 at 2:08 PM, Ferran Pujol <email address hidden>wrote:

> Thanks for your reply Daniel.
>
> I think it's a good way to follow. For me Banshee still lacks some
> advanced features (like custom tags, in order to be able to create a key
> field for example or other custom one's). But I like the idea to
> delegate that work to another solid more general project, because these
> are features not only useful for DJs.
>
> In my opinion the best implementation would be to rely completely on
> Banshee's database. This is: not to having two clone databases (one in
> each program), but using only banshee's one and let Mixxx read and
> modify it. But I would like to know your technical opinion about that.
>
> I would like to happen the same with tags. I would like them to be
> synchronized bidirectionally between Mixxx and the audio file on my
> computer.
>
> I will star using Banshee more seriously to test it's usability and
> report any bug and suggestions to it's project too.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/911743
>
> Title:
> add mass and advanced tagging capabilites
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/911743/+subscriptions
>

I have no experience with Banshee on Windows or Mac OSX but at least they are offering alpha/beta-quality technology preview.
http://banshee.fm/download/

On Linux we could implement a client for the standard MPRIS D-Bus interface http://www.mpris.org. I am afraid it has a leak of performance when we try to use it natively because of its inter process communication.

Is their a similar standard on Windows or Mac OSX?

@RJ: Do you have already made further considerations on this "general way"? Which technology do you want to use?

I am afraid the general way is the most difficult approach.

So an alternative way will be, to select one multi-platform player that suits best and support it seamless. Some other common players could be supported read only as we already did.

What are the requirements for such a player?
* Extensible for the DJs and Mixxx needs
* Linux/Mac/Win Support
* Advanced tagging capabilities
* Based on Track Database
* commonly used

It would be the best, player is written in c/c++ so its easy for the Mixxx Team to re-use or patch its code. And it does not drew so much external dependencies.

@RJ: Did you look at clementine?

Pros:
* nice features (Lyrics/Cover Art/Last.fm Tags ... )
* Qt based
* sqlite databases
* multiplattform
* Young project

Cons:
* Mass tagging not as convenient as banshee
* no Crates
* not very popular until now

Here is a list of other possible Qt Apps:
http://qt-apps.org/index.php?xcontentmode=4220
Btw: The Mixxx infos are outdated in those list.

I like Daniel's approach.

From my point of view we have to choose the player according to the project flavor and not relying on it's accessory features. Take Clementine as an example: I think we should focus in the fact that's Qt based, because mass tagging and crates are not excessively painful to implement and we can always persuade the developers or develop it ourselves.

Banshee is still not 100% cross-platform but is on the way (Windows is in alpha and Mac in beta).
Clementine is cross-platform. (I've not tested neither one or another in other platform than Linux).
I wouldn't care about player popularity. If it meets our requirements people using Mixxx would mostly like it and it will gain popularity by own merits.

By the way I personally do not discard to implement such organization features into Mixxx project (not necessarily into the same application) in the future (I agree there are more crucial things to worry right now and I'm still not a programmer.

I haven't developed the external library idea much except to know that it would require some serious DB schema changes.

The problem with something like Banshee is .. as you've found from their mailing list:
1) The right way to talk with it is via DBus, which is Linux only and requires Banshee to be running.
2) The team discourages direct access to SQLite since they do schema changes often.

Since the vast majority of our users aren't very technical, we need to make it very easy. I'm afraid this means supporting a lot of different external libraries. We will never be able to forget iTunes, and of course integrating other DJ software libraries is a great way to ease people's transitions to Mixxx.

Picking Banshee or Clementine and saying to everyone else that they must use it isn't going to work well for making it easy to pick up Mixxx and start using it.

I'll try and pin down exactly what I'm thinking about for external library support and write out a rough description of it.

I like database approach because I understood maybe it's out of scope to
make Mixxx a full tag editor / music manager. But if relying in other
programs databases becomes a similar work load we might considear it again.

2012/1/7 RJ Ryan <email address hidden>

> I haven't developed the external library idea much except to know that
> it would require some serious DB schema changes.
>
> The problem with something like Banshee is .. as you've found from their
> mailing list:
> 1) The right way to talk with it is via DBus, which is Linux only and
> requires Banshee to be running.
> 2) The team discourages direct access to SQLite since they do schema
> changes often.
>
> Since the vast majority of our users aren't very technical, we need to
> make it very easy. I'm afraid this means supporting a lot of different
> external libraries. We will never be able to forget iTunes, and of
> course integrating other DJ software libraries is a great way to ease
> people's transitions to Mixxx.
>
> Picking Banshee or Clementine and saying to everyone else that they must
> use it isn't going to work well for making it easy to pick up Mixxx and
> start using it.
>
> I'll try and pin down exactly what I'm thinking about for external
> library support and write out a rough description of it.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/911743
>
> Title:
> add mass and advanced tagging capabilites
>
> Status in Mixxx:
> New
>
> Bug description:
> It would be nice to be able to use mixxx as a complete mixing/organizing
> music solution. To achieve that I think one of the firsts steps would be to
> add advanced tag capabilities and mass tagging:
> -User defined tags
> -Advanced mp3 tags
> -Mass tagging
> -Filename rename based on tags and viceversa.
> -Scripting
>
> To get an idea to implement mp3tag/puddletag like features in mixxx in
> order to use only one program.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/911743/+subscriptions
>

--
Atentament, Ferran Pujol Camins

>A crucial question in this topic is: What is the main task of Mixxx?
>For my feeling Mixxx focuses clearly the live situations.

Definitely agree here. Mixx should handle the least possible metadata about tracks - and the metadata it handles should be Mixx-specific (play counts, cue points, etc.). There is already a standard mechanism for handling track-specific metadata: id3 tags.

Of the 5 use-cases in the original post:
-User defined tags - what kind of tags? Anything track-specific can be handled by id3 tags (as comments, if nothing else).
-Advanced mp3 tags - can be handled by id3. Mixxx should be able to read useful non-standard tags, such as the musicbrainz tags that Picard inserts.
-Mass tagging - leave this to mass taggers (picard, kid3, etc).
-Filename rename based on tags and viceversa. - see below
-Scripting - I don't see how this is related to metadata. Is it?

The biggest problem related to leaving tagging to an external app is that if a track file is renamed, all of the Mixxx data is lost. The best way to deal with this would be to ID tracks based on a hash of the actual sound data, instead of the file name.

Picard already adds an "AcoustID" to mp3 files, so perhaps this could be used? (AcoustID doesn't appear to be added to all file formats, unfortunately, but "Musicbrainz recording ID" does seem to...).

If this isn't feasible, then simply storing the md5sum of the audio data in the track as the track ID in the Mixxx database shouldn't be too resource hungry.

> - Advanced mp3 tags - can be handled by id3. Mixxx should be able to read useful non-standard tags, such as the musicbrainz tags that Picard inserts.

Good point. Can you file this to a separate bug and give more details?

> The biggest problem related to leaving tagging to an external app is that if a track file is renamed, all of the Mixxx data is lost. The best way to deal with this would be to ID tracks based on a hash of the actual sound data, instead of the file name.

Thanks to Max, MIxxx has made great progress in finding renamed track.

See e.g.:
Bug #804700 Automatically identify songs using fingerprinting methods and lookup/clean metadata from online-sources (e.g. MusicBrainz)

It would be a great help, if you could test the latest master version from https://github.com/mixxxdj/mixxx/ against your use cases. Instructions: http://www.mixxx.org/wiki/doku.php/start#build_mixxx

> Picard already adds an "AcoustID" to mp3 files, so perhaps this could be
> used? (AcoustID doesn't appear to be added to all file formats,
> unfortunately, but "Musicbrainz recording ID" does seem to...).
I implemented chromaprint, the fingerprint library for acoustID, for
1.12. In Mixxx we can use it for all fileformats that we support. I also
thought about using it to uniquely identify tracks but for this to work
we would need to calculate this with the library scanner which will
slow it down significantly. A lot of our user already have huge
libraries and the scanner takes to long for them. (we need about 1s
reading the audio and 250 ms calculating the fingerprint, so for a small
5000 tracks library we would already need ~ 1h 45m)

> If this isn't feasible, then simply storing the md5sum of the audio data
> in the track as the track ID in the Mixxx database shouldn't be too
> resource hungry.
Calculating the fingerprint is not that much of a problem. Reading the
actual audio kills us. We also cannot read the whole file in binary and
just hash that because the ID3-tag is part of that and we don't want to
be affected by changes in them. Having to do this every time we rescan a
folder to check if nothing changed just takes way to long.

It is a nice idea and I would love to have it but we need to find a way
to deal with the I/O bottleneck

Hi Max, how does the Picard "AcoustID" compares to the ID you use?
If a user has already tagged all files with an "AcoustID" inside the ID3 Tags, we have no need to recalculate it.
If Mixxx adds this ID to its "find renamed files" algorithm, it could be helpful.

But of cause only for Picard users :-/

Musicbrainz is currently switching to using IDs provided by the AcoustID online service. These are NOT the fingerprints we calculate. The system is designed so that different fingerprints can be assigned to the same ID, this is important because you want to have the same ID for a track if it is compressed with 16bit or 512bit.

The only way right now to get the IDs from the service is to submit the fingerprint to the online service and wait for their answer. You'll actually get a sorted list of IDs and their probability.

Sending thousands of network request does not seem like a viable solution to me. You can also check how long this all takes using the 'look up track data at music brainz" feature.

"Daniel Schürmann" <email address hidden> wrote:
>Hi Max, how does the Picard "AcoustID" compares to the ID you use?
>If a user has already tagged all files with an "AcoustID" inside the
>ID3 Tags, we have no need to recalculate it.
>If Mixxx adds this ID to its "find renamed files" algorithm, it could
>be helpful.
>
>But of cause only for Picard users :-/
>
>--
>You received this bug notification because you are subscribed to Mixxx.
>Matching subscriptions: Mixxx-Bugs
>https://bugs.launchpad.net/bugs/911743
>
>Title:
> add mass and advanced tagging capabilites
>
>Status in Mixxx:
> New
>
>Bug description:
>It would be nice to be able to use mixxx as a complete
>mixing/organizing music solution. To achieve that I think one of the
>firsts steps would be to add advanced tag capabilities and mass
>tagging:
> -User defined tags
> -Advanced mp3 tags
> -Mass tagging
> -Filename rename based on tags and viceversa.
> -Scripting
>
> To get an idea to implement mp3tag/puddletag like features in mixxx in
> order to use only one program.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/mixxx/+bug/911743/+subscriptions

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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