Playlist m3u wrong encoding / chars

[pepi01]

Hello,

I use quite a lot VLC for the playlists inside my USB drive that i use on my car to have music playlist. Till here all fine, on VLC < 3.0 I just drag drop the music from the USB Drive to VLC, save playlist as m3u and no issues.

Since the newer versions 3.0 i noticed something has changed in the way to deal with playlist.

1. Order or add music
2. Save the playlist as m3u on the same drive
3. When i open the list with the notepad i see wrong encoding (as spaces with %20 etc...)

Is there some workaround or maybe some setting has changed since the update?
On other computer I've 2.2.6 and i can edit / save and i don't find issues.

[Jean-Baptiste Kempf]

And the player cannot read those % ?

[Rémi Denis-Courmont]

This sounds correct, actually. Does the playlist generated by VLC 3.0 not open correctly inside VLC 2.2 and 3.0 ?

[pepi01]

Actually some songs are not recognized using another VLC.
However the main issue it's regarding another devices, like the car, he don't recognize the playlist at all.

I though was due some encoding difference but i converted from ANSI to UTF8 and same result, creating the Playlist using VLC 3.0+ it get generated differently than previous version of VLC in my case... :/

[oortone]

I just had the same problem. I use VLC o create playlists for Sonos (which for some strange reason is too stupid to create them itself) and after updating the new format does not work anymore.

Anyone who knows what this new format where space is replaced with %-signs and stuff is called?

[Rémi Denis-Courmont]

The file format is MP3 URL, or M3U for short. The lines are URLs.

[oortone]

Thanks Rémi but I meant what it's called when %-signs and numbers are used instead of blankspace in paths. So it's not the file format but the way to encode paths this way I wanted to know the name of.

[oortone]

I compared this to iTunes and that program does not use %-characters and numbers in it's path descriptions. I wonder why VLC has changed this? I don't think it complies to the standard for m3u playlists:
http://n4k3d.com/the-m3u-file-format/

[Rémi Denis-Courmont]

Thanks Rémi but I meant what it's called when %-signs and numbers are used instead of blankspace in paths. So it's not the file format but the way to encode paths this way I wanted to know the name of.

It's called URL.

[oortone]

Thanks Rémi but I meant what it's called when %-signs and numbers are used instead of blankspace in paths. So it's not the file format but the way to encode paths this way I wanted to know the name of.

It's called URL.

No, not really. Replacing characters by the percantage charcter followed by numbers is not in itself called "URL". But you're on to something. The Wikipedia chapter of Internationalized URL:s shed some light upon this:
https://en.wikipedia.org/wiki/URL
"The URL path name can also be specified by the user in the local writing system. If not already encoded, it is converted to UTF-8, and any characters not part of the basic URL character set are escaped as hexadecimal using percent-encoding"


But in the case of VLC-playlists it's mainly the space character that is replaced by %20 so it's not primarily a matter of internationalisation.
The interesting question is how many mp3-player systems that are incompatible with this %-encoding.
Seeems to be quite a few. VLC should have made it a user option to use either classic encoding (WINamp style) or this new encoding style. One could probably argue that the m3u-playlists prouced by VLC nowdays shouldn't even be allowed to be called m3u since they are not compatible with the classic m3u-format.

[Rémi Denis-Courmont]

Thanks Rémi but I meant what it's called when %-signs and numbers are used instead of blankspace in paths. So it's not the file format but the way to encode paths this way I wanted to know the name of.

It's called URL.

No, not really.

The way VLC formats the lines is called URL. There is no "replacing" involved here. That's what the U in M3U stands for.

Using file paths instead of URLs is out of question. We need URLs to support HTTP, FTP, to avoid codepage problems, and to support moving playlists from one system to another or to the cloud.

I could not care less about broken third party software.

[pepi01]

i need to disagree.
The format i was using it wasn't the URL format, indeed now you can save it and it appears as URL however the behaviour has changed since the last version and now spaces are replaced by different characters etc...

on the previous version i was just putting songs on the playlist, saving it and voila, right now it totally change the "enconding" of the file which makes my car system don't recognize it.. so far I'm using an older version of VLC to adjust the playlist

[Rémi Denis-Courmont]

https://en.wikipedia.org/wiki/M3U

[oortone]

https://en.wikipedia.org/wiki/M3U

That doesn't really "prove" anything since VLC did not use that URL-format with escape charactes until recently but they have called their playlists M3U for ages and so has many other applications not using that "standard".
Unless this M3U file format was specified in real standard like IEEE when it was first implemented there's no truth or right or wrong, instead there's been a practice which VLC now has broken. What you believe "we need" is not an argument, that varies.

Also there's no such thing as "third party software" in this discussion since VLC didn't invent the format or standardized it.

Also the Wikipedia page you refer to have examples not using %-escape characters and it also describes URL:s, relative and absolute paths as valid for the M3U format which means that the URL in the name M3U really means "URL", they uset it in an informal fashion apparently.

[Rémi Denis-Courmont]

That doesn't really "prove" anything since VLC did not use that URL-format with escape charactes until recently but they have called their playlists M3U for ages and so has many other applications not using that "standard".

If you are implying that VLC invented URLs in M3U, you are being ridiculous. Internet radio channels, and more recently HLS, have used that format for years and years and years.

And there is only one URL format, and it has a proper standard (IETF RFC3986).

Also the Wikipedia page you refer to have examples not using %-escape characters and it also describes URL:s, relative and absolute paths as valid for the M3U format which means that the URL in the name M3U really means "URL", they uset it in an informal fashion apparently.

M3U can contain URLs and file paths, relative or absolute. VLC follows those rules. It reads M3U playlist with relative or absolute, URls or file paths - except for a few unsolvable ambiguous corner cases. It writes M3U playlist containing "URLs or file paths" as well.

[InTheWings]

https://en.wikipedia.org/wiki/M3U

The above mentioned wikipedia examples shows local files not being encoded as URI at all.
That's also the most common way found in the wild.

We probably need to process local files list as encoded only when when %XX is in use

[mederi]

Since Winamp times there is no percent-encoding/URL encoding of paths of local files in m3u playlists. VLC could also preserve the option to save m3u playlists for local files without the special encoding, just lists of human-readable paths in simple text files (ANSI/UTF8). VLC supports/loads them, but now cannot save them. If a playlist is stored on the same drive, then relative paths should be used, otherwise absolute ones. I suggest to add another m3u saving profile besides current m3u/m3u8 profiles.

[Rémi Denis-Courmont]

Since Winamp times there is no percent-encoding/URL encoding of paths of local files in m3u playlists. VLC could also preserve the option to save m3u playlists for local files without the special encoding, just lists of human-readable paths in simple text files (ANSI/UTF8). VLC supports/loads them, but now cannot save them. If a playlist is stored on the same drive, then relative paths should be used, otherwise absolute ones. I suggest to add another m3u saving profile besides current m3u/m3u8 profiles.

No. As explained before, this breaks if the playlist is uploaded to remote storage (alongside the files that it refers), as you cannot have relative file paths for non-file resources.

[the_clansman_fr]

Hello,
Wanted to use VLC as I use usually to generate m3u files.
As seen on this post that vlc 3.0 and vlc 2.0 does not generate m3u file by the same way.
So, it is a bug.
I've uninstalled vlc 3.0 to install 2.0 and all is working fine.
Is it possible to upgrade vlc 3.0 to make an option concerning m3u generation to keep functionnalities installed in vlc 2.0 soft?
Thanks.

[the_clansman_fr]

More information:
In the wiki (https://en.wikipedia.org/wiki/M3U) we can see that the format is like this:
#EXTINF:123, Sample artist - Sample title
C:\Documents and Settings\I\My Music\Sample.mp3
#EXTINF:321,Example Artist - Example title
C:\Documents and Settings\I\My Music\Greatest Hits\Example.ogg
As vlc 3.0 does not respect the wiki anymore, vlc 3.0 has a bug.
So an upgrade has to be done.

[oortone]

That doesn't really "prove" anything since VLC did not use that URL-format with escape charactes until recently but they have called their playlists M3U for ages and so has many other applications not using that "standard".

If you are implying that VLC invented URLs in M3U, you are being ridiculous. Internet radio channels, and more recently HLS, have used that format for years and years and years.

And there is only one URL format, and it has a proper standard (IETF RFC3986).

Also the Wikipedia page you refer to have examples not using %-escape characters and it also describes URL:s, relative and absolute paths as valid for the M3U format which means that the URL in the name M3U really means "URL", they uset it in an informal fashion apparently.

M3U can contain URLs and file paths, relative or absolute. VLC follows those rules. It reads M3U playlist with relative or absolute, URls or file paths - except for a few unsolvable ambiguous corner cases. It writes M3U playlist containing "URLs or file paths" as well.

I didn't imply VLC invented URL:s, I explained why you can't refer to the 'U' (as in URL) in the word "M3U playlist" as some kind of proof why VLC should break the way it used to write M3U playlist. The URL format is apparently well defined, the M3U format is not. That's why VLC should have kept the old encoding as an option.

[oortone]

Since Winamp times there is no percent-encoding/URL encoding of paths of local files in m3u playlists. VLC could also preserve the option to save m3u playlists for local files without the special encoding, just lists of human-readable paths in simple text files (ANSI/UTF8). VLC supports/loads them, but now cannot save them. If a playlist is stored on the same drive, then relative paths should be used, otherwise absolute ones. I suggest to add another m3u saving profile besides current m3u/m3u8 profiles.

No. As explained before, this breaks if the playlist is uploaded to remote storage (alongside the files that it refers), as you cannot have relative file paths for non-file resources.

And using the % breaks other things.
Conclusion, they should have both options.

[Rémi Denis-Courmont]

As vlc 3.0 does not respect the wiki anymore, vlc 3.0 has a bug.

I don't think indiscriminate, excessive, or irrelevant examples in Wikipedia are authoritative, but FWIW, VLC uses the URL format, which is found in Example 4. So it does "respect the wiki".

[Rémi Denis-Courmont]

And using the % breaks other things.

There is a difference between breaking a legitimate use case, and exposing a bug in another software.

Conclusion, they should have both options.

I doubt that the option can be explained in understandable fashion to users. But patch welcome.

[pepi01]

Hello,

I understand the context, however would be possible have an option to choose the encoding method for the M3U ? mostly because the new encoding break the functionality for creating playlist and in my case the car doesn't recognize any of them among other devices i've

Maybe can be a feature request?