[vlc-devel] Re: [PATCH] m3u playlist import and export, version 2

[Daniel Stränger]

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:
>>
>>> Hi!
>>> 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 
no artist.
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 
>>> the
>>> same EXTINF format.
>>> In 0.8.1 the playlist entry's extra information was saved as:
>>>   #EXTINF:time,artist,name
>>> 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  
>>> comma!
>>
>
> 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 
the delimiter.

> 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.

regards,
schmaller

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html