Sorry if this has been covered before..

My understanding is that TrueHD has a discrete AC3 core, whereas DTS-MA uses some sort of parametric difference between master and DTS core to store the lossless component of the audio.

I suspect they are pretty much the same, but does anyone know if one of these technologies achieve a higher overall compression ratio than the other?

(I don't have any way of encoding TrueHD/DTS-MA otherwise I'd just do some tests)

Here is a summary from a Japanese Blu-ray that had both.


Total Video
Title Codec Length Movie Size Disc Size Bitrate Bitrate Main Audio Track Secondary Audio Track
----- ------ ------- -------------- -------------- ------- ------- ------------------ ---------------------
The Sky Crawlers AVC 2:02:22 36,415,920,576 37,721,214,416 39.68 32.40 DTS-HD Master 6.1 2179Kbps (48kHz/16-bit) Dolby TrueHD 6.1 1674Kbps (48kHz/16-bit)




DISC INFO:

Disc Title: BDROM
Disc Size: 37,721,214,416 bytes
Protection: AACS
BD-Java: No
BDInfo: 0.5.2

PLAYLIST REPORT:

Name: 00000.MPLS
Size: 36,415,920,576 bytes
Length: 2:02:22 (h:m:s)
Total Bitrate: 39.68 Mbps
Description:

VIDEO:

Codec Bitrate Description
----- ------- -----------
MPEG-4 AVC Video 32400 kbps 1080p / 23.976 fps / 16:9 / High Profile 4.1

AUDIO:

Codec Language Bitrate Description
----- -------- ------- -----------
DTS-HD Master Audio Japanese 2179 kbps 6.1 / 48 kHz / 2179 kbps / 16-bit (DTS Core: 6.1-ES / 48 kHz / 1509 kbps / 16-bit)
Dolby TrueHD Audio Japanese 1674 kbps 6.1 / 48 kHz / 1674 kbps / 16-bit (AC3 Core: 5.1-EX / 48 kHz / 448 kbps)

SUBTITLES:

Codec Language Bitrate Description
----- -------- ------- -----------
Presentation Graphics Japanese 5.708 kbps
Presentation Graphics Japanese 44.681 kbps

FILES:

Name Time In Length Size Total Bitrate
---- ------- ------ ---- -------------
00000.M2TS 0:00:00.000 2:02:08.321 36,396,980,736 39,733
00000.M2TS 2:02:08.321 0:00:14.013 18,939,840 10,812

CHAPTERS:

Number Time In Length Avg Video Rate Max 1-Sec Rate Max 1-Sec Time Max 5-Sec Rate Max 5-Sec Time Max 10Sec Rate Max 10Sec Time Avg Frame Size Max Frame Size Max Frame Time
------ ------- ------ -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- -------------- --------------
1 0:00:00.000 0:05:15.314 30,240 kbps 61,144 kbps 00:01:03.146 40,286 kbps 00:01:24.209 38,737 kbps 00:01:23.833 157,638 bytes 695,341 bytes 00:01:03.188
2 0:05:15.314 0:03:34.255 33,532 kbps 41,643 kbps 00:07:47.717 34,963 kbps 00:05:24.490 34,280 kbps 00:07:32.994 174,819 bytes 711,814 bytes 00:05:28.578
3 0:08:49.570 0:08:16.412 33,540 kbps 44,592 kbps 00:15:10.159 37,439 kbps 00:14:47.094 35,673 kbps 00:15:09.825 174,863 bytes 727,726 bytes 00:16:22.356
4 0:17:05.983 0:02:45.206 33,501 kbps 39,161 kbps 00:18:24.728 34,368 kbps 00:19:12.693 34,030 kbps 00:17:08.736 174,660 bytes 633,850 bytes 00:19:19.366
5 0:19:51.189 0:08:15.244 33,468 kbps 40,857 kbps 00:24:21.585 35,398 kbps 00:27:50.835 34,380 kbps 00:25:08.673 174,488 bytes 754,528 bytes 00:24:15.078
6 0:28:06.434 0:07:40.710 33,250 kbps 40,783 kbps 00:31:56.956 35,111 kbps 00:29:47.952 34,400 kbps 00:29:42.947 173,352 bytes 783,267 bytes 00:30:31.454
7 0:35:47.145 0:05:26.659 33,038 kbps 41,545 kbps 00:35:55.361 35,737 kbps 00:37:38.089 34,444 kbps 00:39:03.883 172,246 bytes 781,119 bytes 00:38:58.127
8 0:41:13.804 0:06:31.265 33,456 kbps 44,776 kbps 00:44:30.125 38,036 kbps 00:44:26.872 35,331 kbps 00:44:26.914 174,422 bytes 781,551 bytes 00:42:58.951
9 0:47:45.070 0:02:23.852 33,187 kbps 38,642 kbps 00:49:31.301 34,949 kbps 00:48:08.677 34,193 kbps 00:48:02.170 173,020 bytes 781,972 bytes 00:48:47.132
10 0:50:08.922 0:03:32.295 33,203 kbps 42,802 kbps 00:50:28.191 35,420 kbps 00:50:24.187 34,363 kbps 00:50:19.266 173,107 bytes 754,567 bytes 00:50:35.782
11 0:53:41.218 0:07:11.222 33,602 kbps 52,696 kbps 01:00:26.873 38,065 kbps 00:53:41.218 36,021 kbps 00:53:41.218 175,186 bytes 714,856 bytes 00:56:59.374
12 1:00:52.440 0:06:42.068 33,453 kbps 40,278 kbps 01:04:23.192 35,626 kbps 01:03:33.017 34,369 kbps 01:04:33.327 174,409 bytes 738,678 bytes 01:04:50.261
13 1:07:34.508 0:03:19.616 33,463 kbps 41,060 kbps 01:09:06.350 34,637 kbps 01:08:11.003 34,255 kbps 01:09:59.695 174,461 bytes 728,455 bytes 01:07:39.889
14 1:10:54.124 0:01:51.444 33,564 kbps 42,305 kbps 01:11:36.250 35,085 kbps 01:11:32.204 34,368 kbps 01:11:27.157 174,986 bytes 527,591 bytes 01:12:45.569
15 1:12:45.569 0:08:16.621 33,543 kbps 48,574 kbps 01:17:50.290 36,392 kbps 01:17:50.207 35,196 kbps 01:17:49.206 174,875 bytes 709,285 bytes 01:13:26.360
16 1:21:02.190 0:04:52.959 33,445 kbps 41,700 kbps 01:22:37.702 36,685 kbps 01:22:35.825 35,206 kbps 01:22:36.618 174,367 bytes 716,723 bytes 01:24:37.864
17 1:25:55.150 0:05:32.540 33,313 kbps 46,347 kbps 01:30:15.576 35,993 kbps 01:30:12.240 35,687 kbps 01:30:06.401 173,677 bytes 644,352 bytes 01:29:36.662
18 1:31:27.690 0:04:56.546 33,111 kbps 39,507 kbps 01:34:12.897 34,875 kbps 01:32:57.280 34,270 kbps 01:35:24.635 172,628 bytes 696,961 bytes 01:31:28.483
19 1:36:24.236 0:03:01.431 33,344 kbps 41,726 kbps 01:36:24.862 36,296 kbps 01:36:24.278 35,091 kbps 01:36:24.236 173,843 bytes 701,155 bytes 01:36:25.029
20 1:39:25.668 0:05:19.610 33,308 kbps 38,715 kbps 01:39:27.127 34,490 kbps 01:41:57.528 34,067 kbps 01:39:27.169 173,652 bytes 603,666 bytes 01:39:30.631
21 1:44:45.279 0:03:27.498 33,432 kbps 51,071 kbps 01:44:45.320 38,681 kbps 01:44:45.278 36,430 kbps 01:44:45.279 174,298 bytes 595,924 bytes 01:46:32.719
22 1:48:12.777 0:05:29.162 33,611 kbps 47,034 kbps 01:52:56.394 37,125 kbps 01:53:19.626 35,098 kbps 01:48:13.069 175,234 bytes 631,048 bytes 01:53:40.939
23 1:53:41.940 0:02:29.023 32,966 kbps 42,074 kbps 01:56:05.500 35,145 kbps 01:56:01.371 34,357 kbps 01:55:56.366 171,869 bytes 660,663 bytes 01:54:30.029
24 1:56:10.964 0:05:57.356 16,746 kbps 57,720 kbps 02:00:23.633 38,976 kbps 02:00:33.476 38,360 kbps 02:00:40.066 87,306 bytes 774,309 bytes 02:02:03.065
25 2:02:08.321 0:00:14.013 16,981,501 kbps 61,144 kbps 00:01:03.146 40,286 kbps 00:01:24.209 38,737 kbps 00:01:23.833 168,662 bytes 783,267 bytes 00:30:31.454

STREAM DIAGNOSTICS:

File PID Type Codec Language Seconds Bitrate Bytes Packets
---- --- ---- ----- -------- -------------- -------------- ------------- -----
00000.M2TS 4113 (0x1011) 0x1B AVC 7342.252 32,401 29,736,751,450 161,716,115
00000.M2TS 4352 (0x1100) 0x83 TrueHD jpn (Japanese) 7342.252 2,122 1,947,430,894 15,429,418
00000.M2TS 4353 (0x1101) 0x86 DTS-HD MA jpn (Japanese) 7342.252 2,179 1,999,438,948 12,011,140
00000.M2TS 4608 (0x1200) 0x90 PGS jpn (Japanese) 7342.252 6 5,239,146 29,593
00000.M2TS 4609 (0x1201) 0x90 PGS jpn (Japanese) 7342.252 45 41,007,814 233,866



It seems Dolby TrueHD is much smaller for the same 48/16 6.1 soundtrack. On the otherhand, the core of dts HD MA is better being 1.5Mbps 6.1 rather than 448kbps 5.1 on the Dolby.

Here is a summary from a Japanese Blu-ray that had both.

It seems Dolby TrueHD is much smaller for the same 48/16 6.1 soundtrack. On the otherhand, the core of dts HD MA is better being 1.5Mbps 6.1 rather than 448kbps 5.1 on the Dolby.

Thanks for the info.. can't really tell from that with THD being 500kbps smaller but the core being 1/3rd the size..

But what a headf*ck.. I can't believe someone would release an audio track in both formats on the same disc!

Now,the audiences might be confused with which one is better?To me,I don't care about the theory that states both codecs is the same but I thought DTS-HD MA was the best for now after more than 200 BDs watched.

Now,the audiences might be confused with which one is better?To me,I don't care about the theory that states both codecs is the same but I thought DTS-HD MA was the best for now after more than 200 BDs watched.

I was only wondering about compression.. just like RAR can compress better than ZIP, which of these two technologies can 'zip' harder.

On a side note I wonder does DTS-MA core technology have any other names? Like TrueHDs compression being called MLP (Meridian Lossless Packing)

After wasting too much time reading bitrate reports I noticed:
16-bit 5.1 TrueHD tracks average 1.5 Mbps while 16-bit DTS-MA tracks average 2 Mbps.
24-bit 5.1 TrueHD tracks average 3 Mbps while 24-bit DTS-MA tracks average 4 Mbps.

The one thing that kills DTS-HD's efficiency is that the bitrate can never go lower than the core bitrate. So that means even for dead quite scenes the bitrate will be 1509kbps with DTS-HD, while with TrueHD it will be 100-300kbps.

After wasting too much time reading bitrate reports I noticed:
16-bit 5.1 TrueHD tracks average 1.5 Mbps while 16-bit DTS-MA tracks average 2 Mbps.
24-bit 5.1 TrueHD tracks average 3 Mbps while 24-bit DTS-MA tracks average 4 Mbps.

The one thing that kills DTS-HD's efficiency is that the bitrate can never go lower than the core bitrate. So that means even for dead quite scenes the bitrate will be 1509kbps with DTS-HD, while with TrueHD it will be 100-300kbps.

Yeah I suppose both the cores are CBR encodes.. So having a discrete AC3 core in TrueHD helps in that regard.

Should've just used FLAC ;)

The one thing that kills DTS-HD's efficiency is that the bitrate can never go lower than the core bitrate. So that means even for dead quite scenes the bitrate will be 1509kbps with DTS-HD, while with TrueHD it will be 100-300kbps.
Is that true? Is there a graph for that anywhere? Not trying to challenge, I've never notice that and am curious about it.

Yeah I suppose both the cores are CBR encodes.. So having a discrete AC3 core in TrueHD helps in that regard.
TrueHD doesn't have a core track, you get TrueHD then you get a secondary "hidden" Dolby Digital 640 track, unless you're playing a Warner disc then you get 448 DD.

DTS is Core + extension.

You can't prove empirically that either lossless codec is superior to the other.

The best thing you can do to test is to go buy U-571 and listen to that track. Then go by Cloverfield and listen to that. Then decide which is more effecient, they both work and the HK studios manage to find space for both lossless tracks.

Best not to worry about it and just pick you're favorite if the disc gives you a choice, until then write Warner and tell them to get TrueHD instructions from Paramount. All other studios(well those are mostly DTS friendly studios, so the fanboy in me is super happy) should keep doing lossless the same way they have been.

TrueHD doesn't have a core track, you get TrueHD then you get a secondary "hidden" Dolby Digital 640 track, unless you're playing a Warner disc then you get 448 DD.

Yes that's what I meant by 'discrete' core. It's still referred to as a core, though the lossless audio data does not depend upon it.

You can't prove empirically that either lossless codec is superior to the other.

Well you can if by "superior" you mean "fits the same data in a smaller space" :P

The best thing you can do to test is to go buy U-571 and listen to that track. Then go by Cloverfield and listen to that. Then decide which is more effecient


Nonono.. I'm not talking about what films soundtrack sounds good, I'm talking about lossless compression technologies.. Actually this started by wondering how TrueHD/DTS-MA stack up against free standards like AAC lossless and FLAC.

It seems Dolby TrueHD is much smaller for the same 48/16 6.1 soundtrack. On the otherhand, the core of dts HD MA is better being 1.5Mbps 6.1 rather than 448kbps 5.1 on the Dolby.
It's worth noting that those two listings are essentially identical since the THD bitrate listing in that example does *not* include the embedded AC3, while the bitrate listing for the DTS-MA track does include its embedded core, so for an apples-to-apples comparison you would need to tack on another 448kbps to the measured THD VBR.

I suppose you could look at it from the perspective that the THD track does not truly require its embedded AC3 rider to be complete ala the basic MLP system, so in that sense THD is somewhat more efficient than DTS-MA in theory. However, then you must consider studios like Warner and Weinstein that wastefully duplicate the embedded AC3 as a separate discrete track for compatibility reasons and then you begin to wonder why we have this mess and why they didn't just use something more sensible along the lines of FLAC.

Actually this started by wondering how TrueHD/DTS-MA stack up against free standards like AAC lossless and FLAC.
Wouldn't FLAC put Dolby and DTS out of business, PCM would too. The studio wouldn't have to pay licensing fees. Damn now I want to know how FLAC would perform on a BD.

Can it do 8ch? sound.

I guess someone would have to encode a studio master in FLAC to actually find out how they compare.

Wouldn't FLAC put Dolby and DTS out of business, PCM would too. The studio wouldn't have to pay licensing fees. Damn now I want to know how FLAC would perform on a BD.

Can it do 8ch? sound.

I guess someone would have to encode a studio master in FLAC to actually find out how they compare.

FLAC does 1-8 channels.. Yeah I don't understand why Dolby and DTS are still around. They obviously have their hooks in good and proper. (Not that they haven't done some outstanding work in the past!)

HD-DVD/BD would have been a lot simpler if only AVC for video and AAC or FLAC for audio were used..

I've 'transferred' a few DTS-MA/TrueHD soundtracks to FLAC, but never kept the original audio stream to compare. Might give it a shot though..

Here's a nice comparison of freely available lossless packers.. Looks like there's a few things that knock the wind out of FLAC.. (Though maybe not in terms of widespread community support)

http://members.home.nl/w.speek/comparison.htm

You get the meta data (dialnorm&DRC) and night mode with Dolby which most of us probably hate. DTS gets the core but you can include that seperately.
BDA probably wanted to avoid any patent disputes. No money in sueing FLAC but with a couple million players out there you would have the BDA by the balls. Remember when Immersion sat on their rumble patent for a decade before asking for money. The studios don't pay for Dolby/DTS so they have no incentive to switch.

Wouldn't FLAC put Dolby and DTS out of business, PCM would too. The studio wouldn't have to pay licensing fees. Damn now I want to know how FLAC would perform on a BD.

Can it do 8ch? sound.

I guess someone would have to encode a studio master in FLAC to actually find out how they compare.

Studios don't pay any encoding licensing fees to Dolby or DTS. Licensing fees are pay for by decoders (the players).;)

As is my understanding:

- Dolby TrueHD is PURELY a lossless codec - there is no lossy version of the audio included in that bitstream. However, TrueHD is an optional codec in the Blu-ray spec, therefore software producers are also expected to include a Dolby Digital track as well. This is likely the reason Warner still end up using 448kbps DD tracks, while Paramount use 640kbps - it's whatever their encoder is set to (Warner probably just recycle the soundtrack from the DVD).

- DTS-MA is both a lossless and lossy codec in one - as with most lossless codecs, what you actually end up with is a lossy "guess", and then a run-length (or otherwise) encoded "error correction".

DTS have gone down the route of using their own DTS lossy core for the "guess" part, and then adding the error correction on top. Dolby probably elected not to use their original lossy algorithm and instead wrote another one (which was incompatible with DD).

It seems Dolby TrueHD is much smaller for the same 48/16 6.1 soundtrack. On the otherhand, the core of dts HD MA is better being 1.5Mbps 6.1 rather than 448kbps 5.1 on the Dolby.

Again...

Why is it better? Because it's 6.1 vs 5.1? And is that center rear discrete or matrixed? (Please see the article from the other thread, where it puts DTS 1.5 mbps closer to being on par with DD 448 kbps)

Didn't mean to be argumentative. Thanks for those stats, they're interesting.

But what a headf*ck.. I can't believe someone would release an audio track in both formats on the same disc!


Complete and utter waste of bandwidth and space. Top Gun BD did the same thing.

The best thing you can do to test is to go buy U-571 and listen to that track. Then go by Cloverfield and listen to that. Then decide which is more effecient, they both work and the HK studios manage to find space for both lossless tracks.

I wouldn't have believed someone could post something like this unless I read it myself.

How will listening to two different LOSSLESS mixes, which by definition provide bit-by-bit identical to their (respective) masters help you decide which codec is more effecient in performing compression?

And not as though posting this article for the millionth time will ever change irrational fanboys' minds:

http://www.hemagazine.com/node/Dolby_TrueHD_DTS-MA_versus_Uncompressed_PCM

...but there you have it. You have absolutely no idea if the lossless and PCM, or the different lossless encodes themselves, came from the same source/mix. And that was to explain why you can't even perform a valid listening test...let alone some "determine a codec's efficiency by listening" test...which is what this thread is about, codec efficiency.

I suppose you could look at it from the perspective that the THD track does not truly require its embedded AC3 rider to be complete ala the basic MLP system, so in that sense THD is somewhat more efficient than DTS-MA in theory. However, then you must consider studios like Warner and Weinstein that wastefully duplicate the embedded AC3 as a separate discrete track for compatibility reasons and then you begin to wonder why we have this mess and why they didn't just use something more sensible along the lines of FLAC.

Are you saying each THD track has AC3 embedded and if you see a separate DD track, that is a duplicate?

From what I understand, THD does not embed any AC3 core at all. BD spec requires a companion DD track or other legacy track for THD because THD support is not required for a player. For the Warner titles you mentioned, they simply let the companion DD track be user selectable or in some cases the default track. There is no duplication as far as I can see.

Now, if only BDA could mandate THD support on all players (which actually is the case in the market now), we could eliminate this companion track non-sense altogether.

Are you saying each THD track has AC3 embedded and if you see a separate DD track, that is a duplicate?That is my understanding as well. The reason for a duplicate is because the embedded DD track cannot be directly accessed (same with the DTS core of a DTS-HD MA track) since it is part of a single bitstream.

And not as though posting this article for the millionth time will ever change irrational fanboys' minds:

http://www.hemagazine.com/node/Dolby_TrueHD_DTS-MA_versus_Uncompressed_PCM

...but there you have it. You have absolutely no idea if the lossless and PCM, or the different lossless encodes themselves, came from the same source/mix. And that was to explain why you can't even perform a valid listening test...let alone some "determine a codec's efficiency by listening" test...which is what this thread is about, codec efficiency.
You're right ILJG I misunderstood the OPs intent.

And of course that article is useless to fanboys... if it wasn't they wouldn't be fanboys.:p

BTW - What do you think the chances are of a modern movie with both a lossless and uncompressed track would take each from a different source or mix?

Are you saying each THD track has AC3 embedded and if you see a separate DD track, that is a duplicate?
Yes, exactly. Each THD stream has an independent AC3 stream interleaved with it on the same stream packet identifier (PID). If an AC3 track also shows up as selectable, then it is a completely separate track with no data shared between the separate track and the embedded track.

In most cases, one would assume this would be a bit-for-bit copy of the embedded AC3, although I suppose there is nothing to prevent it from being different occasionally. I seem to recall that there was a title with a 640kbps AC3 embedded in the THD but the separately selectable AC3 was only at 448kbps (or vice versa), however the name of the title escapes me at the moment.

Yes, exactly. Each THD stream has an independent AC3 stream interleaved with it on the same stream packet identifier (PID). If an AC3 track also shows up as selectable, then it is a completely separate track with no data shared between the separate track and the embedded track.

In most cases, one would assume this would be a bit-for-bit copy of the embedded AC3, although I suppose there is nothing to prevent it from being different occasionally. I seem to recall that there was a title with a 640kbps AC3 embedded in the THD but the separately selectable AC3 was only at 448kbps (or vice versa), however the name of the title escapes me at the moment.

I've never seen that sort of setup on a BD.. usually any other AC3 streams are other languages, or special tracks - like for the blind, with some narrator telling you about what's happening on screen.

Funny that.. the blind would appreciate the resolution of TrueHD the most - but they often just get a 448 DD :P

Though it's certainly possible - I've just never seen it (and I've looked at the layout of quite a few BDs)

Yes, exactly. Each THD stream has an independent AC3 stream interleaved with it on the same stream packet identifier (PID). If an AC3 track also shows up as selectable, then it is a completely separate track with no data shared between the separate track and the embedded track.

In most cases, one would assume this would be a bit-for-bit copy of the embedded AC3, although I suppose there is nothing to prevent it from being different occasionally. I seem to recall that there was a title with a 640kbps AC3 embedded in the THD but the separately selectable AC3 was only at 448kbps (or vice versa), however the name of the title escapes me at the moment.

Then how do you explain DTH without any DD/AC3 at all? Yes, I have a HD DVD disc that contains nothing but DTH, no DD, no DD+.

But what a headf*ck.. I can't believe someone would release an audio track in both formats on the same disc!

Why can't you believe it? What's wrong with doing it? I have a few disks with TrueHD and DTS HD MA. It's fine. It's interesting. It's worthwhile comparing. Why are you so disturbed (headf*ck) by this?

Then how do you explain DTH without any DD/AC3 at all? Yes, I have a HD DVD disc that contains nothing but DTH, no DD, no DD+.

The embedded DD track is only on Blu-ray. The HD DVD tracks are different in that there is no embedded track. It's basically straight MLP on HD DVD>

Why can't you believe it? What's wrong with doing it? I have a few disks with TrueHD and DTS HD MA. It's fine. It's interesting. It's worthwhile comparing. Why are you so disturbed (headf*ck) by this?

Well my initial thought was they put the same audio track on the disc in 2 different formats.. which is pointless.

If they are different tracks, then fair enough.

Then how do you explain DTH without any DD/AC3 at all? Yes, I have a HD DVD disc that contains nothing but DTH, no DD, no DD+.

On HD DVD TrueHD was a mandatory format, all players had to decode it.

Blu-ray TrueHD is optional, so a mandatory track (in this case DD) has to be present on the disc.

I've never seen that sort of setup on a BD.. usually any other AC3 streams are other languages, or special tracks - like for the blind, with some narrator telling you about what's happening on screen
Perhaps this is not as common on Australian releases but, as far as I know, every Warner title released in the US with TrueHD has an extra, redundant main audio Dolby Digital track.

BTW - What do you think the chances are of a modern movie with both a lossless and uncompressed track would take each from a different source or mix?

There actually was a Hong Kong release that had a PCM and a DTS-HD Master Audio track each sourced from a different master.

I don't remember which one it was but Josh Z reviewed it on HDD. He thought the lossy core of the Master Audio track was better than the PCM track on account of the mix.

Here's a nice comparison of freely available lossless packers.. Looks like there's a few things that knock the wind out of FLAC.. (Though maybe not in terms of widespread community support)

http://members.home.nl/w.speek/comparison.htm

that's an outdated comparison... many of the encoders (specifically FLAC) have been updated since 2005

that's an outdated comparison... many of the encoders (specifically FLAC) have been updated since 2005

thanks amish.. shouldve checked the date :|

fuzz.. to answer your original question about efficiency..

Because of the core+extension nature of DTS-HD, the core soundtrack is a complete lossy version of the track (I know that's obvious, but hang with me...)

The lossless extension (called "XLL") is an encoding of the difference between the core and the master... if you listen to the lossless extension on it's own, it sounds like a lot of hash.. it is what the lossy encoder has thrown out.

Due to the nature of the noise, the XLL extension can end up being a bit of a data hog due to the relative difficulty of encoding such low level, highly completely differential signal (my words, and probably not scientifically accurate.....)

To put it another way, it can take a bit more space when you are only encoding low level, highly random "noise" (DTS-HD MA "XLL") than taking a complete picture from the get go (TrueHD aka MLP). :)

But also remember that this discussion is completely separate from the comparison of lossy encoder efficiency, which is a much more important concept.

You get the meta data (dialnorm&DRC) and night mode with Dolby which most of us probably hate.

DTS codecs have dialog norm, just like Dolby's.

fuzz.. to answer your original question about efficiency..

Because of the core+extension nature of DTS-HD, the core soundtrack is a complete lossy version of the track (I know that's obvious, but hang with me...)

The lossless extension (called "XLL") is an encoding of the difference between the core and the master... if you listen to the lossless extension on it's own, it sounds like a lot of hash.. it is what the lossy encoder has thrown out.

Due to the nature of the noise, the XLL extension can end up being a bit of a data hog due to the relative difficulty of encoding such low level, highly completely differential signal (my words, and probably not scientifically accurate.....)

To put it another way, it can take a bit more space when you are only encoding low level, highly random "noise" (DTS-HD MA "XLL") than taking a complete picture from the get go (TrueHD aka MLP). :)

But also remember that this discussion is completely separate from the comparison of lossy encoder efficiency, which is a much more important concept.

yeah that's what i got out of it.. it's actually cheaper to have completely seperate lossy/lossless tracks than store the difference.. especially if the lossy cores are CBR

it's got to be a lot more computationally expensive to work with the difference map (XLL).. so if it's resulting in worse compression, it's working harder to get a worse result.

yeah that's what i got out of it.. it's actually cheaper to have completely seperate lossy/lossless tracks than store the difference.. especially if the lossy cores are CBR

it's got to be a lot more computationally expensive to work with the difference map (XLL)..

It's the reason why several first generation BD players were able to get TrueHD decoding with a firmware update while DTS-HD MA required a new generation of hardware.

It's the reason why several first generation BD players were able to get TrueHD decoding with a firmware update while DTS-HD MA required a new generation of hardware.

aye.. and likely the reason why we have open source TrueHD decoders, but no open source DTS-MA decoders.

i am quickly formulating the opinion that DTS-MA sucks, simply because it is over-engineered and way too needy..

It seems like the hate for DTS is a world wide phenomenon. dts does not suck, your going way over board.

It seems like the hate for DTS is a world wide phenomenon. dts does not suck, your going way over board.

Don't worry.. what you think I'm saying, I'm not saying.. DTS doesn't suck. Only their solution for lossless packing is sub-optimal.

Why are you so disturbed (headf*ck) by this?your going way over boardAn increasing number of people these days apparently find it fashionable to talk in extremes, putting things into only two categories: ROCKS! and SUCKS!, with no shades of gray in between. See some of the discussions in the software sections of the forum.

On HD DVD TrueHD was a mandatory format, all players had to decode it.

Blu-ray TrueHD is optional, so a mandatory track (in this case DD) has to be present on the disc.

I understand that. Which brings to my original question, there is really no AC3 core for TrueHD track at all. It's just how it appears to be on a Blu-ray disc. And on some occasions (i.e. the disc contains TrueHD and PCM, not DD), there is no embedded DD/AC3 either on BD.

Which brings to my original question, there is really no AC3 core for TrueHD track at all. It's just how it appears to be on a Blu-ray disc. And on some occasions (i.e. the disc contains TrueHD and PCM, not DD), there is no embedded DD/AC3 either on BD.It's not a "core", to the extent that the legacy lossy (DD) portion is needed to complete the lossless (TrueHD) soundtrack. But both soundtracks are interleaved into a single bitstream.

As for BD titles that seem to have TrueHD and PCM but no DD, one example that comes up is 'Fifth Element'. However, a poster in another thread confirmed that it does have the DD substream inside the TrueHD bitstream.

The lossless extension (called "XLL") is an encoding of the difference between the core and the master... if you listen to the lossless extension on it's own, it sounds like a lot of hash.. it is what the lossy encoder has thrown out.
I've done something like this for fun once. I encoded a song into MP3, converted it back to PCM, inverted it then subtracted it from the original PCM to see how much difference there was. The subtracted PCM track sounded like a bunch of fuzz, and it was surprising how little data there was in it.

Don't worry.. what you think I'm saying, I'm not saying.. DTS doesn't suck. Only their solution for lossless packing is sub-optimal.

For production houses DTS solution is much better- you encode one file and done. With Dolby you have to do 2 files, make sure that they're in sync and because they're later interleaved, there are issues with cutting/syncing them in authoring software.

Dolby should update their software (also make it cheaper and faster)- so if you do TrueHD track DD track is also generated- such a simple option and would make life much easier.

If you also look at the final product- DTS MA is better- because the lossless part is better quality. If you want to make it smaller, you can always do DTS core at lower bitrate and than overall file size will be tha same or smaller than Dolby TrueHD+DD core.
In my test with music source (5.1 24bit) DTS MA was smaller anyway- even with full quality core. It depends on the source files.


Andrew

For production houses DTS solution is much better- you encode one file and done. With Dolby you have to do 2 files, make sure that they're in sync and because they're later interleaved, there are issues with cutting/syncing them in authoring software.

You're still doing 2 files with DTS, just they are joined at the hip, and subject to errors such as the Disney 6.1 flagging or HD flagging on a MA title like Die Hard 2.


If you also look at the final product- DTS MA is better- because the lossless part is better quality.

Lossless is lossless, period.

Point is that TrueHD is fairly robust and isn't DSP intensive.

Dolby should update their software so if you do TrueHD track DD track is also generated- such a simple option and would make life much easier. When you open a project using Media Encoder, select the target as Blu-ray Disc, and choose TrueHD, it automatically pops open a Dolby Digital window with matching metadata loaded, and you only have to click “submit” and it makes the companion DD file along with the TrueHD file with no further intervention. Is that so hard?

You're still doing 2 files with DTS, just they are joined at the hip, and subject to errors such as the Disney 6.1 flagging or HD flagging on a MA title like Die Hard 2.



Lossless is lossless, period.

Point is that TrueHD is fairly robust and isn't DSP intensive.

It's true- Dolby TrueHD is easier to decode and implement.

No- I'm doing one file with DTS MA :) New technology- so there are errors at the beginning, but I don't think they're going to happen anymore.

Yes- with Dolby I have to setup 2 encodes- why they can't just do it for me- it's not a big update :)

Lossless is lossless- nonsense :)


Andrew

When you open a project using Media Encoder, select the target as Blu-ray Disc, and choose TrueHD, it automatically pops open a Dolby Digital window, and you only have to click “submit” and it makes the companion DD file along with the TrueHD file with no further intervention. Is that so hard?

Since which version ???


Andrew

Lossless is lossless- nonsense :)


Andrew

ahahahaha.. Pure gold my friend :)

Since which version ???
Client version 1.2.5 has this feature and the upgrade is free at
www.dolbysupport.com ;)

I've done something like this for fun once. I encoded a song into MP3, converted it back to PCM, inverted it then subtracted it from the original PCM to see how much difference there was. The subtracted PCM track sounded like a bunch of fuzz, and it was surprising how little data there was in it.

That's a pretty cool experiment.. did you try zipping up the difference?

I'm sure that the DTS-MA method is probably more advanced than that, working with blocks of samples rather than 1 difference value per sample.

I could be wrong! Wouldn't that be funny if it were that simple.

What's really puzzling about this method is how it can truly be lossless at all..

Unless the decoding requirements were incredibly strict, surely one DTS core decoder would come out with *slightly* different data than another? Does anyone know about psycho-accoustic compression/noise shaping and whether or not this is the case?

Client version 1.2.5 has this feature and the upgrade is free at
www.dolbysupport.com ;)

I'm using ME SE verison which is 1.2.1 and it looks like this option is not there.


Andrew

I'm using ME SE verison which is 1.2.1 and it looks like this option is not there. Yes, I presume 1.2.5 is a newer release. Go for the free upgrade. It will make your life easier.

The lossless extension (called "XLL") is an encoding of the difference between the core and the master... if you listen to the lossless extension on it's own, it sounds like a lot of hash.. it is what the lossy encoder has thrown out.




Are you sure that it does work in this way? Do you know this as a fact?
I'm not convinced- as fuzz! pointed it would be quite difficult to achive lossless coding.


Andrew

Yes, I presume 1.2.5 is a newer release. Go for the free upgrade. It will make your life easier.

I've just been there- 1.2.1 is the latest version of ME SE :(


Andrew

That's a pretty cool experiment.. did you try zipping up the difference?

I'm sure that the DTS-MA method is probably more advanced than that, working with blocks of samples rather than 1 difference value per sample. Yes, it is block based. That way you can scan to any point in the file and start playback instantly.

What's really puzzling about this method is how it can truly be lossless at all..

Unless the decoding requirements were incredibly strict, surely one DTS core decoder would come out with *slightly* different data than another? Does anyone know about psycho-accoustic compression and whether or not this is the case? In DTS HDMA decoders, the lossy core is a special "bit-exact" version which outputs the identical data as the reference decoder used in the encoding process. Otherwise, you'd be right--it couldn't be guaranteed as lossless.

...Lossless is lossless- nonsense :)


Andrew

So you are saying that DTS-MA and/or TrueHD are in fact lossy formats? If you have the LPCM master and compare it to the decoded DTS-MA or TrueHD (no meta data or DN) you will see bit for bit identical data streams. Since they will be identical how is that not lossless:confused:

I've just been there- 1.2.1 is the latest version of ME SE :( I am told that if this feature is not yet in the SE version, it will be in the next release. I'll let you know if I get any further info--he is checking.

Mr. Dressler - What's your objective feeling on the 640k DD track versus the 1509k DTS track?

If they came from identical sources and had their levels exactly matched, which would be superior? Why?

Mr. Dressler - What's your objective feeling on the 640k DD track versus the 1509k DTS track?

If they came from identical sources and had their levels exactly matched, which would be superior? Why? Well, my subjective feeling is that neither would be superior to the other. It would take some rather unusual circumstances to identify one from the other in a proper blind test. Having never participated in one of those, this is as far as I can say. The one area where a sound difference can be identified, if the source material tickles it, is in the LFE channel. The DTS encoder rolls it off above 90 Hz, while Dolby's LFE filter can be either 120 Hz or "off" which extends the bandwidth to around 500 Hz. Given identical material with sufficient LFE spectra, some folks hear the difference as "deeper, tighter" bass from DTS. Many would prefer that, even though it's not how the master sounded. This has nothing to do with bitrate or coding quality, however.

So you are saying that DTS-MA and/or TrueHD are in fact lossy formats? If you have the LPCM master and compare it to the decoded DTS-MA or TrueHD (no meta data or DN) you will see bit for bit identical data streams. Since they will be identical how is that not lossless:confused:

Haahahahahahaha- sorry!!!!

Sometimes I read something which is not here.
I've read that as lossy is lossy- heheheheeh:)

Lossless i lossless- perfect sense:)

Lossy is lossy- nonsense

Sometimes you just need a sleep :)

Andrew

That's a pretty cool experiment.. did you try zipping up the difference?
No, but that would have been interesting. This was years ago before I had even heard of lossless audio compressioon. In fact I may have recalled the steps wrong (I don't think I had to invert, only subtract).

I'm sure that the DTS-MA method is probably more advanced than that, working with blocks of samples rather than 1 difference value per sample.
And I did do it per sample, making sure every one was aligned in the two PCM files.

Wait, I just remembered something. I think the subtraction generated some small negative values, as if to get back to the original I needed to cancel out some new sounds in the MP3 file. I did some trick to solve this to make a "playable" PCM file that was just noise. I didn't really know what I was doing.

What's really puzzling about this method is how it can truly be lossless at all..
If you think of audio as just sending numbers to speakers (ignoring the analog aspect of it), it really does make sense. You just want to send the right numbers.

I've just been there- 1.2.1 is the latest version of ME SE I have received confirmation that a new release of SE is coming soon (a month or so), and registered users will be notified. The update is free.

I have received confirmation that a new release of SE is coming soon (a month or so), and registered users will be notified. The update is free.

:)

Andrew

Well I just pulled a DTS-MA track off one BD and the TrueHD track off another and compared the difference in size from PCM..

This is by no means a controlled test, but the TrueHD was ~3% smaller than the DTS-MA...

I would guess that this figure would go up and down depending on the soundtrack, how much silence there was on the LFE and surround channels etc..

It probably also depends on if the "core" DTS track is the 768 kbps variety, or the larger 1.5 mbps. For studios concerned with size, 768 kbps seems more sensible; for studios concerned with backwards compatibility (particularly with people still restricted to SPDIF) the 1.5 mbps core is better.

It probably also depends on if the "core" DTS track is the 768 kbps variety, or the larger 1.5 mbps. For studios concerned with size, 768 kbps seems more sensible; for studios concerned with backwards compatibility (particularly with people still restricted to SPDIF) the 1.5 mbps core is better.

Why are either of those statements true?

With a 768 core, the XLL extension will grow in size.

And 768 is just as backwards compatible as 1509.

Am I missing something here?

well if wavpack's hybrid mode is any indication hybrid lossy/lossless tends to be larger in file size compared to straight lossless a lower bitrate for the lossy part helps a bit

note: DTS-HD MA is not wavpack so results may vary (also note wavpack has had a few updates since i last messed with hybrid mode so results may vary there too)

Why are either of those statements true?

With a 768 core, the XLL extension will grow in size.

And 768 is just as backwards compatible as 1509.

Am I missing something here?
The XLL extension is using (I assume) a more advanced compression algorithm than the 768/1509 kbps algorithm; plus for areas with silence (or other easily compressible sequences) the bitrate can drop to a minimum of 768 instead of constantly being pegged at 1509 because of the "core" track.

To be clear, the former is based on my opinion, but the latter should be indisputable. I'd be curious to see tests done to see if the resulting sizes are as I described (even if only slightly smaller for 768 "core" encodes).

Why are either of those statements true?

With a 768 core, the XLL extension will grow in size.

And 768 is just as backwards compatible as 1509.

Am I missing something here? It is true that as the core bitrate increases, the average lossless extension rate decreases. But it's not a 1:1 relationship. The lossless error signal is still a wideband noise-like signal. Attached is data from DTS showing overall bitrate for 3 lossy core rates.

And 768 is just as backwards compatible as 1509.

I understood that statement to mean that since 1509 is also backwards compatible, it is the preferable option over 768 for studios concerned with providing the best experience to people with legacy equipment.

It is true that as the core bitrate increases, the average lossless extension rate decreases. But it's not a 1:1 relationship. The lossless error signal is still a wideband noise-like signal. Attached is data from DTS showing overall bitrate for 3 lossy core rates.

Thanks for the chart - that's very interesting. I don't know the exact internal mechanics of DTS-HD but it makes intuitive sense that there would be some amount of overhead involved in extended core packets, so a higher core rate would incur a bigger overhead penalty.

With that in mind, it's kind of surprising that more titles are not authored with 768 kbps cores. It does not appear from the chart that the difference is tremendous, but certainly significant - enough to possibly make space for another lossy dub track or several subs at the same overall mux rate.

I understood that statement to mean that since 1509 is also backwards compatible, it is the preferable option over 768 for studios concerned with providing the best experience to people with legacy equipment.
Yes, sorry for the ambiguity. 1509 kbps would provide the best experience for legacy equipment, but of course 768 kbps would be just as compatible.

With that in mind, it's kind of surprising that more titles are not authored with 768 kbps cores. It does not appear from the chart that the difference is tremendous, but certainly significant - enough to possibly make space for another lossy dub track or several subs at the same overall mux rate.
Or with 448 kbps; I was not aware DTS supported a bitrate this low. And it seems the space savings get better still at that low "core" rate. It's unfortunate, in a way, that DTS didn't simply choose to have a completely new codec ala Dolby TrueHD. I wonder how a "coreless" DTS HD MA encode would compare (size wise) against Dolby TrueHD.

Yes, sorry for the ambiguity. 1509 kbps would provide the best experience for legacy equipment, but of course 768 kbps would be just as compatible.


Or with 448 kbps; I was not aware DTS supported a bitrate this low. And it seems the space savings get better still at that low "core" rate. It's unfortunate, in a way, that DTS didn't simply choose to have a completely new codec ala Dolby TrueHD. I wonder how a "coreless" DTS HD MA encode would compare (size wise) against Dolby TrueHD.

There is no such thing as a "coreless" DTS-HD MA encode... it is a technology based on core+extensions, as are most of DTS' offerings.

DTS, as well as Dolby, chose to build off their legacy products to ensure backwards compatibility (remember that Dolby TrueHD tracks will always have a "companion" DD track alongside/interleaved with the lossless encode.)

In regards to 448, you can't use a 448 core with DTS-HD, or even "standard"
DTS, on BR or HD-DVD... 768 is the lowest you can go...

I don't know where Roger's chart came from, but according to DTS, that isn't a supported rate for cores.

In regards to 448, you can't use a 448 core with DTS-HD, or even "standard"
DTS, on BR or HD-DVD... 768 is the lowest you can go...

I don't know where Roger's chart came from, but according to DTS, that isn't a supported rate for cores.

Yep, there's a flash demo here: http://www.dts.com/Pro-Audio_Software/DTS-HD_Master_Audio_Suite/DTS-HD_Master_Audio_Suite_Encoder_Demo.aspx

Core bitrate options are only 1509, 1344, 1152, 960, and 768, but that's for 5.1+

But I have a disc with a 2.0 MA track that has a core bitrate of 512kbps. And another disc with a 1.0 MA track that has a 384kbps core.

There is no such thing as a "coreless" DTS-HD MA encode... it is a technology based on core+extensions, as are most of DTS' offerings.
Yes, I know this. =) I was just wondering aloud about how their lossless packer would have worked in a world without the "core". As the graph seems to show, the lower the bitrate of the core the more efficient the overall codec becomes (due to the strengths of the lossless encoder).

There is no such thing as a "coreless" DTS-HD MA encode... it is a technology based on core+extensions, as are most of DTS' offerings. DTS-HDMA indeed includes a coreless mode, but neither HD DVD nor BD allow its use. The coreless mode yields a slightly lower bitrate than when a DTS lossy core is used. DTS designed their technology with a wide range of features and modes to cover as many bases as possible, but not all were put into use, as we've seen with the 448k core.

DTS, as well as Dolby, chose to build off their legacy products to ensure backwards compatibility (remember that Dolby TrueHD tracks will always have a "companion" DD track alongside/interleaved with the lossless encode.) In the context of BD, this is true. But the companion is not a factor of the TrueHD technology, but of the BD format. In HD DVD, TrueHD needed no companion. Compatibilty was achieved thru other means.

In regards to 448, you can't use a 448 core with DTS-HD, or even "standard" DTS, on BR or HD-DVD... 768 is the lowest you can go...

I don't know where Roger's chart came from, but according to DTS, that isn't a supported rate for cores. Correct. It just illustrates the relationship between core bitrate and total bitrate, as that was the question.

DTS, as well as Dolby, chose to build off their legacy products to ensure backwards compatibility

Totally off topic..

It's amazing the hoops people have to jump through for backwards compatibility.. I've never agreed with it. When DVD came out I was horrified to see 50i/60i where 24p should have been (or better yet variable framerate/resolution - okay maybe asking a bit much there). It should be made the playback devices job to pander to antiquated output methods.

BluRay/HD-DVD shouldn't have given a crap what legacy outputs might still exist. Put the onus on the player.. (ie. If you need SPDIF output buy a player that converts the new formats)

It's the only way to move forward with technology and not overload on complexity with concerns about the past.

Totally off topic..

It's amazing the hoops people have to jump through for backwards compatibility.. I've never agreed with it. When DVD came out I was horrified to see 50i/60i where 24p should have been (or better yet variable framerate/resolution - okay maybe asking a bit much there). It should be made the playback devices job to pander to antiquated output methods.

BluRay/HD-DVD shouldn't have given a crap what legacy outputs might still exist. Put the onus on the player.. (ie. If you need SPDIF output buy a player that converts the new formats)

It's the only way to move forward with technology and not overload on complexity with concerns about the past.

Not to dredge up old discussions, but that is what HD-DVD did.... the lossy codecs weren't mandatory, and the Toshiba players would decode DD+ and True HD, as well as DTS-HD, and re-encode them to DD or DTS for SPDIF.

The BDA took a different approach.

Not to dredge up old discussions, but that is what HD-DVD did.... the lossy codecs weren't mandatory, and the Toshiba players would decode DD+ and True HD, as well as DTS-HD, and re-encode them to DD or DTS for SPDIF.

The BDA took a different approach.

One correction: The Toshiba players would decode DD, DD+, TrueHD, and standard DTS (as well as the "core"), but could not decode either of the DTS-HD extensions. They were probably working on that for a future firmware update, but then the format died.

Not to dredge up old discussions, but that is what HD-DVD did.... the lossy codecs weren't mandatory, and the Toshiba players would decode DD+ and True HD, as well as DTS-HD, and re-encode them to DD or DTS for SPDIF.

The BDA took a different approach.

Although to be fair.. there are times maintaining backwards compatibility has been the mother of some fairly interesting inventions..

Like luma/chroma colour video.. Wouldn't have existed if there wasn't a need to maintain backward compatibility with black&white televisions in the field (and save on thinly allocated bandwidth)

Same with stereo FM broadcasting..

Not to dredge up old discussions, but that is what HD-DVD did.... the lossy codecs weren't mandatory, and the Toshiba players would decode DD+ and True HD, as well as DTS-HD, and re-encode them to DD or DTS for SPDIF.

The BDA took a different approach.

They were mandatory in the fact that all HD DVD players had to decode DD, DD+ and DTS. The discs themselves didn't need to have them if they were TrueHD though.

One correction: The Toshiba players would decode DD, DD+, TrueHD, and standard DTS (as well as the "core"), but could not decode either of the DTS-HD extensions. They were probably working on that for a future firmware update, but then the format died.

DTS-HD MA requires much more DSP horsepower, which is why many gen-1 and 2 BD players could not be upgraded to it, where they could for TrueHD.

They were mandatory in the fact that all HD DVD players had to decode DD, DD+ and DTS. The discs themselves didn't need to have them if they were TrueHD though.


Which was my pont.