-
Notifications
You must be signed in to change notification settings - Fork 198
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
Non-ASCII characters and Encoding Issue #882
Comments
Hi. The application should be able to handle any UTF-8 data as demonstrated by the following screen shot from my test library. Are you sure that your file is actually using UTF-8 encoding on its metadata? If you can share a sample of such a problematic file, I can take a look. You can find my email address from my github profile. |
Okay. I have mailed you with the theme |
Thanks for the file. Indeed it seems that the file contains metadata encoded in some non-standard way. The thing is, this file contains the title, artist name, and album name in its RIFF headers, but those headers are supposed to be encoded using ISO8859-1. This encoding, on the other hand, can only store Latin-based scripts. But now this file uses some other encoding there. It doesn't seem to be UTF8, either, but even if it was the file would still be violating the standard. I viewed the file also with the Mp3tag software and this is how it showed up there: However, this isn't quite the whole story yet. I noticed that it's possible to write more proper Japanese tags to the WAV file with the Mp3tag application. When this is done, it uses ID3v2.3-type tags for the UTF-8-encoded data while simultaneously filling the RIFF headers with substitute strings like "??? ~ Eastern Night". That is, anything not representable in ISO8859-1 is substituted with a question mark there. This is reasonable but unfortunately it didn't work with the Music app all that well: the Music app found both the RIFF headers and the ID3v2.3 tags but chose to show the name "??? ~ Eastern Night" from the RIFF header instead of the more appropriately filled ID3v2.3 tag. I still need to investigate if there would be any saner way to arbitrate between the different tags formats. |
Now I know why it happens. Thank you for answering👍 |
The new Music v1.3.2 release now contains a fixed version of the getID3 library where WAV files with non-Latin characters work better. Files like in the opening post (*) still cannot be supported, because that is basically not possible by following the standards. However, the WAV files containing ID3v2 tags should now be shown correctly with any Unicode content. The ID3v2 tags may be written, for example, with the Mp3tag application. (*) File with metadata stored in the RIFF headers using some encoding other than ISO8859-1 |
Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:
永夜抄 ~ Eastern Night.
.�i���@�` Eastern Night.
.Expected behavior
There should be a theme shown as
永夜抄 ~ Eastern Night.
Screenshots
Server (please complete the following information):
The text was updated successfully, but these errors were encountered: