Neon John wrote:
> There is a compatible way to do this. Winamp did it in the beginning.
>
> m3u files support the comment field. Winamp put the additional
> information inside a comment. Other parsers would simply ignore the
> entries following, I believe, a semicolon or a pound sign.
>
> To keep the rockbox parser from trying to execute other comments, I'd
> preface each rockbox command with some magic, say, "rockbox:" followed
> by the command.

I thought of that but I couldn't remember for certain if M3U supported
comments.

In any case, I think it would be cleaner to create our own format. The
embedded comment thing can get pretty ugly pretty fast, IMO. Plus,
another app using these customized M3U files would get no benefit from our
customizations. It would even be possible to have customized M3U files
that had ZERO songs in them from the other apps perspective (e.g. a file
consisting of only directory references; something which I, for one, will
be very likely to create).

If we create a facility that can 'convert' a rockbox play list file into
an M3U file then we can generate contents to support most, perhaps even
all, of our custom commands (at least the ones that select songs). The
generated M3U file would then be more meaningful/useful if used in another
app.

In fact, I'm thinking that one relatively easy way to implement this would
be to have rockbox play lists automatically generate an M3U file when they
are 'played', and then (internally) hand-off the generated M3U file to the
existing M3U player in rockbox. In this scenario, the rockbox play list
handler would just need to execute the embedded commands (such as audio
settings) and expand song selection queries into the M3U file. No new
code would need to be written to play from the new play list format. The
resulting M3U file could then be used with other apps and would contain
the full song listing, just as on the rockbox.

I thought of one more file name extension that I like: .BOX

So now I have .RX and .BOX

(I considered .ROX too but I think it sounds too much like .rock and would
cause confusion.)

I think I'm leaning towards .BOX

So maybe if I find some free time I'll look into implementing this. No
promises though: the holidaze is a crazy time... :|

~ray

PS: Here's my first attempt at defining a format (comments please):

------------------------------------------------------------------
Proposed Rockbox Playlist Format:

        - # comment

        - ! config config-statement[; config-statement]

        - ! config load <any config file>

        - ! include /path/playlist[.BOX|.M3U]

        - [/][path/][filename.ext]

        - ! match [recursive] /path/dirname[/regexp]

        - ! select <database query TBD>

        - ! playlist-file <playlist.m3u>

        - ! generate-only

        - ! auto-cleanup

        - ! windows-drive-letter <[A-Z]>

Notes:

        - 'playlist-file' is used to override the default output (M3U)
          file name, which is derived from the .BOX file name

        - 'generate-only' tells the .BOX player to only generate an
          M3U and not to play it. Could be useful in some situations.

        - 'auto-cleanup' tells the .BOX player to automatically delete
          the generated M3U file when it finishes playing. (This may
          prove difficult or impossible to implement.)

        - 'windows-drive-letter' indicates which drive letter to write
          to the M3U file. Default is none.
Received on Wed Dec 7 23:04:11 2005