-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Native method of exporting cue points and such (all the data in the sql database) from one installation and import it into another mixxx installation #10939
Comments
Separate issue, and also already fixed by #4802 by enabling the "Reset Loops" action in the track menu. |
Is the request about updating / syncing your own track set's metadata (tracks, metadata, crates ect.) across Mixxx installations? Or do you want to import your track set into an existing database? Like plugging in an external drive (tracks + db) to play your tracks on a friends laptop? |
The first one, syncing metadata and such including cue points, loops, bpm etc. I mix on two devices so would be super helpful if I can export the metadata from one installation and import it to another to take on the go with me to sets. Thank you for the speedy reply!! |
If the two systems Otherwise it'll be more difficult... |
They're both windows and they're both the same version but copying over an installation every time you want to sync your metadata isn't an appropriate solution, if the username is different on the device being copied to it won't work as the directory will be different hence you need to run sql commands. Mixxx needs a native method of importing and exporting library metadata or just storing it in the actual music file like other mixing software, either works |
Why not just (optionally?) store cue points, analysis, waveform etc in the music files? |
Yeah I think this would be the best solution, there are already standards for storing that kind of info in metadata so it just needs to be implemented. |
What standards are you referring too? Unfortunately the "standard" employed by serato is neither documented, well designed (see reverse engineering documentation at https://homepage.ruhr-uni-bochum.de/Jan.Holthuis/) nor particularly fit for mixxx. |
I doubt that this is true. Please provide references. |
I was referring to Serato's implementation but I didn't realise they haven't documented it 😵💫 perhaps creating an open and properly documented standard would be worthwhile. |
Possibly, but creating a good standard is quite a lot of work. Also, xkcd standards applies since this is quite a common problem, I doubt anyone except us would actually adopt it. |
Moving to more file orientated library canonical data store could help cut the apparent gordian knot of not easily being able to have multiple libraries with all tracks #10147 or a subset of all tracks on a different machine/device #6253 or as a different format #9434 #11520 or filename #9881 or quality #10791 etc #10773 ("Corollary: Don't rely on the database. Try to encode and store as much information as possible in file tags.") (also #6384 argh biggest pain with a large library!). (Even though I'd have a track in multiple crates, I'm also thinking a file-directory orientated first approach to playing is a more sustainable and easier to manage affair, like #11026, with extra portable crate playlist/groupings as a side (but more easily transferrable/relatable-to-the-tracks-whereever-they-be thing).) |
If you want a searchable library that's reasonably fast, there is no way around having a proper database that you can run queries on, especially once the library gets to a decent size. Just storing all data in the file tags is not likely an option when you need to do search across many files. You will always need a centralized index (database) and thus you'll always need to do deal with synchronizing the different data sources. That said, when exchanging files between different sources, saving track-specific metadata within the file itself probably makes most sense, though as you said that still doesn't address non-track metadata (playlists, tags, etc). |
I didn't say there shouldn't also be a db for speed, but hoarding info only in a db rather than having the canonical information in the file seems to be the problem. |
Sure, I agree, but writing metadata back into the file and then synchronizing these two data sources has its own set of problems, not to mention the fact there isn't really a standard for the more DJ-oriented metadata anyways. |
When the option to write Serato metadata is enabled, what forms of metadata are not currently written to the file in the form Serato uses? |
My understanding now is that everything Serato uses is written, but Serato does not use Intro Start + End and Outro Start + End markers, so it's not possible to rely on the Serato metadata mechanism in Mixxx to easily transfer tracks between Mixxx instances. Meh. (I was hoping to set Mixxx metadata in my local NAS music colletion, then just copy the files to USB where there's a different config+db and import there, but no.) |
Reflecting on all of this I think using a database is the best option for speed etc, but just adding a button to export/import the sql database in a way that is usable on another installation without further modification would be really helpful. In an ideal world there would be an open standard for storing this kind of metadata in the files but that's not feasible from the sounds of it. |
I'm kind of tearing my hair out about it, checking the third-party scripts, trying to figure out if this is possible. I've got friends who run clubnights and I want to have a stick with tracks to pop into a CDJ-3000, but it would be great if a) these tracks could be used with another instance of Mixxx with the home Mixxx metadata, n b) any new/updated metadata can be brought back into the home instance (b being many many steps down the road). Some have said that creating a new metadata tag standard/schema/form (or the route of a portable DB file that takes into account that the tracks that have been exported to a USB stick have a new and relative path) would just be like XKCD # 927, but someone has to start if there's not an open standard for it already. This is Mixxx, by far the most widely used open source DJing software. Why shouldn't it innovate? It's like there is both an argument that "there's no existing method that other software uses", or it's "oh, it'll just be a yet another format" but with the "we can't just use the existing format" (e.g. Rekordbox if we're talking industry standard) problem. Sticking music files on a USB and popping round a mates and using their controller/computer is such a common activity amongst younger DJs.. and some of my other friends use Mixxx for sure. |
Feature Description
I'd love to see a feature where you can export all the cue points and loops (everything in the sql database) from one mixxx installation and import it into another. Would make mixing on the go much easier as currently if I go from my desktop to my laptop I have to run sql commands to format it so I can use it on the laptop.
Also would love to see an option to delete loops that you've created fully so they don't show up anymore as it can be extremely annoying visually not being able to delete them if you accidentally create them
Thank you 😊
The text was updated successfully, but these errors were encountered: