user-1868
05-05-2020, 02:41 PM
There's an obscure difference between the tagging on Windows and Linux.
On Windows tagging can only contain characters that fall with the ISO8859-1 range as GiP filters the UTF-8 tagging information on Windows. So, mostly there is no effect at all. ISO8859-1 supports most common western european languages. My experience is that the most common use of non-ASCII characters is names in track listing for radio 3 output.
An example is the track listing for Music Planet of 2020-05-02
https://www.bbc.co.uk/programmes/m000hvp5
This contains some Arabic and Chinese. Cyrillic and Greek would also not be supported.
You can see the missing characters in the tracks.txt file. Under Windows you need a text editor that supports UTF-8. Windows 10 notepad does, earlier windows versions don't.
The windows version of AtomicParsley, which actually does the tagging, has wide characterer (UTF-16 - the traditional windows support for Unicode) command line input. So, if the command line could be constructed in UTF-16, which I assume Perl could do, and passed to AtomicParsley, whcih I don't know about, then that would work.
I tried using the --tag-utf8 option to send UTF-8 to AtomicParsley and copying AtomicParsley.exe to AtomicParsley-utf8.exe and pointing at that to make it accept raw UTF-8, but that doesn't work. Probably because of something going on in the conversion to UTF-16 which is implicit in sending any command line to AtomicParsley.
Recently Microsoft have started improving UTF-8 support in Windows. Since windows 10 v1903, setting the code page to 65001 (UTF-8) mostly works for programs such as Atomic Parsley which output UTF-8. It's also possible to add a manifest to an application to show that it expects to work with UTF-8, so that it will not need the code page to be set.
I tried rebuilding AtomicParsley with only UTF-8 support and an appropriate manifest, and that does seem to work. But that's with only one test!
Obviously using the Linux version of GiP is the simplest thing to do. I assume that this will work under WSL (windows subsystem for Linux) on Windows 10.
You could argue that this is a bug in the Windows version, but it has such a tiny affect on the functionality that I would be surprised if anyone other than me would notice, and I already have a fix.
On Windows tagging can only contain characters that fall with the ISO8859-1 range as GiP filters the UTF-8 tagging information on Windows. So, mostly there is no effect at all. ISO8859-1 supports most common western european languages. My experience is that the most common use of non-ASCII characters is names in track listing for radio 3 output.
An example is the track listing for Music Planet of 2020-05-02
https://www.bbc.co.uk/programmes/m000hvp5
This contains some Arabic and Chinese. Cyrillic and Greek would also not be supported.
You can see the missing characters in the tracks.txt file. Under Windows you need a text editor that supports UTF-8. Windows 10 notepad does, earlier windows versions don't.
The windows version of AtomicParsley, which actually does the tagging, has wide characterer (UTF-16 - the traditional windows support for Unicode) command line input. So, if the command line could be constructed in UTF-16, which I assume Perl could do, and passed to AtomicParsley, whcih I don't know about, then that would work.
I tried using the --tag-utf8 option to send UTF-8 to AtomicParsley and copying AtomicParsley.exe to AtomicParsley-utf8.exe and pointing at that to make it accept raw UTF-8, but that doesn't work. Probably because of something going on in the conversion to UTF-16 which is implicit in sending any command line to AtomicParsley.
Recently Microsoft have started improving UTF-8 support in Windows. Since windows 10 v1903, setting the code page to 65001 (UTF-8) mostly works for programs such as Atomic Parsley which output UTF-8. It's also possible to add a manifest to an application to show that it expects to work with UTF-8, so that it will not need the code page to be set.
I tried rebuilding AtomicParsley with only UTF-8 support and an appropriate manifest, and that does seem to work. But that's with only one test!
Obviously using the Linux version of GiP is the simplest thing to do. I assume that this will work under WSL (windows subsystem for Linux) on Windows 10.
You could argue that this is a bug in the Windows version, but it has such a tiny affect on the functionality that I would be surprised if anyone other than me would notice, and I already have a fix.