I repeat.
Perhaps Plex could consider internally prioritizing (E)AC3 over multichannel AAC when transcoding for “living room” devices?
There are more situations where (E)AC3 can be successfully passed through to the decoding device, while there are more situations where AAC may be 1) transcoded again, or 2) converted to stereo, or 3) fail.
I’m not sure what combination of factors is at play, but Plex already does this for Roku TVs. The TVs advertise support for 5.1 AAC, but they smash it down to stereo. Plex is aware that this occurs and avoids the problem by PMS transcoding to AC3.
1 Like
But what happens if the receiver doesn’t support EAC3 but only AAC. You’d end up with the same issue.
Or if the TV only supports EAC3 for passthrough but then the user doesn’t have a receiver. They would get EAC3 audio that can’t be played.
@ovimax To be clear, are you sure your TV can passthrough EAC3 audio if it receives it? My LG TV can’t but it does have an internal function to output “immersive 3d surround” which is eac3. This seems to always kick in if I enable the feature. If your TV has a similar feature or any other enhancement features, I would try turning it off and see what happens.
Agreed, it would.
But that’s the reason for the suggestion.
I don’t think there are any receivers that support AAC and not AC3.
Passthrough for AAC is really rare, if it exists at all. Is it even possible over ARC? I’d be interested to learn of any TV that ever does AAC passthrough, or any receivers that decode multichannel AAC.
I don’t suggest forcing AC3, only choosing AC3 over AAC if they are both detected.
EAC3 shouldn’t be detected or selected in that configuration.
Is that an issue? I haven’t seen TVs lying about (E)AC3 capabilities. Only AAC. 
I don’t know about that, but almost every one should support 5.1 PCM and TVs should be able to decode 5.1 AAC to 5.1 PCM and send that so it should work without needing another conversion. In this case the TV did say it supported 5.1 AAC, why it chose to transcode to EAC3 instead of passing the AAC or decoding to PCM is unknown. If that setting I mentioned above is enabled, that could be the reason.
Ah! That’s a happy outcome, but it’s only possible with eARC.
Regular ARC is limited to 5.1 AC3 and 2.0 PCM. ARC doesn’t have enough bandwidth for 5.1 PCM.
It’s not untrue that a TV can decode 5.1 AAC, but it’s more likely to result in additional transcoding or downmixing.
In the Living Room, 5.1 AC3 is more likely to preserve all channels, and more likely to avoid additional transcoding.
I force AAC transcoding on my LG by turning off E-AC3 support in the Plex settings so the other way round is possible. This is because I get weird volume fluctuations when transcoding TrueHD->E-AC3.
Why does this menu exist in the first place if the TVs are expected to properly report what formats they support anyway?
I am not aware of a single receiver that will decode multichannel AAC. Doesn’t mean they don’t exist, but… yeah.
1 Like
TV convert E-AC3 to AC3 ,it’s dolby audio CONVERSION
https://i.postimg.cc/rp31tCpH/Annotazione-2020-04-27-100535.png
ARC can be passthrough E-AC3 with ATMOS without any issue, not need eARC.
The prorblem is ARC NOT support AAC.
@zplosion, Can you provide a sample of this occurring over on @ymgenesis’s thread?
Striking volume fluctuation/pulsing artifacts when converting TrueHD 7.1 to EAC3 7.1
1 Like
Yes, please. Plex has acknowledged the issue and would probably benefit from more examples of it in the wild. In general, the codec used and all infos about the file, if possible. Also a short sample about 50ish mb.
1 Like
I’ll get on this at some point this week. IIRC it happens a lot in The Hobbit and The Lord of The Rings.
Is there a reason PMS can’t decode 7.1 channel DTS? Both ffmpeg and EasyAudioEncoder can do it, and if I understand correctly, Plex uses both? under the hood.
EasyAudioEncoder:
I also verified that ffmpeg 5.0 can decode DTSMA 7.1 and transcode straight to eac3:
ffmpeg -i [input] -acodec eac3 -vcodec copy [output]
libavutil 57. 17.100 / 57. 17.100
libavcodec 59. 18.100 / 59. 18.100
libavformat 59. 16.100 / 59. 16.100
libavdevice 59. 4.100 / 59. 4.100
libavfilter 8. 24.100 / 8. 24.100
libswscale 6. 4.100 / 6. 4.100
libswresample 4. 3.100 / 4. 3.100
libpostproc 56. 3.100 / 56. 3.100
...
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (dts (dca) -> eac3 (native))
Press [q] to stop, [?] for help
However, the same command with Plex Transcoder results in
libavutil 56. 63.101 / 56. 63.101
libavcodec 58.117.101 / 58.117.101
libavformat 58. 65.101 / 58. 65.101
libavfilter 7. 96.100 / 7. 96.100
libswscale 5. 8.100 / 5. 8.100
libswresample 3. 8.100 / 3. 8.100
...
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (? (?) -> eac3 (eac3_eae))
Decoder (codec dts) not found for input stream #0:1
So maybe in the (near?) future PMS can update its version of ffmpeg/libavcodec to gain support for DTS 7.1 decode/transcoding?
PMS does support decoding DTS 7.1. Do you have an example where it’s not?
Your post from last year in this thread above:
Has this changed in the last year? I’ve only been able to get PMS to transcode 5.1 of the 7.1 channels in DTS.
Yes, there was a change some time ago that allowed PMS to correctly identify the source audio as 7.1 channels. Check the preplay screen for your video. If it still shows 5.1, you’ll need to re-analyze the file. PMS should transcode these to EAC3 7.1 on support clients.
Then there’s still a bug in PMS somewhere? I have the latest PMS (1.25.8.5663) with a Roku Ultra 2020 connected to a 7.1 amp (this setup plays TrueHD 7.1 files and converts to EAC3 7.1 just fine via Plex).
With the Orchestra Short (Lossless) file here: DTS Trailers - The Digital Theater it identifies as DTS-HD HR 7.1 on the preplay screen, but when played it converts to AC3 5.1 instead of EAC3 7.1.
I also tried DTS HD Out of the Box (long) from the same site which as both DTS-HD MA 7.1 and DTS 5.1 tracks. Despite playing the 7.1 track, PMS still transcoded it to AC3 5.1
