Paul77nz 8 Posted March 12, 2019 Share Posted March 12, 2019 (edited) As per the title some MKVs with EAC3 5.1 audio tracks are listed by Emby as being 6 channels instead of 5.1 channels. Others correctly show as 5.1 channels. It sems to be MKVs muxed with more recent version of MKVMerge which seem to be displaying incorrectly. I have confirmed this my taking an MKV that Emby displays as EAC3 5.1 and running it through the latest versions of MKVMerge (31.0.0), and the resulting file is displayed by Emby as EAC3 6 channels. It appears that Emby isn't reading the layout information or bitrate from MKVs that are created in newer version of MKVMerge. MediaInfo correctly shows the audio layout as "Front: L C R, Side: L R, LFE" on both files, so I think it's an Emby issue. Thanks EDIT: These are MKVs from multiple different sources, not just ones I've created. Edited March 12, 2019 by Paul77nz Link to comment Share on other sites More sharing options...
Luke 37071 Posted March 12, 2019 Share Posted March 12, 2019 That is just what ffprobe tells us. I can't imagine this is causing any kind of problem though, right? Link to comment Share on other sites More sharing options...
Paul77nz 8 Posted March 12, 2019 Author Share Posted March 12, 2019 (edited) That is just what ffprobe tells us. I can't imagine this is causing any kind of problem though, right? @@Luke I Direct Play these files and it doesn't seem to be causing any obvious problems. I have no idea if it would impact trans-coding the audio if Emby doesn't know the layout? I've actually just come across some files that were created in a newer version of MKVMerge which do show EAC 5.1 correctly. Also when I rolled back to an old version of MKVMerge and remuxed a file my results still show up a 6 channel. So now I have no idea. For me it's not causing a problem that I've noticed, it's just one of those weird annoying things and it bugs me that I can't figure it out! Thanks Edited March 12, 2019 by Paul77nz Link to comment Share on other sites More sharing options...
Luke 37071 Posted March 12, 2019 Share Posted March 12, 2019 Yea it won't affect any transcoding decision making, so therefore i don't expect it to have much of an impact. Link to comment Share on other sites More sharing options...
Carlo 4330 Posted March 12, 2019 Share Posted March 12, 2019 Paul, I'm a bit curious about something in those files. Any chance you could post text output from Mediainfo for both of those files? Link to comment Share on other sites More sharing options...
Paul77nz 8 Posted March 12, 2019 Author Share Posted March 12, 2019 (edited) @@cayars here you go. Both are EAC3 5.1 MKVs but Emby displays one correctly as 5.1 yet displays the other as 6. EAC3_5.1.txt EAC3_6.txt Edited March 12, 2019 by Paul77nz Link to comment Share on other sites More sharing options...
Carlo 4330 Posted March 12, 2019 Share Posted March 12, 2019 Thanks, Didn't help what I was looking for Link to comment Share on other sites More sharing options...
ebr 14913 Posted March 12, 2019 Share Posted March 12, 2019 The two are actually displaying the media info exactly the same, you are just looking at two different fields for the two different items. Both examples have "channels" listed exactly the same as "6" (which is correct). The only difference is one of them is missing the "layout" field - which is nothing but informational. Link to comment Share on other sites More sharing options...
Paul77nz 8 Posted March 12, 2019 Author Share Posted March 12, 2019 @@ebr I know it's just informational and that the audio format is identical between the two examples, that's exactly why it's so strange. It's also failing to read the bit rate information. Why I'm confused is I can see no difference in the files that would explain why ffprobe can get this information from some files with EAC3 audio but not others. MediaInfo reads both identically as: Bit rate: 640 kb/s Channel(s): 6 channels Channel layout: L R C LFE Ls Rs So the layout and bit rate information is available. I know it's not really a "problem", just an annoyance. Link to comment Share on other sites More sharing options...
Paul77nz 8 Posted March 12, 2019 Author Share Posted March 12, 2019 (edited) @@Luke @@cayars @@ebr So, I've actually been completely wrong as to the cause of this. It's actually related to when the files were added to the library. Any MKVs with 5.1 EAC3 audio added before mid May 2018 displays layout and bit rate info. Any added after early October 2018 don't display this info. If I simply copy an MKV which correctly displays the layout and bit rate, when Emby scans the copy it doesn't show this info. Unfortunately I haven't been able to narrow it down furthur than this, but that date range would indicate the change in behaviour happened in either Emby Server 3.5.2 or 3.5.3. EDIT: OK, so it's an issue with ffprobe v4 and later. v3.2 and 3.4 output: Stream #0:1(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 640 kb/s (default) v4.0.1 and higher output: Stream #0:1(eng): Audio: eac3, 48000 Hz, 6 channels, fltp (default) I guess I need to query the FFMPEG guys about this? Edited March 12, 2019 by Paul77nz 1 Link to comment Share on other sites More sharing options...
Carlo 4330 Posted March 12, 2019 Share Posted March 12, 2019 Yes, Emby is only going to use what's being reported back. This should be the same for consistency sake, so does it also report back 3 channels for 2.1 and 8 channels for 7.1? Link to comment Share on other sites More sharing options...
Paul77nz 8 Posted March 12, 2019 Author Share Posted March 12, 2019 @@cayars it specific to EAC3 and I only have files with 5.1 EAC3. Other audio codecs (AC3, TrueHD, DTS) display correctly as 5.1, 7.1, stereo etc. I can just replace ffprobe in the Emby directory with v3.4 and refresh the metadata - this updates them so Emby displays 5.1. Not a fix, but an acceptable workaround. Link to comment Share on other sites More sharing options...
Carlo 4330 Posted March 12, 2019 Share Posted March 12, 2019 There you go. You just showed that ffmpeg/probe isn't reporting results constantly using different audio codecs. This should be reported. Link to comment Share on other sites More sharing options...
Paul77nz 8 Posted March 12, 2019 Author Share Posted March 12, 2019 I'd best jump on Google and figure out how to report it then! Thanks 1 Link to comment Share on other sites More sharing options...
OddbOd 21 Posted March 22, 2019 Share Posted March 22, 2019 This is definitely an ffmpeg issue, it is not specific to Matroska or EAC3 and is already reported at https://trac.ffmpeg.org/ticket/7601 and https://trac.ffmpeg.org/ticket/7602 Tip: For best results (if you are going to add to the bug reports) use the samples at http://samples.ffmpeg.org/A-codecs/AC3/eac3/ and try to be as clear as possible. This should be the same for consistency sake, so does it also report back 3 channels for 2.1 and 8 channels for 7.1? Indeed, but consistent with what? Codec and container specifications leave a lot of implementation details open to interpretation. As a "simple" AC3 based example, how would you display dual mono (audio coding mode 0)? Perhaps as 1+1 channels like the ATSC spec, or as 1 channel with the language code appended, maybe separate them and use the Ch1, Ch2 nomenclature, or just as 1 channel since despite the fact there are two encoded channels they contain different material. What about this DTS:X sample? Mediainfo has gone from listing the X, MA and Core portions separately in v18.05 to only listing the MA portion in v18.12, which is now consistent with ffmpeg's behaviour. Is that better, worse or just different? Link to comment Share on other sites More sharing options...
Luke 37071 Posted March 22, 2019 Share Posted March 22, 2019 Thanks for pointing out those ffmpeg tickets. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now