eac3to - audio conversion tool

[jruggle]

Read '>' like 'better quality than':
AC3 640 > DTS 1536 > AC3 448 > DTS 768


The same guy (Justin Ruggles) wrote Aften and ac3 code in ffmpeg, but Aften have more options to tune the encode.

That is not true. Though I am listed as the current maintainer of it, I did not write the AC3 encoder in FFmpeg. It was written by Fabrice, who started FFmpeg. I used his code as the starting point for Aften. The original FFmpeg AC3 encoder has not changed much since it was first written. I made a few tweaks and some speed improvements, but nothing significant.

So are they equally up to date? In other words, if I'm doing 5.1 ac3 without settings anything other than the bitrate, is there any reason to chose one over the other?
FFmpeg is a simpler encoder than Aften. It only allows 16-bit input, and it uses 16-bit fixed-point for the MDCT and other calculations. It does not have any options other than bit rate and frequency cutoff. Aften allows higher resolution input such as 24-bit and floating-point, it uses floating-point calculations internally, and it has many options. Aften is also multi-threaded.

That said, the quality is not significantly different. There is only so much you can do with the format. The core encoding features are basically the same, the 2 encoders just use different algorithms in several places.

[jruggle]

So what do you guys think... should I use aften and tweak bandwidth or is it a bad idea?
The only downside of increasing the bandwidth is that the encoder has to spread the available bits across more frequency coefficients, so it can decrease overall quality.

[tebasuna51]

That is not true. Though I am listed as the current maintainer of it, I did not write the AC3 encoder in FFmpeg... I made a few tweaks and some speed improvements, but nothing significant...

Sorry, my fault. I was thinking your tweaks like current maintainer was more important.

[Abradoks]

I have recently made an objective comparison between proprietary Dolby encoders and aften. Aften has much worse SNR than DD. Even 224 kbps AC3 encoded with DD beats aften 448 kbps in SNR. When using PEAQ metric aften is closer to DD, but still worse. :(
Also, if you want to have frequency cutoff similar to DD encoders, you should use w=48 for 448 kbps and w=8 for 224 kbps. This tweak gives a little worse SNR but better PEAQ on 448 kbps (w=8 gives worse PEAQ than default settings).
If somebody is interested, I can repost here that comparison. But, it seems that development of AC3 encoders is dead.

[tebasuna51]

...
If somebody is interested, I can repost here that comparison. But, it seems that development of AC3 encoders is dead.
Two post before you have jruggle the Aften developper.

Maybe he need some support to improve the encoder, everybody is interested in a good free ac3 encoder.

But, please, use the Aften thread (http://forum.doom9.org/showthread.php?p=1341620#post1341620) for this.

[shon3i]

When using PEAQ metric aften is closer to DD, but still worse.Nothing than usual ABX comparing is not optimal for making decision which encoder is better, none of methods PEAQ or Spectogram like MokrySedeS posted. Because encoder made decision to cutoff certain frequency range to keep overall quality. That means audio still can be transparent to source, but if you look at spectogram and see that something missing, because forcing to not cutoff (leave frequency range) is not good.

Many people here have a bad decision, rather than listen, they watch the some values and graphs, which is completly wrong.

[Terrachild]

Abradoks,

very interesting.
Could you tell me what commercial encoder you tested. (Surcode?)

How did you measure signal to noise ratio, is there a free program you can point me to that can do that? What about measuring PEAQ?

You said use W=8, what setting is that. Im using "WAV to AC3 Encoder 4.1" where is that setting?

Thanks

[raziel666]

I have a certain DTS-MA audio track from a bluray disc of mine and I want to compress it to FLAC.

I own Sonic Cinemaster Audio Decoder 4.3 and have installed the .dll's of ArcSoft using the trial version as described in other posts in doom9.

Now the problem is this: when trying to encode to FLAC, the ArcSoft decoder gives a file twice the size of that from the Sonic Audio Decoder.

After examining the files with MediaInfo, I found out that the bitrate varied between these two decoders. The ArcSoft one produced a file with 2833kbps and the Sonic one with 1631kbps. Moreover, the file produced with ArcSoft is supposedly 14 minutes longer than the original duration and when I tried to play it back, it sounded slowed down and like crap... :(

Am I doing something wrong? Is it some bug that one of the decoders has?

Thanks in advance for your answers.

[rapscallion]

It's a True-HD Blu-ray track and I'm trying to create lossless wavs. (using eac3to_more) and I'm running into a strange problem.

First, when I create wavs, from a regular AC-3 track, Nero decoder (direct show) does the processing and maintains 24 bit.

However, when I try to do this to the HD track, ffmpeg/Libav somehow does the decoding and after the first pass Libav reports superfluouus zero bytes, eliminates them and drops down to 16 bits.

Is there a way create lossless wavs, maintaining 24bit, from True-HD ?

[Inspector.Gadget]

If eac3to using LAVC says a lossless codec is actually 16-bit, it is. 24-bit decoding for a lossy format like AC3 makes sense because presumably you're going to transcode it later and the additional accuracy is desirable.

[rapscallion]

Yes, however, at the first pass it's reported as 24 bit. And, as I stated, libav is dropping it down from 24 to 16 bit, NOT reporting that it originally is.
What is lavc btw, or did you mean libav?

My goal is to re encode the wavs to DTS-MA.

[Inspector.Gadget]

LAVC = libavcodec. The first pass calls it 24 bit because eac3to has to make sure that the 8 bits of padding lasts the length of the file and there's no actual 24-bit content in there. Once eac3to has verified this, it can discard the padding during decoding.

[rapscallion]

Ok, thanks, I got it now....just two last questions.

Is Nero docoder (from ver 7.10.1) not able to decode TrueHD and that's why eac3to is choosing libav/ffmpeg ?

When I re encode to DTS-MA will the resulting track be back to 24 bit or does it even matter ?

[Abradoks]

I have posted (http://forum.doom9.org/showthread.php?p=1341798#post1341798) comparison in aften thread.

Nothing than usual ABX comparing is not optimal for making decision which encoder is better, none of methods PEAQ or Spectogram like MokrySedeS posted. Because encoder made decision to cutoff certain frequency range to keep overall quality. That means audio still can be transparent to source, but if you look at spectogram and see that something missing, because forcing to not cutoff (leave frequency range) is not good.

Many people here have a bad decision, rather than listen, they watch the some values and graphs, which is completly wrong.
I'm not going to argue about subjective vs. objective tests. If you have enough resources to make ABX comparison, it'll be very interesting to see how they correlate with SNR and PEAQ.
Besides, my tests were started because somebody reported bad listening quality of AC3 track encoded with aften compared to DD encoder. It was suggested that default frequency cutoff causes such effect.

You said use W=8, what setting is that. Im using "WAV to AC3 Encoder 4.1" where is that setting?
You can control encoded frequency range through commandline option "-w" when using aften. I don't know if any GUI can do this.
You can find information about used encoders and measurement tools in the post I linked.

[Inspector.Gadget]

Is Nero docoder (from ver 7.10.1) not able to decode TrueHD and that's why eac3to is choosing libav/ffmpeg ?


I'm not sure, but both Nero and LAVC can decode TrueHD (the MLP part, which is what you're after) bit-perfect.

When I re encode to DTS-MA will the resulting track be back to 24 bit or does it even matter ?

If you're using the DTS HD Encoder Suite, then it will remain 16 bit. I'm not sure what Surcode would do.

[rapscallion]

OK, thanks IG.....and yes DTS MA Suite to encode.

Edit: Both DTS-MA and Surcode encodes result in 16 bit depth.

[TinTime]

I'm not sure, but both Nero and LAVC can decode TrueHD (the MLP part, which is what you're after) bit-perfect.

Nero's limited to 5.1 output though which is why eac3to uses libavcodec by default.

[rapscallion]

If eac3to using LAVC says a lossless codec is actually 16-bit, it is. 24-bit decoding for a lossy format like AC3 makes sense because presumably you're going to transcode it later and the additional accuracy is desirable.

Well, not only are you exactly right, but I found this info, for the audio track I'm processing, on Blu-raystats.com :

Run -Time2h 32m 13s
Language -English
Disc Language -English
Video -1080p 2.35:1
Video Encoding -VC-1 24 Mbps
Audio- Dolby True HD 5.1 16 bits 48 kHz 1505 kbps
Secondary Audio -DD AC3 5.1 640Kbps
Disc- BD50 40.72 GB
Region- A, B, C

I always thought that both DTS-MA and DDTrueHD were 24 bit. Live and learn.

[rapscallion]

Ok guys, I've been playing around with this and now I'm a bit confused.

First time extracting TrueHD to 6 wav files via eac3to_more.

When I do this directly, 2 passes are made, resulting in wav files that are ~800,000KB ea/16bit.

However ,if I process the TrueHD to an AC-3 file and THEN process the AC-3 to wav files, the size of the wavs are ~1,285,000KB ea/24bit.

My reasoning is that the larger wavs are lossless and I can use them to create a DTS-MA audio track ? And I don't know what the smaller wav files are (the 2 pass process) ??

Any explanation would be greatly appreciated.

Another question is, when creating the DTS file should the rear channels (5.1) be attenuated to -3db or should that be left alone ? From what I've read movie theater tracks are boosted by 3db for the rears so theaters then attenuate them by the same. But BD tracks are not boosted, so should be left alone? Is that correct ?

My head hurts !

[nurbs]

TrueHD is a lossless codec that will give you the same output as the source. Lossy codecs like AC-3 and AAC don't store the information at a fixed bitdepth, so you can either decode them to 16 bit or 24 bit. Since the latter is a more accurate representation of the files content eac3to will do that by default.

[rapscallion]

Thanks, I understand that but it doesn't answer my questions re the wav files. Which processing gave me the lossless wavs?

[nurbs]

Both of them in a way. If you decode the TrueHD you get exactly what was in it. If you decode the AC-3 you might not get exactly what's in it (assuming they can be decoded to an arbitrary bitdepth), but 24 bit is close enough as in no audible difference from the source.
Of course if you encoded the AC-3 from the TrueHD there is a loss during the AC-3 encoding.

[Inspector.Gadget]

If you're making a DTS-HD MA track, the you should ONLY go TrueHD -> WAVs -> DTS Encoder. Going TrueHD -> AC3-> WAVs-> DTS encoder is converting lossy to lossless whether you re-encode or take the TrueHD core, because either way you're discarding the lossless MLP data.

[rapscallion]

......which is the logic I was using from the start. Thanks.

However, what really puzzles me here are the substantially smaller wav files (and DTS-MA files- 2.5gb vs 3.8gb) when going from TrueHD -> WAVs -> DTS Encoder, then when going TrueHD -> AC3-> WAVs-> DTS encoder.

Logically, I would think all the files would be larger in the first lossless option. Additionally, the first option results in 16 bit wavs, the second in 24 bit. I think you guys can appreciate my reasoning, even if it's way off base.

From what you're saying, I should also use the first option if I want to just create a straight, non HD, DTS track @1536 ?

[Inspector.Gadget]

24-bit PCM (16 bit + 8 bits padding) is generated by decoding AC3 to 24 bit, for no quality gain (and in this case, quality loss versus MLP to WAV). Decoding straight to WAVs nets you only the real 16-bit data.

From what you're saying, I should also use the first option if I want to just create a straight, non HD, DTS track @1536 ?

Yes. Original to lossless to lossy is preferable to original to lossy to lossy.

[nurbs]

From what you're saying, I should also use the first option if I want to just create a straight, non HD, DTS track @1536 ? You should always use the first option.

About the filesize. IIRC wav filesize is simply bitdepth * sampling rate * duration, so with the same duration and sampling rate a 24 bit file is 50% larger than a 16 bit file. 0.8 GB *1.5 = 1.2 GB


24-bit PCM (16 bit + 8 bits padding)
AFAIK it's not padding, it's actual information, insofar as the 24 bit file is a more accurate representation of the AC-3 file than a 16-bit wav would be even if the source of the AC-3 was only 16 bit. Of course it probably won't make much difference.

[Thunderbolt8]

as it seems eac3to cannot remove gaps from truehd tracks, but for example it can do so when I convert the original truehd track from a movie BD to flac. but when I demux the truehd track and then convert it to flac afterwards, then the gap message suddenly disappeares. does this mean that the gap remains undetected here and untreated?

[honai]

as it seems eac3to cannot remove gaps from truehd tracks, but for example it can do so when I convert the original truehd track from a movie BD to flac. but when I demux the truehd track and then convert it to flac afterwards, then the gap message suddenly disappeares. does this mean that the gap remains undetected here and untreated?

Yes, gap detection means that eac3to looks for audio gaps in relation to the video stream (i.e. container timecodes), so once you demux audio there is no reference video stream (i.e. container timecodes) anymore.

[rapscallion]

In case you all missed this last question in an earlier post today :

"Another question is, when encoding a DTS file should the rear channels (5.1) be attenuated to -3db or should that be left alone (unchecked) ? From what I've read movie theater tracks are boosted by 3db for the rears so theaters then attenuate them by the same. But BD tracks are not boosted, so should be left alone? Is that correct ?"

Edit : Found this in the Surcde (which I don't use) manual :
7.2
The Attenuate Rear Channels 3 dB Option

The original standard for Surround Sound in movie theaters was to attenuate
the rear channels by 3 dB.

So, in mixing for theaters, studios have their rear channel monitors attenuated 3 dB.

Home theaters, on the other hand, have the rear channels at unity gain.
So, a mix that was made with the rear monitors attenuated 3 dB will
have rear channel levels that are 3 dB too high for home theater.

This option takes care of that difference. So, in general, you use this option
if creating a DVD-Video using a Surround master that was originally mixed for movie theaters

So, for tracks from BD discs everyone leaves the -3db option unchecked, right ?

[Snowknight26]

eac3to incorrectly reports the resolution for one of the playlists on a Blu-ray of mine:

C:\unzipped\eac3to>eac3to.exe E: 1)
M2TS, 2 video tracks, 8 audio tracks, 4 subtitle tracks, 1:36:07, 112.806p
1: Chapters, 35 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: h264/AVC, 480p24 /1.001 (20:11)
4: DTS Master Audio, English, 5.1 channels, 24 bits, 48khz
(core: DTS-ES, 5.1 channels, 24 bits, 1509kbps, 48khz)
5: DTS Master Audio, English, 2.0 channels, 24 bits, 48khz
(core: DTS, 2.0 channels, 24 bits, 1509kbps, 48khz)
6: AC3 Surround, English, 2.0 channels, 192kbps, 48khz
7: AC3 EX, French, 5.1 channels, 640kbps, 48khz
8: AC3 EX, Spanish, 5.1 channels, 640kbps, 48khz
9: AC3 Surround, English, 2.0 channels, 192kbps, 48khz
10: AC3 Surround, French, 2.0 channels, 192kbps, 48khz
11: AC3 Surround, Spanish, 2.0 channels, 192kbps, 48khz
12: Subtitle (PGS), English
13: Subtitle (PGS), French
14: Subtitle (PGS), Spanish
15: Subtitle (PGS), English

[honai]

Is that some CGI movie from Pixar?

[Snowknight26]

It is. Seamlessly branched, too.

[Abradoks]

When decoding dts through libav I get pcm that should have gain factor of 1.0605 to match the source. While arcsoft decoder creates proper wavs. Is it known issue?

[honai]

It is. Seamlessly branched, too.

Then take a look at the last few lines after muxing, eac3to 3.17 should be reporting the correct fps there, nothing to worry about.

[honai]

When decoding dts through libav I get pcm that should have gain factor of 1.0605 to match the source. While arcsoft decoder creates proper wavs. Is it known issue?

I believe you are the first to mention this.

[Thunderbolt8]

Yes, gap detection means that eac3to looks for audio gaps in relation to the video stream (i.e. container timecodes), so once you demux audio there is no reference video stream (i.e. container timecodes) anymore.is there any chance to save a gap file which then can be used when I process only the audio track alone later on?

[Snowknight26]

Then take a look at the last few lines after muxing, eac3to 3.17 should be reporting the correct fps there, nothing to worry about.

A cosmetic issue is still an issue.

[tebasuna51]

When decoding dts through libav I get pcm that should have gain factor of 1.0605 to match the source. While arcsoft decoder creates proper wavs. Is it known issue?
Welcome to lossy encoders/decoders.
Yes it is know, to avoid overflows, when convert from frequency domain to time domain, many decoders attenuate a little bit the output.

You can use the -normalize parameter if you want.
And, of course, the use of ArcSoft decoder is always recommended.

Decoding ac3 sometimes eac3to detect overflows and make a second pass attenuating the signal.

[Thunderbolt8]

as it seems eac3to cannot remove gaps from truehd tracks, but for example it can do so when I convert the original truehd track from a movie BD to flac. but when I demux the truehd track and then convert it to flac afterwards, then the gap message suddenly disappeares. does this mean that the gap remains undetected here and untreated?
for some strange reason the subtitle file for this movie is about 4 seconds out of sync after remuxing. the movie consists of 2 m2ts files, the first one only being 7-8 seconds long. still, no apparent relation to those 4 seconds of subtitle delay. the fps rate of this movie is listed as 26.744fps (even though the value added to the header is 24/1.001), maybe this affects the subtitles here?

[crasus]

v02 The video framerate is correct, but rather unusual.
a03 Extracting audio track number 3...
a03 Removing AC3 dialog normalization...
a03 Applying (E-)AC3 delay...
a03 A remaining delay of -13ms could not be fixed.

The BluRay has two audio tracks. An ac3 640kbps one and a DTS-HD one with a core of 1536kbps. I get a delay could not be fixed message on both. Is there any way to correct it? ArcSoft DTS is installed and fully functional with eac3to (latest version).

Thank you!

[Snowknight26]

No, because of the size of AC3/DTS frames. I can't remember if AC3 is 32ms per frame or not, but if you have an AC3 track that has a -40ms delay, adding 32ms would yield an unfixable -8ms delay unless you reencode the audio. Same goes for DTS.

Not like you'd be able to hear the difference with an -8ms delay anyway.

madshi, would it be possible to parallelize audio conversion and gap fixing? I noticed that when converting a track to AAC and extracting a DTS track that had gaps, the 2nd pass for the DTS gap fixing only started after the 2nd pass of the AAC encoding/gap fixing finished.

[crasus]

eac3to reports that both tracks have a 83ms delay on the BluRay. Should I try to encode the DTS-HD to an ac3 5.1 448kbps track?

[Snowknight26]

Why are you trying to reencode? If it's to remove that miniscule delay, I suggest you rethink what you're doing.

[dcmo]

I'm pretty new to this, but I have a pretty big issue with the sound quality which I am getting. I'm using eac3to, pcm2tsmu, and ts muxer to get my backup. When running an
eac3to test it shows I have the Arcsoft Decoder, Haali Matroska Muxer, Nero AAC Endoder, and the MkvToolnix as up to date or working fine. The picture comes out great but the sound is definitely lacking. The channels being mapped wrong on some of the movies is merely an annoyance, I can just switch the cables; but the poor quality coming out of the center channel is almost a deal breaker. I'm re-encoding them all as lossless pcm to stream to a PS3, for that matter they may still be lossless. However the center sounds boxy, or boomy; after searching thru this thread it could be it has a kind of mono sound to it. I don't know what to call it, but I do know that it pales in comparison to the disc. I've got a pretty nice little set-up and I don't want to lose anything quality wise. Is there something I'm doing wrong while backing these movies up. Any help is much appreciated on this end.

[Inspector.Gadget]

Post the exact command line you're using, including the output of eac3to and what it reports about the source and destination files.

[tebasuna51]

I'm pretty new to this, but I have a pretty big issue with the sound quality which I am getting. I'm using eac3to, pcm2tsmu, and ts muxer to get my backup.
Pcm2Tsmu now is obsolete, the last TsMuxer accept .w64 files to avoid the problem with .wav files greater than 4GB.

Use eac3to to output .w64 files instead .pcm+pcm2tsmu

I'm re-encoding them all as lossless pcm to stream to a PS3, for that matter they may still be lossless. However the center sounds boxy, or boomy; ...

I think PS3 only support PCM 2.0, if you have an audio equipment with 5.1 speakers use ac3 640 Kb/s instead PCM.

If you want only stereo sound you need use :
eac3to input.file output.w64 -down2 -normalize
to obtain a PCM 2.0 with all the channels mixed.

[KidKappa]

i'm having troubles getting eac3to to recognize my arcsoft dts decoders/encoders, i have TotalMedia Theatre (2.1.6.131) and eac3to (v3.17) and running on Windows 7 64bit, when I run the -test i get that arcsoft is not installed and and error saying that magcore.dll cannot be found. i've looked through this thread but alot of it is over my head. i noticed that the arcsoft common files are in the "program files (x86)" folder and not in the "program files" folder. Also the missing magcore.dll is in there as well. could someone please give me a nice step by step on how to get this working. thank you.

[dcmo]

Post the exact command line you're using, including the output of eac3to and what it reports about the source and destination files.

eac3to v3.17
command line: eac3to.exe E: 1) 2: C:\movie\HIC.h264 3: C:\movie\HIC.pcm
------------------------------------------------------------------------------
M2TS, 1 video track, 4 audio tracks, 3 subtitle tracks, 1:42:50, 24p /1.001
1: Chapters, 16 chapters
2: h264/AVC, 1080p24 /1.001 (16:9)
3: DTS Master Audio, English, 7.1 channels, 24 bits, 48khz
(core: DTS, 5.1 channels, 24 bits, 1509kbps, 48khz)
4: AC3, French, 5.1 channels, 640kbps, 48khz, dialnorm: -27dB
5: AC3, English, 2.0 channels, 224kbps, 48khz
6: AC3, English, 2.0 channels, 224kbps, 48khz
7: Subtitle (PGS), English
8: Subtitle (PGS), English
9: Subtitle (PGS), Spanish
[a03] Extracting audio track number 3...
[a03] Decoding with ArcSoft DTS Decoder...
[v02] Extracting video track number 2...
[a03] Swapping endian...
[a03] Remapping channels...
[a03] Creating file "C:\movie\HIC.pcm"...
[v02] Creating file "C:\movie\HIC.h264"...
[a03] The original audio track has a constant bit depth of 24 bits.
[a03] Audio overlaps for 9ms at playtime 0:21:31. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:23:05. <WARNING>
[a03] Audio overlaps for 10ms at playtime 0:39:41. <WARNING>
[a03] Audio overlaps for 9ms at playtime 0:40:32. <WARNING>
[a03] Audio overlaps for 10ms at playtime 1:03:57. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:16:14. <WARNING>
[a03] Audio overlaps for 9ms at playtime 1:20:34. <WARNING>
[a03] Audio overlaps for 8ms at playtime 1:25:34. <WARNING>
[a03] Starting 2nd pass...
[a03] Extracting audio track number 3...
[a03] Decoding with ArcSoft DTS Decoder...
[a03] Swapping endian...
[a03] Remapping channels...
[a03] Realizing RAW/PCM gaps...
[a03] Creating file "C:\movie\HIC.pcm"...
[a03] The processed audio track has a constant bit depth of 24 bits.
Video track 2 contains 147951 frames.
eac3to processing took 51 minutes, 59 seconds.
Done.

MUXOPT --no-pcr-on-video-pid --new-audio-pes --vbr --vbv-len=500
V_MPEG4/ISO/AVC, "C:\Movie\HIC.h264", fps=23.976, insertSEI, contSPS
A_LPCM, "C:\Movie\HICUPDATE.pcm"


SmartLabs tsMuxeR. Version 1.10.6 http://www.smlabs.net
Decoding H264 stream (track 1): Profile: High@4.1 Resolution: 1920:1080p Frame rate: 23.976
H.264 stream does not contain fps field. Muxing fps=23.976
Decoding LPCM stream (track 2): Bitrate: 9216Kbps Sample Rate: 48KHz Channels: 7.1 Bits per sample: 24bit
Processed 147951 video frames
Mux successful complete.
Muxing time: 8 min 43 sec


I've only backed up a few movies so far, this is the only one where the audio was overlapping. I used Clown BD to do this one the first time, said the blu-ray structure wasn't recognized when I tried to use Eac3to with it the first time. The log files indicated wav files with Clown BD so I re-ran it.

I think PS3 only support PCM 2.0, if you have an audio equipment with 5.1 speakers use ac3 640 Kb/s instead PCM.

If you want only stereo sound you need use :
eac3to input.file output.w64 -down2 -normalize
to obtain a PCM 2.0 with all the channels mixed.

I've got multiple channels working now out of the PS3 with this, would the other channels be active if the PS3 only supported 2.0. Downgrading my sound quality is unacceptable, I enjoy the sound more than I do the picture. There are times when I will just shut my eyes and let the sound sink in. If this can't work I will just rip to a back up disc with BD Rebuilder.

[Inspector.Gadget]

What about taking the DTS core? You'll have known surround compatibility at the cost of the lossless data that you probably can't ABX against the core. That said, tebasuna 51 knows more than I do about the PS3, so I'll defer to him.

[dcmo]

A little more follow-up. I have a 7.2 system set-up and was testing (receiver set to MCH PCM) out the new results this morning. I had to switch the center and the RF channel to get the dialog coming out of the center channel. All speakers were active except for the LS (for further clarification not the LBS speaker) speaker, which was completly dead. As I had suggested earlier about the sound not sounding right when coming out of the center (possibly being mono) I wanted to hear what the mono would actually sound like so I changed my selection on my receiver to mono. While listening to it in mono I don't believe it is quite mono sounding when it is set to MCH PCM, and more than that the dialog changed from the center channel back to the RF channel with everything coming out of the RF speaker. So to sum it all up:

MCH PCM: have to switch C and RF speakers to get dialog out of center.

Mono: With the C and RF speakers switched (have to switch them to get MCH PCM), the sound now comes out the RF.