[MPlayer-users] playlist file syntax

[James Gatt]

Quoting The Wanderer <inverseparadox at comcast.net>:

> James Gatt wrote:
>
> > D Richard Felker III wrote:
> >
> >> On Wed, Dec 08, 2004 at 01:04:36PM +0000, James Gatt wrote:
> >>
> >>> Quoting D Richard Felker III <dalias at aerifal.cx>:
> >>>
> >>>> On Tue, Dec 07, 2004 at 06:20:39PM -0800, Jessica Johnson
> >>>> wrote:
>
> >>>>> The docs say that the playlist format is one file per line.
> >>>>> So it doesn't seem to be possible to make a playlist file
> >>>>> that includes a playtree. (Correct me if I'm wrong here.)  It
> >>>>> would be useful to be able to specify,  say
> >>>>>
> >>>>> { "song1.mp3" "song2.mp3" }
> >>>>> { "song3.mp3" }
> >>>>>
> >>>>> in a playlist file.
> >>>>>
> >>>>> I've been thinking of modifying the source to expand the
> >>>>> accepted syntax of a playlist file.  Is this something other
> >>>>> people would be interested in? Any core developers want to
> >>>>> comment on the likelihood of this patch being accepted?
> >>>>
> >>>> it won't be accepted, because it makes it impossible to play a
> >>>> playlist with a file named '{ "song1.mp3" "song2.mp3" }' in it!
> >>>
> >>> How is that useful? Do you know anyone who puts double quotes in
> >>> filenames? I know you *can*, but... After all, is there a way to
> >>> put filenames containing
> >>
> >> YES, I DO!!! IF IT'S PART OF THE NAME OF THE SONG!! pretty much
> >> anyone who names their mp3s with the full titles rather than just
> >> short_name.mp3 runs into this problem.
> >
> > 1. I didn't think mplayer was intended to be used as an mp3 player -
> > there are much better programs around for doing this, even the
> > mplayer documentation suggests this somewhere.
>
> Well, you were the one who used MP3 files in your "this would be useful"
> sample (not snipped above, far back though it is). The same reason can
> apply just as well to non-MP3 files, as I noted in a previous mail.

Actually, the original post was not mine. I do not use mplayer for mp3 files.

> > 2. "pretty much anyone" is a grossly inaccurate generalisation. Most
> > people either use Windows or like to keep their filenames sane so
> > they can be used on Windows. They use two ' characters instead, which
> > in most proportional fonts looks identical to ".
>
> ..for one thing, that might count as "running into this problem", since
> they have encountered the need to represent a double-quote in a
> filename. For another thing, *very* far from everyone uses proportional
> fonts for filename display - almost all of my own file-naming /
> file-listing interaction is done via the command line, specifically an
> xterm, and I don't think there even *is* a way to use a non-fixed-width
> font there. (I don't think I'd want to, either - it probably wouldn't
> look as good.)

Proportional fonts look dreadful in xterms. ;) (Can't remember how I got them,
but it wasn't what I wanted.) Things that I see using proportional fonts for
filenames are generally GUIs running on Windows boxes. Not sure what the Linux
based GUI file explorer type gadgets use, I rarely use them. Most
non-programmer types who want media players don't use the command line, they
want a nice GUI and names presented nicely. With mp3s this can be achieved
using the id3 tags regardless of the actual filename, but where filenames are
used they are generally displayed using a proportional font.

> I note that you did not snip, but also did not respond to, the
> (admittedly less than ideally coherent) comments I made on the notion of
> "retaining Windows FS compatibility" - while I recognize that some/many
> people do in fact need to do that, I find at-least-almost offensive the
> idea that programs which do not specifically need to do so should
> *require* people to adhere to Windows filename standards. If people want
> to break FS compatibility in their filenames, that's *their* problem
> (and their prerogative).
>
> (I also rather object to the notion that "filenames which are not
> compatible with Windows' naming restrictions are not sane", but that may
> be another argument.)

The more obscure the characters you want to put into a filename, the more
problems you will run into. Some programs and scripts etc. don't even like
spaces in them. There is no hard cut-off point as to what is an acceptable
character other than what the underlying filesystem itself will allow. All I
was saying is that characters such as " are *problem* characters in many
situations, so as a general rule for an easy life they are best avoided.
Personally if I found an application which did not support " in a filename, it
wouldn't bother me as I don't use that character in filenames. That's just my
opinion and the way I deal with that issue.

> >>> linefeeds into playlists? If not then there are already
> >>> restrictions in the filenames allowed by the playlist format over
> >>> and above those of the file system.
> >>
> >> putting linefeeds in filenames is idiotic. putting natural
> >> characters like " and { and } is not. i want to be able to generate
> >> a basic playlist from the output of the "ls" command without
> >> needing to do all kinds of additional processing to escape
> >> characters...
> >
> > Putting double quote characters in filenames is every bit as idiotic
> > as linefeeds - I have not yet seen a shell script written to tolerate
> > either, as both are simply bad practice.
>
> ..no comment, I don't think I have the background (or, at present, the
> stamina) to convince you on this.

I just opt for the path of least resistance. Why make things difficult?

> Well, maybe one comment: your own standard of "usefulness", above.
> Double-quote characters in filenames can be useful, but as I said
> before, I don't see how line-break characters could do the same.

I originally used the linefeed as an example of a character that the underlying
file system does support and mplayer playlists do not. This example proves that
someone has already *decided* to disallow a character even though the filesystem
allows it. I did not say it was *useful* to have that character in filenames.

I am not going to comment on whether or not it is *useful* to have the "
character in filenames - that's up to the user to decide. I was just adding my
two cents that it's not always a good idea in my experience as it's
non-portable and can break scripts.

> >>> Particularly looping. It would be good to be able to specify
> >>> options like looping in playlists as well. Right now the playlist
> >>> support is so basic that I don't think it offers anything more
> >>> than can be achieved using a shell script and just calling
> >>> mplayer for each file to be played. To this end is it really
> >>> worth defending the current playlist format against features
> >>> offered by non-core members?
> >>
> >> yes! people use it and don't want it broken for the sake of some
> >> silly obscure feature. i use "mplayer -shuffle -playlist foo.list"
> >> all the time, and i expect many others do too.
> >
> > I generally use mplayer for playing movies, as I expect most other
> > users of mplayer do also. It is what it does best. Playlists feature
> > little in this mode of operation.
>
> ..that *really* depends on your context, doesn't it? There are in fact
> potential video-playing-related uses for which playlists could be *very*
> useful; I believe I've seen questions on this mailing list which refer
> to them, albeit certainly not recently.

I do actually use playlists for playing some things, although they don't achieve
much a script couldn't do, other than being able to skip to a previous clip from
the middle of another.

Regards,
James.