Chinese/Japanese language garbled in music metadata

[Viscacha]

Chinese/Japanese language garbled in music metadata. This problem only display on wav files.And I try to use Mp3tag rewrite metadata with UTF-8 but it doesn't work. 

[Abobader]

Hello Viscacha,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Luke]

Hi, after you rewrite with utf8, then run a library scan in emby server. Please let us know if that helps. Thanks.

[Viscacha]

Thanks for you reply. library scan is helpless,And my server env is Synology Ds920+ .

Edited January 19 by Viscacha

[Luke]

1 hour ago, Viscacha said:

Thanks for you reply. library scan is helpless,And my server env is Synology Ds920+ .

Hi, what do you mean library scan is helpless? What exactly did you do?

[Viscacha]

sorry for my poor English。I mean I click the library scan button but nothing happened。 

[TerranceLiang]

Hi there, thanks for the awesome platform develepment, I'm recently updating my music libirary and also crushed on the same problem, I've workd about one day solving it but nothing goes better. I post my situation below, hopefully my they do help to you/us. 

Env: 

• Emby server (in docker): 4.6.7.0, docker image: df4586193beb

What happened:

• It happens only on the *.wav files (how has wavtag/ID3tag), the *.flac files recognizes well.
• Rescan/metadata refresh does not help, since I also tried creating a new media library for the testing.
• I tried mp3tag (ID3v1, v2.3 ISO-8859-1, v2.3 UTF-16, v2.3 UTF-8, remove the tag and rewrite with these formats), not working.
• I also tried to update the tag with foobar2000, musicbrainz picard, none of which works.
• I tried utf-8, utf-16, gb2312 (simplified Chinese), iso8859-1 encoding, and none of them works.
• mp3tag has a function named "codepage convertion", I applied them but doesn't work. 
• I also probe the tag with ffprobe (version 4.4.1-full_build-www.gyan.dev Copyright (c) 2007-2021 the FFmpeg developers), it looks like returns exactly as what emby does.

I think this issue has existed for a long time, since there are discussions from 2018, I know from here this issue might be caused by the ID3 tag encoding, however I have no idea for the solution (on why aren't working), I'm still trying with the solutions provided in the webpage.

I've attached my wav files on Google Drive, and some of my screenshots with this comment. They are some ffprobe output (blue background), mp3tag+foobar+MS explorer (white), and emby+picard (black).

[TerranceLiang]

Okey,

I found it caused by RIFF tag with Kid3, I modified the tag content and it works fine, next step is to figure out how to massively update this tag with right encoding.

Scrrenshot (emby web - kid3 - ffprobe)

[TerranceLiang]

What I posed above helps with few files, or all files in the smae folder.

For the recurrently paths, I found a solution with the kid3-cli. Currently it works fine for me.

It's to find all my *.wav file, and copy the ID3 tags (tag 2 in the kid3) to the DIFF tags (tag 3 in the kid3).

Code:

find /path/to/your/music/folder/ -name '*.wav' -exec /path/to/your/kid3-cli -c "select *.wav" -c "tag 2" -c "syncto 3" -c "save" {} \;

However, I'm still wondering why almost all the tageditor wrongly encode the DIFF wav tag, and is there any other workarounds (e.g., force emby read ID3 tags) for this issue?

 

Usefull links:

Kid3 handbook, Kid3-CLI handbook, Kid3 Linux binary, Kid3 Win binary.

 

previous display v.s. current display

 

Edited January 21 by TerranceLiang
typo correction

[Luke]

After you edit the files simply run an emby library scan and the server will pick up the changes. Please let us know if this helps. Thanks.