XSPF Playlist import/export

Bug #1617466 reported by Antonio
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mixxx
Confirmed
Wishlist
Unassigned

Bug Description

Need to output a mix as a .cue or XSPF is this possible?
Reason for this described below
If you can help enroll to
<email address hidden>
------------------------------------

Hi folks. I am trying to attract attention to this idea below. Basically I' d like to set up a radio with, possibly, very few listeners.
Tried with Radionomy and was cancelled several times not to meet their minimum audience. Radionomy was unsatisfactory, also, for the limitation on their database.
Many songs I'd love were not there. So I would like to develop a consistent approach for this and I am not finding the appropriate resources. May be it is time to write something myself? Ideally Mixx should be used to produce a Radio program. Once one is satisfied with his program basically has a list of URL for the songs he has found on the net plus a number of vocal Dj intervention Mixx is keeping in his memory. This can be described as a .cue file.
If one is satisfied with streaming a sequence of song-comment-song etc. then it is quite straightforward to put your vocal intervention mp3 on some server, build a XSPF playlist, put a XSPF player on a web page and have a radio.
The listener runs the XSPF player embedded in the web page of the radio and downloads each song and each dj comment.

In a more advanced scenario XSPF capabilites are extended and the client is modified to mix two tracks so that we can have a DJ doing his intervention while music is playing. This is quite straightforward since, right now, there are XSPF players that crossfade two subsequent mp3.

Finally some middleware is needed. You can stream this way a program but a radio needs something more. Therefore you need a good bunch of PHP code dealing with
assembling XSPF playlist, one for each single program, into a XSPF for the whole day, upload it to your server. Handle monthly plannig and so on.

Finally we can imagine some plus.
First the communication with clients could be secured and therefore XSPF is passed to the client in encoded form.
Next either the PHP server and the client could receive several URL for the same song and try to adapt is some link went dead.
When this happens the PHP server could inform radio programmer that a certain shortage of options, for a certain song, comes up.

The whole scenario looks like an internet radio (for the user really look like this!) but basically is playlist playing leveraging the server from streaming workload.
DO YOU KONW IF SOMETHING LIKE THIS ALREADY EXIST? I DO NOT
Think there are a bunch of programmes on Github or SourcForge that tackled part of this scenario (XSPF players or PHP for Radio servers and MiXX delivering playlists)
so I think that is not that difficult to put together something
DOES SOMEONE WANT TO CONTRIBUTE? CAN YOU PASS THIS IF YOU KNOW SOMEONE WHO
-Is able to output a playlist out of Mixx
If you can help enroll to
<email address hidden>
-Is programming XSPF players for the web page
-Is buiding PHP servers for radio.
Cheers
Antonio

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Wishlist
Revision history for this message
Daniel Schürmann (daschuer) wrote :

The final goal looks somehow similar to this:
https://bugs.launchpad.net/mixxx/+bug/1338409

I would like to focus this bug on Playlist export.
Mixxx has a History "Playlist" that can be exported.
This can be feed a Web player to re-listen the set, in a Jukebox fashion without the original transitions.

A next step could be to save the cue-in and cue-out points and the fade time.
The advanced version will have to track speed and pitch info as well.
I am afraid XSPF is not able to do this right now and Mixxx is yet not able to collect the data.
This should be tracked and discussed in a separate bug or as an comment for the existing bug.

summary: - XSPF support
+ XSPF Playlist import/export
Revision history for this message
Antonio (antonio2016) wrote :

Yes, somehow XSPF must be extended in several directions. Afterall is X SPF.
History Playlist might be ok instead of XSPF but they should harbour URLs for songs rather than
references to local files. You need to have cue-in and cue-out points and the fade time, Right.
Would be that difficult to add this information to a History playlist? Not started to dig into the code yet so I can't figure out. Another problem is to understand how these URL could be found by Mixx.
Cheers
Antonio

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

We could add these infos to the History playlist.
I am only afraid that a extra column for each info will soon be an overkill.
The same is might be an issue for the XSPF file.

An other issue is that the History playlist has no dedicated start and end event. It starts and ends with Mixxx, which is not equal to the start and end events of your radio show.
So we should consider a different approach.

So how about using the standard XSPF file as a inter-operable format for all players and "record" all control events in a second stream based file. This could also be a binary blob inside the XSPF file.

Revision history for this message
Antonio (antonio2016) wrote :

Must be surely something like this. Simply have no idea what is the simplest to implement in Mixx.
Still trying to have this compiling in Eclipse under W10.
May be that once we are able to do this we can feed this to a player and see how is difficult to modify one of the two (i.e. Mixx or the player). Surely not necessary to stitch to pure XSPF output.

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

Compiling Mixxx on W10 is a pain. We have only a few contributors who have managed it.
If you like to get your feature done, do it on a Linux
machine. Building works also on a Virtual Box image, but there are performance issues when running Mixxx.

Revision history for this message
Tuukka Pasanen (pasanen-tuukka) wrote :

I investigated this little bit. In general form XSPF/JSPF doesn't do what we want. Although it has extension system what VLC uses to extended XPSF (https://wiki.videolan.org/XSPF/) which gives at least second start and stop but again it's not as accurate as we need.
MIDI could be the one but problem it is binary and mainly it's formed more or less '80. There is XML Midi (http://www.palserv.com/XMidi/ ) and musicXML (http://www.musicxml.com/for-developers/).
XSPF extended with musicXML could be one option because we want to map what has happened between starting to play song and stop when it have been mixed to another and again record what happened to that new song.
Binary MIDI would be best option but if one wants to read it or see whats inside it's pain.

One option is adopt: XML that are compatible with: MLT framework (https://www.mltframework.org/bin/view/MLT/MltXml) so one can tune mixes and then render it offline.

For people who just requires played songs we should use CSV file. Easiest to parse and use with Word or Libreoffice. Just couple ideas to get this done.

tags: removed: xspf
tags: added: playlist
Revision history for this message
David Nadasi (macrophone) wrote :

I would like to easily import xspf playlist generated by clementine without absolute path. Other types of playlist format rely on absolute path so if the file is not at the right place it doesn't show up in the imported playlist.

Revision history for this message
David Nadasi (macrophone) wrote :

sorry my previous comment is not correct: my problem is that relative path are not imported, witch is related to :
https://bugs.launchpad.net/mixxx/+bug/1836243

tags: added: hackathon
Revision history for this message
Swiftb0y (swiftb0y) wrote :

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

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.