[noggin]

Also worth remembering that France has used DD+/E-AC3 on their digital terrestrial service for a while now - so support for E-AC3 could well be common in DVB TVs that are sold there, and around Europe (and possibly other DVB territories)

[noggin]

The core isn't AC3. It needs to be remuxed/transcoded and will be output as AC3@640kbs AFTER this happening. Dolby licensed hardware will be capable of doing this.

Official Dolby FAQ claims that there is a core and compatibility:

Is Dolby Digital Plus content backward-compatible?
Because Dolby Digital Plus is built on core Dolby Digital technologies, content
that is encoded with Dolby Digital Plus is fully compatible with the millions
of existing home theaters and playback systems worldwide equipped for
Dolby Digital playback. Dolby Digital Plus soundtracks are easily converted
to a 640 kbps Dolby Digital signal without decoding and reencoding, for
output via S/PDIF. The 640 kbps bit rate, which is higher than the standard
448 kbps used on DVDs, is fully compatible with all existing Dolby Digital
decoding products such as A/V receivers, and can provide higher-than-DVD
quality from Dolby Digital Plus soundtracks when played back through
existing systems
source: https://www.dolby.com/uploadedFiles/Asse...us-faq.pdf

640 kbps is also supported on all old S/P-Dif devices, it was just never used on DVDs. But at the beginning of this century the nVidia nForce Mainboards that had the first DD-Live encoders built in (derivatives from the original Microsoft XBOX) were encoding the computers audio in 640 kpbs AC3 streams. Even my 1997 old AV-Receiver was able to decode this Dolby Digital 640 kbps AC3 stream via S/P-Dif (because it was part of the standard).

Swedish broadcaster SVT used to use 640kbps DD on their DVB (both S2 and T I think) broadcasts when they started their SVT HD channel. They have since switched to 448k, but I have quite a few off-air recordings I made with the older higher bitrate 640k stuff around 2010 or possibly a bit before.

[infinity85]

Yeah I think at the end of the day there was simply not enough noticable difference between 448 and 640 kbps. Nice facts, though. Didn't know this about france and SVT!

[Soli]

The FAQ claims no such thing. There is a core which is NOT AC3 and never will be. The core needs to be converted to AC3 by either hardware or software that is Dolby licensed. The 640kbs bitrate is used since this is the maximum AC3 rate and why not, since it's converted on the fly. A high bitrate will also minimize lossy to lossy artifacts. (Even though Dolby say there is no decoding and reencoding..that is probably stretching the truth).

But remember that a 640kbs transcoded steam is not representative of what 640kbs directly converted from a lossless 7.1 soundtrack would sound like. A typical DD+ stream is 192kbs. They can say what they want but that's pretty shite.

Regarding the "640kbs bit", nothing wrong with what you wrote, but it was clearly an answer to something else. I wrote that Dolby licensed products (in the context of DD+) will be able to *transcode* the DD+ Core to AC3, not that you need any special equipment to decode 640kbs.

[infinity85]

This is a real fail then. Just tested a couple of EAC3 samples directly on my TV (no AVR involved). My TV shows always "Dolby Stereo", if playing DD+ content, but no sound comes out (as you said). If I play DD content, TV shows "Dolby Digital".

If I throw TrueHD content onto my TV, this is recognized as "Dolby Stereo" as well, but here it is played successfully (so here the AC3 core is existent). Tested this on a Raspberry Pi2 with the current LibreELEC v7.95.1 BETA.

@wrxtasy
Funny thing... I think I found a bug in the Odroid C2 audio part...
Did a cross check with my C2 and running your 7.1.0 october build there is a issue with Dolby TrueHD: Other than on the Raspberry Pi2, the TrueHD stream is not recognized by my TV at all. It simply shows an empty line for audio info. Obviously it won't output any sound. As mentioned before: Raspberry plays the TrueHD core as "Dolby Digital Stereo".

[noggin]

If I throw TrueHD content onto my TV, this is recognized as "Dolby Stereo" as well, but here it is played successfully (so here the AC3 core is existent). Tested this on a Raspberry Pi2 with the current LibreELEC v7.95.1 BETA.

I believe this is because there is a second 'hidden' Dolby Digital track by default in Blu-ray Dolby True HD tracks (they are considered a single track on Blu-ray players).

Unlike Blu-ray DTS-HD MA/HRA tracks which are based on a DTS Core with a helper signal that reconstructs a lossless result knowing what the core is doing, and require the core as a base, Dolby True HD tracks are entirely self contained and use Meridian Lossless Packing (nothing significantly to do with Dolby Digital AIUI). You could remove the Dolby Digital track and the Dolby True HD would still play fine. (The Dolby 'hidden' track is there for backwards compatibility, just like the core is for DTS)

[infinity85]

If I throw TrueHD content onto my TV, this is recognized as "Dolby Stereo" as well, but here it is played successfully (so here the AC3 core is existent). Tested this on a Raspberry Pi2 with the current LibreELEC v7.95.1 BETA.

I believe this is because there is a second 'hidden' Dolby Digital track by default in Blu-ray Dolby True HD tracks (they are considered a single track on Blu-ray players).

Unlike Blu-ray DTS-HD MA/HRA tracks which are based on a DTS Core with a helper signal that reconstructs a lossless result knowing what the core is doing, and require the core as a base, Dolby True HD tracks are entirely self contained and use Meridian Lossless Packing (nothing significantly to do with Dolby Digital AIUI). You could, theoretically, remove the Dolby Digital track (or part of the track as Blu-rays consider them both a single track) and the Dolby True HD would still play fine. (The Dolby 'hidden' track is there for backwards compatibility, just like the core is for DTS)

sounds logical! I thought TrueHD has a core similar to DTS-HD (built lossless on top of the core).

[wesk05]

A Dolby Digital Plus bit stream has to have at least one independently decodable type 0 or type 2 stream. If it is carrying more than 5.1 channels, the independent substream 0 is actually a 5.1 downmix that can be decoded as such or further downmixed for less than 5.1 channel systems. It will not be incorrect to state that there is no decoding/encoding involved in the conversion of Dolby Digital Plus bit stream to Dolby Digital. This is because the quantinzed mantissa & spectral envelope data from substream 0 is carried over untouched in the conversion process. The changes are in the bit stream info and audio block elements of the syncframe.


@infinity85: Dolby Digital Plus bit stream is not backward compatible with legacy Dolby Digital decoders.

[wrxtasy]

... It will not be incorrect to state that there is no decoding/encoding involved in the conversion of Dolby Digital Plus bit stream to Dolby Digital. ....

Double Tongue tied, with a twist of Lemon if ever I saw a sentence
Ha Ha !

Do you mean to say "it is correct to state that there is no decoding/encoding involved in the conversion of Dolby Digital Plus bit stream to Dolby Digital....." ?

[hansolo]

Well, I have a Samsung 55HU7500 4k non-HDT TV (moninfo shows on audio DTS, DD, DD+ supported formats), a HDMI 1.4 receiver (Yamaha HTR-4066) bluray player LG BP740, Himedia Q5IV.
After this thread i did some tests.
TV outputs to HDMI-ARC surround sound DD from internal Netflix app (not DD+), DD or DTS from internal player (DTS-HD Master downconvert to DTS 5.1, truehd is not supported).
TV outputs to HDMI-ARC stereo/PCM sound from any HDMI source (BR player set as RAW bitstream).
BR player outputs direct to receiver all surrounds formats, including DD+ from Netflix.

Questions: I want to buy a 2017 Shield, mainly for movies but also for games (I also have a new desktop with Gamestream capable Nvidia 1060 card).
Question: can in have Gamestream video (aka 1080p or 4k RGB format) and surround sound? For that I need a splitter, one HDMI 2.0 to carry video to TV and another HDMI 1.4 to carry surround sound to receiver. Are any tested splitters that do that?
Thanks!

[Soli]

Yes, the transcoding process from DD+ to DD is quite elegant, and without involving end-to-end decoding/recompression (supposedly they call it hybrid recompression), but it's not totally distortion and artifact free so it's only logical to transcode to the highest bitrate the AC3 standard allows.

I take it that the Shield is not licensed and hence cannot transcode DD+ to AC3. Well, that is a big slip up.
But AFAIK Netflix does include native AC3 to some clients (players, not customers). If I'm not mistaken, both the Windows client , and WDTV Streaming G3 utilize that. And probably numerous Smart TV's as well, if the TV is not Dolby licensed. (to be able to output the bitstream over it's toslink output). They should have done the same for the Shield. Maybe if you bug Nvidia enough, they'll talk to Netflix about it.

[wrxtasy]

Well then nVIDIA need to bug Amazon Video and VUDU as well and likely others streaming with DD+
The question is where does the bugging and pleading stop ?

[Soli]

In my view, it (the Shield including all apps) should have defaulted to native AC3 since DD+ isn't supported. It's in the best interests of all parties involved to sort this out.

Then again, Nvidia should have this sorted from the get go. I mean, you make the worlds most powerful media player (in it's class), you make it futureproof by including HDMI 2.0(x), H265 decoding and encoding (as used by Plex Media Server), but in the end you f... it all up by not licensing Dolby/DTS.

[noggin]

A Dolby Digital Plus bit stream has to have at least one independently decodable type 0 or type 2 stream. If it is carrying more than 5.1 channels, the independent substream 0 is actually a 5.1 downmix that can be decoded as such or further downmixed for less than 5.1 channel systems. It will not be incorrect to state that there is no decoding/encoding involved in the conversion of Dolby Digital Plus bit stream to Dolby Digital. This is because the quantinzed mantissa & spectral envelope data from substream 0 is carried over untouched in the conversion process. The changes are in the bit stream info and audio block elements of the syncframe.


@infinity85: Dolby Digital Plus bit stream is not backward compatible with legacy Dolby Digital decoders.

When discussing types - are you referring to this ? https://www.dolby.com/us/en/professional...dard-b.pdf Particularly

E2.3.1.1 strmtyp: Stream Type, 2 bits
This 2-bit code, as shown in Table E2.7, indicates the stream type. Table E2.7 Stream Type
The stream types are defined as follows:
Type 0: These frames comprise an independent stream or substream. The program may be decoded independently of any other substreams that might exist in the bit stream.
Type 1: These frames comprise a dependent substream. The program must be decoded in conjunction with the independent substream with which it is associated.
Type 2: These frames comprise an independent stream or substream that was previously coded in AC-3. Type 2 streams must be independently decodable, and may not have any dependent streams associated with them.

If my quick reading is correct :

7.1 E-AC3 streams will contain a Type 0 (carrying a 5.1 stream) and a Type 1 (carrying the additional channels require for 7.1)?
5.1 E-AC3 streams could be Type 0 (carrying a 5.1 E-AC3 stream) or Type 2 (carrying a 5.1 AC3 stream)?

This means that a 5.1 E-AC3 stream COULD be simply a re-wrapped AC3 stream flagged as E-AC3 Type 2. This bitstream, fed natively, wouldn't make sense to an AC3-only device, but an intermediate device could simply re-wrap the E-AC3 stream with AC3 encoded data into an AC3 native bitstream? This wouldn't require decoding or transcoding, just a rewrap or similar of the stream?

What does this mean for a 5.1 E-AC3 Type 0 stream - which presumably is NOT AC3 encoded data?

However in all cases, you aren't simply passing through a bitstream, you are at the least re-wrapping content based on Dolby specific data, which presumably could be a licensable task? (It's not data that is part of a parent standard you may already have licensed, like MPEG2 transport stream decoding etc.)

[Soli]

You are right, and you presume right.
DD+ that are 7.1 channels are effectively 5.1 + 4 channels. Prolly why Netflix is limited to 5.1 (although feel free to google it), since they insist on using 192kbs (try squeezing 5.1+4 channels into 192kbs.. Ugh)