We need a portable, multiplatform (Win,Linux,MAC) server application which can read the iTunes music library or a playlist directory, and generate multiple MP3 RTP Multicast streams ("channels") from playlists. To configure which playlist is multicasted on which port number, a configuration UI/storage (preferences) will be needed. For each channel/playlist, a start and stop time should be configurable (default from 00:00 to 00:00, so always).
We think the application is ideally written in Java to be portable and easy to use on different platforms.
The application must be able to use the "itunes" library format (the xml file) to find playlists and song files, or a very simple directory format (one directory contains playlists, in M3U format). Which format is used must be configurable (and also the path to the iTunes library resp. m3u directory).
A simple UI must be exposed by the application to allow configuration of the path to the library/m3u directory, the choice of either iTunes lib or m3u, as well as the playlist names for the channels and the corresponding port numbers. Ideally, the playlist names are presented as a drop-down menu (choices pulled from iTunes library or m3u directory). In addition, a selection to either play the titles in the order of the playlist or to shuffle them (shuffle - not random, that means make a random permutation of the list once then play them in sequence of the permutation) will be required.
Playlists always will "repeat", so once the playlist is finished the channel must begin playback from the beginning.
The UI must also expose a status display, which can be kept simple, showing a table (a row per channel, showing port number, playlist title, and which title currently is played).
In addition to the above, a simple "about" screen showing the Barix logo, version and copyright is required.
The application needs to be reasonably documented (user documentation).
How-to do the RTP/Multicast playout (on a per file basis):
The player must open the music file, strip any non-MP3 frame information (such as ID3 tags, incomplete frames), and determine
the duration of the frames from the MP3 headers. It may be assumed that all frames have the same duration (sample rate), it is NOT required to determine that on a per-frame basis. The MP3 frame format is well documented, so this is not a complicated problem.
The RTP frames then should be sent out as accurate as possible timed ("even spacing"). Our suggestion to implement that is to remember (per channel) the last time (in ms/us) when the last frame has been sent, add the frame duration to that time, and wait until system time is above this value, then send the next frame and add the frame duration to the remembered value. This makes sure timing stays overall accurate even if the process would not be getting cpu attention for longer than a frame.
The iTunes library format is very well documented.
If you don't agree with the given budget, please PM.