Unicode file names are not supported when writing to tag

[Mapaler]

When the file name contains unicode characters, it cannot be written. Manually changing to the ASCII character set can be written.

[Martchus]

What do you mean with "Manually changing to the ASCII character set"? Are you simply changing the filename to contain only ASCII-characters or are you changing the code page setting for the process?

Which version/build of Tag Editor is this and which version/build of Windows are you running it on? Which code page do you use? Is it also happening with the later Qt 5 based build? Is the CLI working when using a decent terminal¹? I'm just wondering because I've already fixed that problem at some point.

¹ Since you're using cmd.exe, please also be aware of https://github.com/Martchus/tageditor#windows-specific-issues.

[Martchus]

Likely a regression introduced by e277070e9cc855f927ffcb0eec974a2dc8d52776.

[Mapaler]

I'm using tageditor-qt6-3.6.1-x86_64-w64-mingw32.exe.zip
If I manually change the filename あよ - 蛙楽.mp3 to a.mp3, the write succeeds.

And I don't know how to changing the code page setting for the process.

The code page is automatically switched to UTF-8 after executing the TagEditor

The same problem exists in powershell.

I installed v3.5.0 on chocolatey can successfully write to the unicode file.

[Martchus]

And I don't know how to changing the code page setting for the process.

No problem. I suppose you've provided enough information now - especially because I could pin it down to Martchus/tagparser@e277070.

The code page is automatically switched to UTF-8 after executing the TagEditor

Right, that's the default behavior of Tag Editor described in the linked README section I've already mentioned (https://github.com/Martchus/tageditor#windows-specific-issues).

I installed v3.5.0 on chocolatey can successfully write to the unicode file.

Yes, as mentioned it is a recent regression. So I recommend to use the older version for now. (Of course I'll be fixing the problem. It will just take a few days as it involves testing on a Windows system, WINE is apparently no help here.)

[Martchus]

The problem should be fixed by: Martchus/tagparser@4f22179

You can try the development build: https://martchus.no-ip.biz/repo/experimental/win/tageditor-issue-81.exe

[Mapaler]

The write is already successful.

---

Here's another question, you see if need to open a new issue.

Open the song, do nothing, just click Save.

There is a warning that does not know what the meaning is.

The metadata has changed. Additional ID3v1 added. It also shows that the comment tag name has changed. (Use Beyond Compare 4)

Id3v1 is also generated using the command line.

Neither version can set the song title for Chinese.

There is the song.
あよ - 蛙楽.mp3.zip

[Martchus]

The warning is likely just that the added ID3v1 tag can not represent some of the entered values. Since the ID3v1 tag is only acting as fallback for compatibility that should be ok. Of course you can disable the creation of an ID3v1 tag in the GUI settings or via a CLI option (see README).

Note sure what the problem with the GUI's behavior is. That it takes over values from ID3v2 to ID3v1 is also expected. The comment doesn't look different except that :XXX is missing on the key (which shouldn't make a difference).

That the app crashes on an unhandled exception in the end is definitely a bug. However, maybe there's really an invalid multi-byte sequence specified by you.

[Mapaler]

I can use the Foorbar2000 to set the ID3v1 with Chinese and Japanese.
Is TagEditor unsupportable?

[Martchus]

So far Tag Editor only uses Latin-1 in ID3v1 tags as some software has problems when putting UTF-8 there and Latin-1 seems to be the accepted default. Maybe it makes more sense to open it up for UTF-8 at this point. (It can already deal with existing UTF-8 values and if you'd use the C++ library directly you'd also be able put UTF-8 values in.)

Note that ID3v1 hasn't been invented with support for different character sets in mind. So maybe in your case it is the best to disable ID3v1 creation. I'd mention it serves as a fallback for older software not capable of reading ID3v2 tags. However, if that leads to software accidentally interpreting data in a wrong character set as you're using non-Latin-1 characters I'd say you might be better of without it after all.

[Mapaler]

Thanks, I will remove ID3v1 in later work.

[Martchus]

I suppose I can close this issue as the original problem has been fixed and ID3v1 is just not a good idea when using non-ASCII characters anyways.