[WIP] Add support for importing/exporting the SeratoMarkers2 tag

[Holzhaus]

This aims to implement reading/writing the SeratoMarkers2 tag that Serato DJ Pro uses to store Track Color, Hotcues, Saved Loops, Flips and BPM-Lock state. Support for parsing/dumping the tag was added in #2323.

NOTE: This is a very early state, but I guess it's better to release code early to get some feedback. Also I don't know when I'll find enough time to finish this, so at least the current progress doesn't get lost. (@bungrudi Let me know if you want to take over here!)

TO DO:

• Find best location to call syncFromTrackObject
• Check precision of conversion between position in samples (mixxx) and position in milliseconds (Serato)
• ...
• Extensive Testing

[daschuer]

I have general concerns to write a reverse engineered proprietary format. I am not saying we shouldn't do that, but we should be clear to the user what we do, because we "mess" with the users data.
In worst case, issues in our code may crash other applications.

I think also that we have the power to establish a standard version for this. We should get in contact with the http://id3.org and https://hydrogenaud.io/ and check if there is already something in progress or if there are stake holders for this topic. It could be fun to work with Traktor and Serato developers on this topic.

What do you think?

[daschuer]

I suggest to keep changes to the import code in a separate PR. This will help to get a clear view on the new export code.

[Holzhaus]

I have general concerns to write a reverse engineered proprietary format. I am not saying we shouldn't do that, but we should be clear to the user what we do, because we "mess" with the users data.

Yes. I'd say we should definitely provide an option for this and put a warning message next to it.

In worst case, issues in our code may crash other applications.

If their parser code is really brittle and badly programmed, then yes.

I think also that we have the power to establish a standard version for this. We should get in contact with the http://id3.org and https://hydrogenaud.io/ and check if there is already something in progress or if there are stake holders for this topic. It could be fun to work with Traktor and Serato developers on this topic.

On one hand I like the idea, but I think there are some problems with creating a new format:

• It will be Mixxx-only. I strongly doubt that commercial DJ apps like Traktor or Serato would add support for it, and even if they do (and use that instead of their proprietary solution) - All older versions of their tools won't support it and most DJ libraries won't be compatible either.
• I think it could be quite difficult to find a format that fits all the different feature sets that each DJ application supports.

That said, I'm all for reaching out to the different companies and institutions and see if it works out.

Additionally, I'll reach out to the Serato guys and see if they are willing to provide some documentation on their format. That would be in their interest: If some Mixxx user would like to switch to Serato, the migration would be much easier if Mixxx could write these tags properly. However, I doubt they'd give out documentation.

I suggest to keep changes to the import code in a separate PR. This will help to get a clear view on the new export code.

Both the import and the export code is new. The serialize/unserialize code for the SeratoMarkers2 GEOB tag isn't, but the glue code that converts the SeratoMarkers2CueEntry objects into track cues in Mixxx. If you want I can put the code that writes the Mixxx cues to the SeratoMarkers2 object into another branch.

What's missing in this branch is some checking if the file modification time is newer than the last change to the track cues in Mixxx. If so, we should probably overwrite the cues stored in the Mixxx DB. We could also provide an option to only import Serato cues if there are no cues in the Mixxx DB for the track in question. What do you think?

[daschuer]

On one hand I like the idea, but I think there are some problems with creating a new format:

It will be Mixxx-only. I strongly doubt that commercial DJ apps like Traktor or Serato would add support for it, and even if they do (and use that instead of their proprietary solution) - All older versions of their tools won't support it and most DJ libraries won't be compatible either.

Im not sure, I think it's a matter of the use-cases around it. Compared to other Standard processes, this will likely take 10 years until it is widely used, but if we don't try, we will have it never.

I think it could be quite difficult to find a format that fits all the different feature sets that each DJ application supports.

Yes, we need something extensiable.

That said, I'm all for reaching out to the different companies and institutions and see if it works out.

Yes, do you have interest to do it?
We may do a poll first if we have already contacts.

Additionally, I'll reach out to the Serato guys and see if they are willing to provide some documentation on their format. That would be in their interest: If some Mixxx user would like to switch to Serato, the migration would be much easier if Mixxx could write these tags properly. However, I doubt they'd give out documentation.

And, be careful not to agree some non disclosures, because this prevents reverse engineering.

Sometimes a industrial standard is created by publishing a propritary solution. In this scenario Serato will benefit the most.

Separate import ..

It is all just about keeping small PRs merge-able.

What's missing in this branch is some checking if the file modification time is newer than the last change to the track cues in Mixxx. If so, we should probably overwrite the cues stored in the Mixxx DB.

We could also provide an option to only import Serato cues if there are no cues in the Mixxx DB for the track in question. What do you think?

Yes. There is also the cue offset issue ...

[Be-ing]

I doubt they'd give out documentation.

I doubt they have documentation.

[Holzhaus]

I doubt they'd give out documentation.

I doubt they have documentation.

It's woth a try anyway. Does somebody have contacts over there? If not, I'll submit a request over at: https://support.serato.com/hc/en-us/requests/new

[Holzhaus]

Closing this in favor of #2499.