[vlc-devel] Re: [PATCH] m3u playlist import and export, version 2
vlc at schmaller.de
Mon Aug 15 17:43:56 CEST 2005
Derk-Jan Hartman wrote:
> On 12 aug 2005, at 16:24, Christophe Mutricy wrote:
>> On Wed, Aug 10, 05 at 12:39 +0200, Daniel Stränger wrote:
>>> I forgot to free psz_author in the first patch version.
>>> This mail comes with the corrected patch.
>> Applied (r12139).
>> A few modifications:
>> the strnlen is a bit over-cautious as stream_ReadLine always
>> return a "\0" finished string and strnlen doesn't exist on windows.
>> in the output module, we need to count the backslases as
>> well as
>> the commas.
> This patch breaks things. If you have a m3u WITHOUT an artist, it
> puts the title into the artist field. UNACCEPTABLE.
Generally that's wrong. if there's no artist, the EXTINF is saved as
"#EXTINF: time,,title" and parsed correctly.
You're right in the case of opening an "foreign" m3u playlist that has
but that's nearly the same as in the 0.8.2 original: if you have an
artist, the artist and title were put into the title field , and that's
just as unacceptable, isn't it!?
>>> hi all!
>>> i've recognized that loading and saving a m3u playlist does not use
>>> same EXTINF format.
>>> In 0.8.1 the playlist entry's extra information was saved as:
>>> Now, in 0.8.2 it's saved as:
>>> #EXTINF:time,artist - name
>>> but during the load of a playlist and parsing the EXTINF-line the
>>> part of the artist was neglected.
>>> i've corrected this misbehavior as follows:
>>> * The delimiter character between time, artist and title is the
> Says who?
Says Version 0.8.1.
> "The problem about using EXTINF data as title is that such data is
> unstructured and unreliable. There is no formal m3u standard to
> specify what should go after the duration data on an EXTINF line -
> the consensus is that the data should be considered as 'display title'.
> Therefore different m3u generators put different types of data there
> - either strings in the format 'artist - title' (or vice versa), or
> just the title, or simply the filename. All of this may be acceptable
> when simply displaying the data as it's human readable"
> As far as I'm concerned the EXTINF should not even contain the artist
> information. And definitely not with ',' as a delimiter.
If there's no formal m3u standard, it's even possible to use a ',' as
> We should store it in a VLC specific way if you ask me.
>>> * If the artist contains a comma, the comma is escaped by a
>>> backslash during export
>>> * of course the newly introduced escape charater "backslash" will
>>> also be escaped
>>> * in the Demux-function the artist *and* the title are parsed and
>>> handled separatly
>>> * the artist will be unescaped and set by vlc_input_item_AddInfo()
>>> the patch file comes as attachment and i hope you check it in to
>>> svn tree after revision.
But on the whole I aggree that we should conform to the WinAmp pseudo
standard and save EXTINF as:
#EXTINF:time, artist - title
Nevertheless the parsing should be adapted for examining such strings to
determine the artist.
Unfortunately i'm having some problems compiling the svn trunc, thus
providing another patch may take a while.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel