Request: Export Playlist to Traktor Pro Format

[Thangalin]

I have three copies of music: CDs, a desktop version for entertaining, and a portable version for DJ'ing.

For DJ'ing, I run Traktor Pro. For entertaining at home, I run Exaile. Of the two, Exaile excels at creating playlists. Yet Traktor Pro uses its own quasi-proprietary XML-like file format, and it cannot import M3U files.

It is orders of magnitude faster to create playlists in Exaile than Traktor. Therein lies the problem: there is no way to convert (export) the Exaile playlists to Traktor playlists.

Until now.

To run the attached file:

./m3u2nml.sh blues-playlist.m3u Blues

Where the first parameter is the playlist filename and the second parameter is the name of the playlist as it will appear after being imported into Traktor.

It would be great to see this as an export option for Exaile. It would have to be tweaked a bit and probably converted to Python.

Lastly, the code operates under the assumption that the directory structure between the two music collections is the exact same. In my case, it is.

If you have any questions, or would like help creating an exporter, let me know.

[reacocard (reacocard)]

Should be easy enough, do you have links to a spec (informal is fine) or some example files? Anything along those lines would be helpful.

[Thangalin (thangalin-deactivatedaccount)]

Find attached a playlist in M3U format that was converted to NML format using the previously attached m3u2nml.sh shell script.

[reacocard (reacocard)]

I note that file paths in the tracktor format lose the /home/username prefix, why is that? Does traktor just run relative to ~ always, or is this an adjustment to account for path changes in your particular setup?

[Thangalin (thangalin-deactivatedaccount)]

Traktor is Windows-based, but my Exaile installation is on Linux.

The /home/username has no direct equivalent on Windows. Note the following lines in the shell script:

    echo "<LOCATION DIR=\"$DIR\" FILE=\"$FILE\" VOLUME=\"$DRIVE\"></LOCATION>"
    echo "<ENTRY><PRIMARYKEY TYPE=\"TRACK\" KEY=\"$DRIVE$DIR$FILE\"></PRIMARYKEY>"

Traktor uses a fully qualified path. The source copy path (on Linux) is:

  /home/username/music/flac/...

The portable (destination) copy (on Windows) is:

  F:\flac\...

For this to be platform independent, the user should be prompted to provide the location of the source copy and location of the destination copy. The reason the drive letter is extracted is because of the first "echo" statement above: the Traktor file format has VOLUME= as an attribute. A sub-optimal decision, for sure, but it is what it is.

Hope that helps.

[reacocard (reacocard)]

I see, so for this to be any use we need to support relative paths in playlist export. I've added bug #783232 to track that feature (surprised there wasn't already a bug for that, tbh).

[Thangalin (thangalin-deactivatedaccount)]

I, personally, don't need relative paths. Both paths are absolute:

Source: /home/username/music/flac
Destination: f:\flac\

The shell script simply replaces "/home/username/music/flac/" with "F:\flac\" (or "F:" and "\flac\" when the VOLUME attribute is required).

For Traktor exports four inputs are required:

  Source Directory (e.g., /home/username/music/flac/)
  Destination Drive (e.g., F:)
  Destination Directory (e.g., \flac\)
  Playlist Name (e.g., Blues)

Architecturally, it would be great if there was a reusable system in place to simplify the creation of playlist format exporters.

[reacocard (reacocard)]

Playlist format exporters ARE a framework, adding new ones is trivial. Supporting new input into formats to do things like relative paths requires changing the framework itself and the parts of the GUI that tie into the framework so is rather less trivial.

Back on topic, Traktor doesn't support relative paths? It doesn't make sense to export using absolute paths with a different root than is on the system because then the program creating the playlist would never be able to open it again. This is why relative-path playlists exist - to handle the cases where you may wish to use one structure with multiple different roots.

[Thangalin (thangalin-deactivatedaccount)]

Good to know there's a framework, Aren. I understand about the GUI being less trivial, and I completely agree that relative paths are ideal.

I do not know whether Traktor supports relative paths because I have not tested or tried to figure out. What I did was build a playlist in Traktor, then export it in its NML format. I then wrote a script to take M3U files and convert them to the NML format used by Traktor. Once I successfully imported a converted rather large playlist, I submitted this feature request.

I have not looked to see if Traktor has a setting to change the paths to relative; I doubt it does.

As far as "the program creating the playlist" not being able to open it again, that's a non-issue. If I change the location of the music files on the destination drive, I would simply re-export the playlists from Exaile into Traktor format again, giving a different root directory. Unless I have misunderstood?

Traktor does support multiple roots, but all of my music is organized in a single location on my two machines, so I have never used the feature. My guess is that it still uses the fully qualified path for all the roots listed.

[reacocard (reacocard)]

> As far as "the program creating the playlist" not being able
> to open it again, that's a non-issue.
It's a non-issue for *your* case. For most cases it IS an issue, and when considering changes to core we have to consider how it affects every use case, not just individual users. The vast majority of users will expect that if they export a playlist into any format, they'll be able to re-open the same list again using the program that created it.

> I would simply re-export the playlists from Exaile into Traktor
> format again, giving a different root directory.
You have misunderstood, I mean being able to reopen the playlist with Exaile. Obviously reexporting them is a nonissue, but importing them to Exaile is impossible without adding (yet another) prompt to the import/export process to handle only this single case which almost noone except you will ever encounter.

Basically, if Traktor doesn't have a means to support relative paths, the necessary changes to support it in Exaile would be too great for the resulting benefit.