Jump to content

Support ID3v2.4 specification


Go to solution Solved by Luke,

Recommended Posts

Posted

I might be hallucinating, but I believe there's even an option in Picard to change this - did you use Piccard to set this metadata?

Posted

I did use Piccard to set this metadata. And verified it with mp3tag.

Its odd that the ffprobe of EmbyServer on Windows can read it correctly, but ffprobe of EmbyServer on docker (and likely Synology) does not.

Posted

Here is the output of ffprobe for the same mp3 file but on Windows. The albumartists tag has both artists, and the MusicBrainz Album Artist ID also has both artists correctly.

image.png.33654171473959c6f8fec5067712504d.png

Posted

Okay, that's odd. Can you PM me the file?

Posted

Also looks like ffprobe windows was built with gcc 12, while ffprobe docker was built with gcc 10. Not sure if that is significant though.

image.png.b16442bc52b0f9259f7e8e3233cb9d27.png

Posted
10 hours ago, rfporter said:

Also looks like ffprobe windows was built with gcc 12, while ffprobe docker was built with gcc 10. Not sure if that is significant though.

No

Posted

Okay, took a very quick look When I execute ffprobe on Ubuntu for this file, it outputs a control code and shows the additional items on the next line:

Ā 

image.png

image.png

Ā 

Maybey in your case, the shell just "swallows" everything behind the control code?

Ā 

Posted

Maybe the shell "swallows" it. Not sure. And I haven't tried on Ubuntu yet. However, the result is in Windows the album artists are correctly interpreted by Emby:

image.png.9bdf75194afec00bc4c8e3715d74ff98.png

But on Synology and Docker Emby only the first artist is recognized:

image.png.fcfe25f6ab693a3522e57c102e3ec47a.png

Posted

It's possible that it depends on the character set being used. Can you try the three variants in Picard and see whether it makes any difference?

image.png

Thanks

Posted

Just tried with UTF-16 and ISO-8859-1. Same result as UTF-8.

In my terminal the missing entries get clumped into one line at the end of the list:

image.png.227bc47e769b25455663462153c12eee.png

Posted

Found the cause. I hope we will be able to include a new ffmpeg build in the next beta.

Thanks for reporting!

  • Like 2
  • Thanks 1
Posted

Thanks for working on this issue. I am eager to try out the new build.

  • Agree 1
  • 2 weeks later...
Posted

It looks like this fix did not make it into v4.9.0.33 beta on Docker.

  • 2 weeks later...
Posted

The fix did not make it into v4.9.0.34 beta on Docker.

  • 2 weeks later...
Posted

Looks like this fix made it into v4.9.0.35 beta on Docker 🤩

  • Like 1
Posted

Awesome! Great to hear it's working now. Thanks for the feedback!

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