Chinese/Japanese language garbled in music metadata

[Viscacha 0]

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 3204]

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 38499]

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

[Viscacha 0]

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

Edited January 19, 2022 by Viscacha

[Luke 38499]

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 0]

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

[TerranceLiang 1]

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 1]

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 1]

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, 2022 by TerranceLiang
typo correction

[Luke 38499]

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.

[bungoume 1]

I'm facing the same issue with this thread.

Would it be possible on the Emby side to make a modification so that it prioritizes the ID3 tags when they exist?

Tag management software like Mp3tag seems to write the RIFF of WAVE files in Windows-1252 format rather than UTF-8.

As a result, Emby prioritizes the RIFF over the ID3 tags, leading to garbled characters. Since RIFF is primarily for compatibility purposes, I would appreciate it if Emby could prioritize reading the ID3 tags when they are available.

[Luke 38499]

On 12/24/2023 at 1:11 AM, bungoume said:

I'm facing the same issue with this thread.

Would it be possible on the Emby side to make a modification so that it prioritizes the ID3 tags when they exist?

Tag management software like Mp3tag seems to write the RIFF of WAVE files in Windows-1252 format rather than UTF-8.

As a result, Emby prioritizes the RIFF over the ID3 tags, leading to garbled characters. Since RIFF is primarily for compatibility purposes, I would appreciate it if Emby could prioritize reading the ID3 tags when they are available.

HI @bungoumewe use ffprobe for media info. If you run the file through ffprobe, what does it output for these values?

[bungoume 1]

I prepared a random wave file and added Japanese metadata using mp3tag. When I checked with ffprobe, it displayed in Japanese. However, when I used Emby, it showed "???".

```
Input #0, wav, from 'wave_metatest.wav':
  Metadata:
    track           : 20
    album           : albmアルバムalbm
    composer        : 作曲家
    genre           : JPop
    title           : title日本語タイトルtitle
    artist          : art日本語アーティストart
    album_artist    : アルバムアーティスト
    date            : 2023
  Duration: 00:00:07.84, bitrate: 1536 kb/s
  Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, 2 channels, s16, 1536 kb/s

```

(Upon rechecking with the binary data, the RIFF that appeared as "???" was found.)

 

 

After removing the RIFF, the file appeared as follows.

 

 

I'd like it to read the ID3 metadata instead of RIFF, similar to how ffprobe behaves.

[xiaobaiya 6]

This issue has indeed been around for quite some time, compelling me to manage my music through Plex. I hope that EMBY can rectify this problem, so that I can have an all-in-one EMBY experience.

[Luke 38499]

On 12/26/2023 at 9:12 AM, xiaobaiya said:

This issue has indeed been around for quite some time, compelling me to manage my music through Plex. I hope that EMBY can rectify this problem, so that I can have an all-in-one EMBY experience.

It is a problem in ffmpeg. I believe this can be solved using utf8.

Wouldn't you rather have a personal media server and not one that puts your information into the cloud?

[bungoume 1]

 

The result from ffprobe doesn't seem to be garbled, so I still recognize the issue to be on the Emby side.

@LukeCould you please share the specific section of the code where this process is occurring?
I will try to make the fix on my end.

[TerranceLiang 1]

13 hours ago, Luke said:

It is a problem in ffmpeg. I believe this can be solved using utf8.

Wouldn't you rather have a personal media server and not one that puts your information into the cloud?

As in my test, the latest (6.1) ffprobe works fine, and the previous release (4.4.1) garbles

Maybe Emby can consider upgrading the integrated ffprobe?

[bungoume 1]

> As in my test, the latest (6.1) ffprobe works fine, and the previous release (4.4.1) garbles

Thank you very much.

The emby/embyserver:latest docker container was experiencing character encoding issues with ffprobe v5.0.
However, after updating to emby/embyserver4.8.0.64, the problem was resolved with ffprobe version 5.1-emby_2023_06_25.

 

[Guest]

On 27/12/2023 at 21:40, Luke said:

It is a problem in ffmpeg. I believe this can be solved using utf8.

Wouldn't you rather have a personal media server and not one that puts your information into the cloud?

What do you mean when you mention your information being put into the cloud?