Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracks with non-English characters rejected when importing playlists #1047

Closed
Valoiro opened this issue Feb 21, 2023 · 6 comments
Closed

Tracks with non-English characters rejected when importing playlists #1047

Valoiro opened this issue Feb 21, 2023 · 6 comments

Comments

@Valoiro
Copy link

Valoiro commented Feb 21, 2023

From a desktop web browser create a new playlist then "Import from file" - all tracks with non-English characters are rejected -
e.g. Blue Öyster Cult - (Don't Fear) The Reaper.mp3, Urban släke - Så jävla svensk.mp3

@paulijar
Copy link
Collaborator

If your playlist file has the extension .m3u, then it's assumed to be encoded as Latin-1, unless another encoding is given in the tags of the file. If the extension is .m3u8, then the encoding is assumed to be utf-8 by default. Most likely you now have utf-8 within .m3u file without defining the encoding and that combination doesn't work.

@Valoiro
Copy link
Author

Valoiro commented Feb 25, 2023 via email

@paulijar
Copy link
Collaborator

This interpretation is in our own hands.

As I have understood it, the .m3u format originally used the Latin-1 encoding. Later, the .m3u8 format was introduced to be its UTF-8 equivalent. But as years go by, it's probably becoming more and more common to use UTF-8 also in .m3u files. As there's no actual standard available, there's strictly speaking no right or wrong way to do this.

So yes, it might make sense to interpret the file as UTF-8 if it seems to be valid UTF-8, regardless of the file extension. As you may know, all valid UTF-8 can be interpreted as some valid characters in Latin-1 but all valid Latin-1 cannot be interpreted as valid UTF-8. But still, this logic would be only heuristic: there are cases where the same stream of bytes is both valid Latin-1 and valid UTF-8 but the interpretation is different.

paulijar added a commit that referenced this issue Apr 30, 2023
Previously, playlist files with the .m3u extension were always interpreted as
ISO-8859-1 unless otherwise specified with the tag #EXTENC. However, it's
nowadays increasingly common to use UTF-8 encoding also in those files and the
use of the #EXTENC tag is uncommon.

With this commit, any .m3u file looking like valid UTF-8 is interpreted as
UTF-8. ISO-8859-1 is used only if the UTF-8 interpretation fails or the
#EXTENC tag rules so.

refs #1047
@numerfolt
Copy link

Might it not be better to assume UTF-8, even if it is an .m3u file?

A fix was already added but to manually fix this for one playlist, one can:

  1. Add the line #EXTENC: UTF-8 between the first line (saying #EXTM3U) and the first entry of the playlist.
  2. Or rename the file from .m3u to .m3u8

And I agree, this app is great!

@Valoiro
Copy link
Author

Valoiro commented May 2, 2023 via email

@paulijar
Copy link
Collaborator

paulijar commented Jun 6, 2023

Also .m3u files are now assumed to be in UTF-8 by default in the newly released Music v1.8.4.

@paulijar paulijar closed this as completed Jun 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants