Ooh, that’s a very good point! I hadn’t thought about that before, because I have a faint memory of having once tested this on a Pi (under Kodi 17) and it working correctly… but I may be remembering that wrong. In any case, testing it just now, it definitely suffers from exactly the same problem as the Vero.
And it’s a lot more serious on a Pi, because the Pi can’t ever use pass-through on DTS-HD - the option isn’t even visible in the system settings. Everyone using a Pi effectively has the “pass-through DTS-HD” box unchecked.
So, every person who is running OSMC on a Pi and has checked the option to pass through DTS has unknowingly disabled DTS-HD soundtracks in the process. I wonder how many people have done that?
That seems a lot more serious to me than the Vero case. I think you need an actual warning message in the UI not to enable DTS pass-through if it’s going to work like that: a note in the wiki is not adequate.
This is a horrible example. Unless you have mediainfo showing that Netflix uses E-AC3 to encapsulate both an independent substream and a dependent legacy (AC-3) substream, any “fallback” you see is actually an on-the-fly re-encode by the device, or a completely separate audio track.
Another bad example, since the channel count would tell you in most cases (DTS can only output 5.1), and you won’t be able to hear the difference for a 5.1 DTS vs. DTS-HD MA track. You might think you can, but double blind tests say you can’t.
Note, too, that these examples assume an AVR that can decode lossless/advanced formats, but passthrough for lossless has been disabled intentionally by the user. This is not the setup the OSMC wiki recommends, so why are you complaining that OSMC developers need to fix something that is, essentially, user error?
Then, address this to the Kodi developers, since this affects all platforms. The behavior is identical on a PC running Kodi with HDMI output and the same settings. OSMC developers don’t need to spend their time fixing a core Kodi issue, especially when it is a tiny corner case (devices that have HDMI input that supports 4K and can’t decode lossless audio are very rare) and can be fixed by disabling passthrough completely.
This also happens with LibreElec, or any other OS you can install on the Pi and then run Kodi. That’s because it a Kodi settings issue, and not specific to OSMC. Go complain about it on the Kodi forums, and make sure you demand they fix it right away.
Kodi 20 landed on my nVidia Shield today, and I noticed that the passthrough audio settings now have a sub-option on DTS-HD for enable/disable the DTS core. I’ve not tracked down anything on this in release notes, but I am intrigued - i.e. if passthrough of DTS-HD is enabled, what is the purpose of this sub-option - to ensure that the DTS core is stripped out, in which case has “pass through” so far been compromised, and to fully enjoy my DTS-HD tracks, I’ve been missing out with DTS passthrough switched on?
Having tinkered with the new settings I see the logic in the behaviour: if DTS-HD passthrough is enabled, there is no sub-option. But if DTS-HD passthrough is disabled, a sub-option appears to use DTS core yes/no. Presumably that ensures PCM decode of the DTS-HD stream if desired rather than passthrough of the lossy DTS core, while allowing passthrough of DTS for non-HD sources.
From reading that commit, it seems - yes! That was the OP complaint 3 years ago. I don’t think OSMC currently does anything different from stock Kodi in that respect. We’ll check that option is available when we bring up Nexus.
BTW I don’t see that option with Nexus on Win 11. I can’t select passthrough at all. Maybe it knows my monitor is DVI even though it’s through a HDMI socket.
Yeah, it sounds like this is exactly the change I was originally suggesting (and that @nabsltd felt the need to viciously insult me for supporting): as it stands now, if you disable pass-through for DTS-HD but enable it for DTS, then it will ignore the DTS-HD track entirely and pass through the DTS core instead.
On the Vero 4K that often makes sense - it’s not all that common to have an audio device that supports 5.1 or 7.1 PCM, but not DTS-HD; so usually either you’d enable DTS-HD pass-through, or the sound device can’t handle multi-channel PCM anyway, in which case passing through the core DTS track is your best option. But if the audio device actually does support multichannel PCM and not DTS-HD then you’re compromising sound quality, probably without realising.
It’s much more of an issue on the Pi 2 and 3, because they don’t support DTS-HD pass-through; so, even if your audio device does support DTS-HD, if you switch on DTS pass-through then you are losing HD audio on all your DTS-HD recordings.
The work-around is simple enough, of course - just disable DTS pass-through. But the problem is that most users don’t know you need to do that!
I’m glad they’ve finally changed this, although I’m not sure if this will help in the Pi 2/3 case, as the DTS-HD pass-through control isn’t actually present there. It’ll be interesting to see how that works (if there even is a Pi 2/3 Nexus release!).
A DTS core of 1.5mbs is already transparent. Even if you home cinema costs 1M$. So for all intents and purposes this thread has no real purpose. Don’t mean it in a derogatory way, I’m just saying.
Yeah, you did mean it in a derogatory way. You’re also plain wrong. The core track can’t be more than 5.1, but the DTS-HD track could be 7.1, in which case you’re missing two entire speakers’ worth of data.
I have a fully DTS-HD MA X / Dolby TrueHD Atmos compatible setup so this doesn’t affect me at all, but I totally understand why this would be troubling for someone who has a setup limited to DD/DTS.
And it made me think about how annoying it is that I have to untick the DTS core box every time I do a rip with MakeMKV.
Why would I want to store the lossy DTS core in the MKV as a separate track when the core is in the DTS-HD MA?
But for those who do not have a lossless audio setup, MakeMKV putting the DTS core as a separate track makes a bunch of sense now.
I still think that audio passthrough should work the way every thinks it should but since DTS-HD MA has a real core and TrueHD doesn’t I have to imagine that makes it tricky for the player (but not necessarily impossible).
But if you have MakeMKV rip your DTS core as a separate track I have to imagine it resolves this issue.
Well, yeah: obviously if your TV or AVR supports DTS but not DTS-HD or multi-channel PCM, then you want to pass through DTS! There are a heck of a lot of people still using optical connections for audio, which puts them in precisely that position.
That’s not what this thread was originally about, of course. My original use-case was a rather niche one: my audio device supported DTS and 7.1 channel PCM, but not DTS-HD pass-through. It therefore made sense to pass through DTS if nothing better was available, but to decode DTS-HD to PCM if there was a DTS-HD track available. Prior to Kodi v20 there was no way to do that; and (more importantly) the behaviour if you opted to pass through DTS but not DTS-HD was extremely counter-intuitive: if you told it to play a DTS-HD track it would ignore that and pass through the DTS core instead (meaning you ended up with lower-quality 5.1 sound instead of higher-quality 7.1).
This was particularly a problem on the Raspberry Pi (up to model 3): they don’t have DTS-HD pass-through as an option; so if you ticked the box to pass through DTS you were actually disabling DTS-HD playback, and there was no indication in the UI that it was doing that - and that applied even if your AVR did actually support DTS-HD. So a lot of Pi users were affected by this (many of them without knowing about it, probably).
Happily, all of this has now been resolved with an extra UI option in Kodi v20: now, if you choose to disable DTS-HD pass-through, you have a choice as to whether to decode DTS-HD to PCM or to pass through the core DTS track, which is exactly what was needed.
