Completed Support ID3v2.4 specification

[escapereality 11]

Emby doesn't completely support the ID3v2.4 specifications yet. For example a key difference with v2.3 is native support for multiple values for tags. The official id3 website states "All text information frames supports multiple strings, stored as a null separated list, where null is reperesented by the termination code."

 

Currently Emby just shows the first value of the NUL-character separated list.

[Luke 42077]

hi @@escapereality, we use ffprobe to scan audio tags so I guess we will need to see what version that supports.

[escapereality 11]

As far as I can see ffprobe reads id3v2.4 values. I'll experiment a bit with the sole ffprobe cli tool and post my findings.

[Luke 42077]

Thanks. If you can provide some samples files I'll test them as well.

[escapereality 11]

Here is a file with multiple genre and artist tags, following the ID3v2.4 specs. Notice the differences between mid3v2 and ffprobe.

 

nicola@linx ~ % mid3v2 --list 01_Infinite_\(Original_Mix\).mp3

IDv2 tag info for 01_Infinite_(Original_Mix).mp3

APIC=cover front, (image/jpeg, 94701 bytes)

COMM=iTunNORM=eng= 0000525E 0000525E 0000CDEC 0000CDEC 00000000 00000000 00008000 00008000 00000000 00000000

TALB=Infinite

TBPM=150

TCMP=0

TCON=Hardstyle / test / Hard Dance

TDRC=2017

TIPL=[unrepresentable data]

TIT2=Infinite (Original Mix)

TPE1=B-Front / Test1

TPE2=B-Front

TPUB=Roughstate

TRCK=1

TXXX=CATALOGNUMBER=ROUGH082

TXXX=R128_ALBUM_GAIN=0

TXXX=R128_TRACK_GAIN=0

TXXX=REPLAYGAIN_ALBUM_GAIN=-13.24 dB

TXXX=REPLAYGAIN_ALBUM_PEAK=1.000000

TXXX=REPLAYGAIN_TRACK_GAIN=-13.24 dB

TXXX=REPLAYGAIN_TRACK_PEAK=1.000000

UFID=http://musicbrainz.org=b''

 

nicola@linx ~ % ffprobe 01_Infinite_\(Original_Mix\).mp3

Metadata:

title : Infinite (Original Mix)

artist : B-Front

track : 1

album : Infinite

date : 2017

genre : Hardstyle

compilation : 0

TBPM : 150

album_artist : B-Front

TIPL : arranger

publisher : Roughstate

R128_ALBUM_GAIN : 0

R128_TRACK_GAIN : 0

CATALOGNUMBER : ROUGH082

REPLAYGAIN_ALBUM_PEAK: 1.000000

REPLAYGAIN_TRACK_PEAK: 1.000000

REPLAYGAIN_ALBUM_GAIN: -13.24 dB

REPLAYGAIN_TRACK_GAIN: -13.24 dB

iTunNORM : 0000525E 0000525E 0000CDEC 0000CDEC 00000000 00000000 00008000 00008000 00000000 00000000

Duration: 00:05:00.64, start: 0.025056, bitrate: 322 kb/s

Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 320 kb/s

Metadata:

encoder : Lavf

Side data:

replaygain: track gain - -13.240000, track peak - 0.000023, album gain - -13.240000, album peak - 0.000023,

Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 600x600 [sAR 1:1 DAR 1:1], 90k tbr, 90k tbn, 90k tbc

Metadata:

comment : Cover (front)

01_Infinite_(Original_Mix).mp3

[Luke 42077]

What fields exactly? Thanks.

[escapereality 11]

TCON and TPE1

[Luke 42077]

Ok yes unfortunately ffprobe is only giving me one entry for those, and is not supporting the multiples. I don't see any switches in their documentation to indicate v 2.4. I think this might have to be reported on their issue tracker. Thanks.

[escapereality 11]

Allright, I will (after celebrating nye )

[escapereality 11]

I've reported it on their tracker.

 

https://trac.ffmpeg.org/ticket/6949

[Luke 42077]

Excellent, thanks !

[escapereality 11]

The devs of FFmpeg don't seem to respond to the issue. Could it be possible to implement this feature in Emby without native support in FFprobe?

 

Sent from my SM-G950F using Tapatalk

[Luke 42077]

if we have to use another library for this and probe files 2x with two different libraries that is just going to bring out a whole new crowd of complainers over how long that takes.

[escapereality 11]

Allright, I understand. Maybe I'm thinking way too simple, but isn't implementing a cross-platform mid3v2-ish command line tool doable (don't know if something like that exists)? Only for music metadata parsing.

 

Sent from my SM-G950F using Tapatalk

[Roendi 16]

I have the same Problem. All my DSF File are tagget with ID3v2.4. Bevor I have the same Problem. The Minimserver read only the first Genre Type. 

DSF Issiue (minimserver.com)

On the Minim Server DSF tagged Files works fine. I see the smal Problem on the EMBY Server. Please fix this.

 

[Luke 42077]

3 hours ago, Roendi said:

I have the same Problem. All my DSF File are tagget with ID3v2.4. Bevor I have the same Problem. The Minimserver read only the first Genre Type. 

DSF Issiue (minimserver.com)

On the Minim Server DSF tagged Files works fine. I see the smal Problem on the EMBY Server. Please fix this.

 

Hi, id32.4 will be supported in the upcoming Emby Server 4.7 release. Thanks.

[Roendi 16]

Nice thanks for this Information

[rfporter 34]

Sorry to revive this thread, but are you sure that id3v2.4 is supported in v4.8.8?

I've tagged my music in picard using id3v2.4 with the ARTISTS  and ALBUMARTISTS multi-value tags, which are NULL delimited. Emby appears to only recognize the first value.

Jellyfin, Gonic, and LMS all pickup these multi value tags correctly.

[ginjaninja 605]

On 22/11/2024 at 14:06, rfporter said:

Sorry to revive this thread, but are you sure that id3v2.4 is supported in v4.8.8?

I've tagged my music in picard using id3v2.4 with the ARTISTS  and ALBUMARTISTS multi-value tags, which are NULL delimited. Emby appears to only recognize the first value.

Jellyfin, Gonic, and LMS all pickup these multi value tags correctly.

still working for me on 4.9.0.31... (or at least embys ffprobe is seeing the two artists and albumartists, and a refresh metadata still shows the two in the ui...so think thats working normally for me)..maybe send through your test file?

[rfporter 34]

I've tried this on emby (synology) v4.8.8, emby (docker) v4.9.0, and again emby (docker) v4.7.0 9 and v4.9.0.11. The last two were because it was mentioned in another post that this was fixed in v4.7.0.9. However ffprobe in all of those versions yields the same result for me. Only the first artist is reported.

I see thay you are using emby (windows). I will give that a try.

[rfporter 34]

Its working on Emby v4.8.10 for Windows.

It seems that the modified version of ffprobe only made it into the windows release. Not synology or docker releases.

Any chance that I could just get a copy of the modified ffprobe binary for my synology DS920+?

I'm running Emby v4.8.8 but don't mind upgrading if necessary.

[softworkz 5066]

@rfporter- How are you invoking ffprobe on Linux?

If you move into the folder where Emby's ffmpeg and ffprobe are located, you need to prefix with dot and slash:

./ffprobe ...

Otherwise you're invoking a system-installed ffprobe instead. Just in case you didn't know.

Our ffmpeg/ffprobe code is identical across platforms (except hw acceleration), so if it still doesn't work, please PM me a file for testing on Linux.

Thanks

[rfporter 34]

Ah. On Synology I get this when trying to execute /var/packages/EmbyServer/target/bin/ffprobe:

./ffprobe: error while loading shared libraries: libavdevice.so.59: cannot open shared object file: No such file or directory

I think that maybe ffmpeg and the video drivers were replaced when I installed JellyFin from SynoCommunity.

 

On Docker it does appear to be the emby-modified ffprobe version 5.1-emby_2023_06_25

but it does not correctly read multiple album artists on ID3v2.4 tagged tracks. It just reads the first artist.

For example this track:

Will produce:

[softworkz 5066]

1 minute ago, rfporter said:

Ah. On Synology I get this when trying to execute /var/packages/EmbyServer/target/bin/ffprobe:

./ffprobe: error while loading shared libraries: libavdevice.so.59: cannot open shared object file: No such file or directory

You need to run 

/var/packages/EmbyServer/target/bin/emby-ffprobe

This will set up the environment in the same way as Emby sees it.

 

[softworkz 5066]

9 minutes ago, rfporter said:

On Docker it does appear to be the emby-modified ffprobe version 5.1-emby_2023_06_25

but it does not correctly read multiple album artists on ID3v2.4 tagged tracks. It just reads the first artist.

I can only vaguely remember the whereabouts when I implemented this. But one thing comes to my mind: At the end it was all fine, but there was a way how the "Picard" app from MusicBrainz stored multiple values which does not conform to ID3v2.4 and we don't support this.