Jump to content

Chinese/Japanese language garbled in music metadata


Viscacha

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Viscacha

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

Edited by Viscacha
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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).

564806644_2022-01-21(17).thumb.png.23828a8b334312a9bb0bbe279445a0b1.png2053350453_2022-01-21(16).thumb.png.22b16bf6aa263cd2f661e4887ea895f0.png137313252_2022-01-21(8).thumb.png.9b9c85aed8201782b739a7a210918d6e.png

2022-01-21 (9).png

2022-01-21 (10).png

Link to comment
Share on other sites

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)

Snipaste_2022-01-21_12-19-09.thumb.jpg.6a0b35e03bdcbadfbc14abfc2fd61b5b.jpg

Link to comment
Share on other sites

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 handbookKid3 Linux binary, Kid3 Win binary.

 

previous display v.s. current display

prev.thumb.jpg.a1e27427da8affb2d51fb7880cfda20c.jpgcurr.thumb.jpg.12f8f62592b54fadab98395956528774.jpg

 

Edited by TerranceLiang
typo correction
Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

  • 1 year later...
bungoume

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

bungoume

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

```

image.thumb.png.a648fd49b4a82e285ddfeded07a6f82b.png


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

image.thumb.png.81b50e4f62d6c4203062577eb441084c.png

 

 

After removing the RIFF, the file appeared as follows.

image.thumb.png.e2f57a4b8a006730845caae01936129c.png

 

image.thumb.png.1e1caa7889f32fc6303227d8b1ad0094.png

 


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

Link to comment
Share on other sites

xiaobaiya

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

bungoume

 

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.

Link to comment
Share on other sites

TerranceLiang
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?

Snipaste_2023-12-28_19-39-13.thumb.jpg.fc6ccebec6523ff37d22cc29e1f84ad5.jpg

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?

  • Like 1
Link to comment
Share on other sites

bungoume

> 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.

 

image.thumb.png.9c83f809d8340a6e5f6edc17047f9182.png

  • Thanks 1
Link to comment
Share on other sites

jlambie
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? 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...