One-and-Only PS3 as Blu-Ray Player Thread

[phdeane]

Originally Posted by rwestley

Now with bitstreaming confirmed it makes the PS3 an even better buy. I just wish that they included an IR sensor. I am guessing that this introduction will help to bring lower prices to stand alone players. Can't wait for Black Friday.

Originally Posted by Doug Blackburn

???? PS3s don't go on sale. A Blockbuster near me has 2 40GB PS3s that are marked $399 and they won'd BUDGE even though they have been sitting in the store for 2 years. On black Friday you MIGHT get a free movie or free game, but probably not since the Slim will still be new and probably still somewhat in demand - or maybe not since Wii is outselling PS3 by 2:1 right now.

I believe rwestley was referring to "stand alone players." See bolded above.

[Robert George]

???? If you want Pro Logic IIx or DTS:Neo6 applied to a TrueHD or DTS-HD bitstream track, it can only be done after the bitstream is decoded to PCM - any AVR (that decodes TrueHD and DTS-HD) will do that and any AVR will process the PCM audio output by current and older PS3s with PLIIx or Neo6. Bitstreaming really has nothing to do with it at all.

This is false, and has been a major part of the misinformation regarding internal decoding vs. bitstreaming since the HD DVD and Blu-ray formats were launched. Not all receivers/processors will apply post processing to multi-channel PCM audio. Also, HDMI is not a very good interface for the transmission of PCM, quite average in fact. Further, the whole "bits is bits" argument is not the point. The potential problems with internal decoding with PCM output is not only the potential of errors being introduced in the transmission over HDMI, but the fact that different receivers process PCM differently than packeted digital bitstreams (DD and DTS). I have personally compared internally decoded hi-res audio from a PS3 with the same disc in a standalone BD player into the same AVR (Denon, Pioneer Elite, and Yamaha models) and the difference was noticeable with greater clarity and low level detail in the bitstreamed audio.

While some will contend that there is either no difference, or so little difference as to be irrelevant, my contention, based on real world testing, is that there is an audible difference on some systems, and that is reason enough to offer the option of bitstream audio output.

Frankly, I'm a little dismayed by the vehemence displayed by some people in their continuing campaign AGAINST this useful feature. It's okay to be wrong. Really. No one is going to take away your console just because you can't understand something as technical as advanced digital audio processing.

But if you do bitsream, you will never hear secondary audio tracks from PIP director commentary or probably even the regular director/actor/cinematographer commentary.

That part is true. Most people that select the bitstream option know this and aren't afraid to switch to internal decoding if they want to listen to a commentary track.

[Geaux Tigers]

Originally Posted by shabre

Can we ask our little buddy in the oval office for a "Cash for PS3's" program so we can trade in our very used PS3 for a new one

He will sponsor the program only if the government controls the program and decides who is entitled. I may be confusing this program with the health care proposal. It is hard to keep track with the government creating so many programs to control our lives or should I say help us.

[eldithomaso]

Originally Posted by Robert George

This is false, and has been a major part of the misinformation regarding internal decoding vs. bitstreaming since the HD DVD and Blu-ray formats were launched. Not all receivers/processors will apply post processing to multi-channel PCM audio. Also, HDMI is not a very good interface for the transmission of PCM, quite average in fact. Further, the whole "bits is bits" argument is not the point. The potential problems with internal decoding with PCM output is not only the potential of errors being introduced in the transmission over HDMI, but the fact that different receivers process PCM differently than packeted digital bitstreams (DD and DTS). I have personally compared internally decoded hi-res audio from a PS3 with the same disc in a standalone BD player into the same AVR (Denon, Pioneer Elite, and Yamaha models) and the difference was noticeable with greater clarity and low level detail in the bitstreamed audio.
....

That part is true. Most people that select the bitstream option know this and aren't afraid to switch to internal decoding if they want to listen to a commentary track.

Ah the Jitter argument. Good point since most recivers don't have flow control or any form of Jitter reduction over HDMI and that can make a difference for a lower end HDMI system. Bitstreaming could be better in that regard vs PCM.

However, NO players other than the PS3 do the overlap of secondary audio as well with internal player decoding. Most popular units even DOWNGRADE the primary signal (Dolby True HD or DTS HD MA to the core DD or DTS since they don't have the processing power to decode the HD codec and the secondary audio).

A player that can bitstream but when decoding has to default to the original base codecs to combine secondary audio is a FAR inferior solution even with jitter introduced.

The fact the Slim PS3 will be able to do both will be an improvement for some with lesser HDMI setups - likely the majority of PS3 buyers.

Even with some jitter introduced I would still prefer some to most discs with advanced secondary audio decoded in the player. YMMV of course depending on the HDMI flow control, jitter introduced with PCM conversion and the quality of your BD player.

So even though digital is digital there are still multiple variables in transports and transmission.

The real question is will the next PS3 be upgradable to 3D BD? I doubt it and unless it is I will personally pass and keep my first gen.

[DaViD Boulet]

While some will contend that there is either no difference, or so little difference as to be irrelevant, my contention, based on real world testing, is that there is an audible difference on some systems, and that is reason enough to offer the option of bitstream audio output.

Agreed.

In fact, it was hearing the real-world effects of jitter in a bit-for-bit identical digital audio comparison that got me interested in high fidelity audio back in 1990's. I had two DAT tapes played back through the same d/a converter via the same digital connection... but one DAT tape was the original and one was a digital-dub made via coax digital connection. The digitally dubbed tape sounded harsher and less natural in the highs... again, all audible when played back over the same DAC via the same cables. Two tascam decks were used to make the dubs. Curiously, when dubbing via balanced XLR digital, the altered sound of the "dub" vanished and I couldn't hear any difference between the original and the dub made via XLR.

I called a tech at tascam who stated, without hesitation, that "oh yeah, you get jitter in the dub via coax because the meta-data sent along with the audio signal (like track-start ID flags) interferes with the time-clock. But over XLR there's no subcode data sent with the data so you get a cleaner time-clock on the other end".

Well, that's what my ears heard. I stress that the audible results of jitter were obvious enough that it prompted me to call Tascam to find out why my "digital dubbed DAT tape (via coax digital) sounded different than original," despite the bit-for-bit copy.


New topic:

It's been a LONG time since I've visited this thread. Can anyone tell me if Sony has released a firmware update for the PS3 that allows for a "constant resosution/frequency" video output? IE: one that allows 1080i and SD content on Blu-ray's to be upscaled to 1080p60 for a constant HDMI 1080p60 ouput regardless of content?

[Doug Blackburn]

Originally Posted by Robert George

This is false, and has been a major part of the misinformation regarding internal decoding vs. bitstreaming since the HD DVD and Blu-ray formats were launched. Not all receivers/processors will apply post processing to multi-channel PCM audio.

PROVE IT. I said that all AVRs that decode TrueHD and DTS-HD will apply PLIIx or DTS:Neo6 processing to multi-channel PCM inputs to achieve 7.1 sound. I didn't specify, but was referring to multi-channel PCM via HDMI. And I didn't specify but was referring to 7.1-capable AVRs because why would you use PLIIx or Neo:6 to get 7.1 sound from a 5.1 AVR (nonsensical).

Please cite specific examples of 7.1 AVRs that decode TrueHD and DTS-HD that do not process incoming multi-channel PCM via HDMI with any internal surround modes and presumably, without correcting for speaker levels, speaker distance, crossovers, speaker size, and proprietary surround modes (not that many will find proprietary modes useful).

Until you have specific examples, I'm sticking with my assessment because there would be no roadblock to processing PCM coming in over HDMI because TrueHD and DTS-HD are converted to PCM before they are processed anyway.

I believe you are confused... it is multi-channel ANALOG inputs that are rarely processed in any way by AVRs. Multi-channel PCM is digital audio. There are very very few surround processors or AVRs with 8 channels of analog to digital converters and THAT only affects ANALOG signal processing. PCM is PCM and the AVR doesn't care if it enters the AVR as PCM over HDMI or whether the AVR decodes the TrueHD or DTS-HD to PCM. All processing for PLIIx, Neo:6, speaker levels, speaker distance, speaker size, LFE yes/no, bass management, proprietary modes... all of it is all done in PCM mode. This is SIMPLE to check - send stereo audio from a CD player or other disc player to the AVR and select PLIIx or Neo:6 and see if you get sound from 5.1 or 7.1 (whichever setup you are running). If you do, the AVR is processing PCM. Period. If you send 5.1 PCM multi-channel via HDMI from a movie, and you have a 7.1 surround setup, you won't get sound in the 2 back surrounds unless the AVR is applying PLIIx or Neo:6 or some proprietary processing in the AVR. If you get sound in the back, PCM is being processed.

[eldithomaso]

Originally Posted by Doug Blackburn

PROVE IT. I said that all AVRs that decode TrueHD and DTS-HD will apply PLIIx or DTS:Neo6 processing to multi-channel PCM inputs to achieve 7.1 sound. I didn't specify, but was referring to multi-channel PCM via HDMI. And I didn't specify but was referring to 7.1-capable AVRs because why would you use PLIIx or Neo:6 to get 7.1 sound from a 5.1 AVR (nonsensical).

Please cite specific examples of 7.1 AVRs that decode TrueHD and DTS-HD that do not process incoming multi-channel PCM via HDMI with any internal surround modes and presumably, without correcting for speaker levels, speaker distance, crossovers, speaker size, and proprietary surround modes (not that many will find proprietary modes useful).

Until you have specific examples, I'm sticking with my assessment because there would be no roadblock to processing PCM coming in over HDMI because TrueHD and DTS-HD are converted to PCM before they are processed anyway.

I believe you are confused... it is multi-channel ANALOG inputs that are rarely processed in any way by AVRs. Multi-channel PCM is digital audio. There are very very few surround processors or AVRs with 8 channels of analog to digital converters and THAT only affects ANALOG signal processing. PCM is PCM and the AVR doesn't care if it enters the AVR as PCM over HDMI or whether the AVR decodes the TrueHD or DTS-HD to PCM. All processing for PLIIx, Neo:6, speaker levels, speaker distance, speaker size, LFE yes/no, bass management, proprietary modes... all of it is all done in PCM mode. This is SIMPLE to check - send stereo audio from a CD player or other disc player to the AVR and select PLIIx or Neo:6 and see if you get sound from 5.1 or 7.1 (whichever setup you are running). If you do, the AVR is processing PCM. Period. If you send 5.1 PCM multi-channel via HDMI from a movie, and you have a 7.1 surround setup, you won't get sound in the 2 back surrounds unless the AVR is applying PLIIx or Neo:6 or some proprietary processing in the AVR. If you get sound in the back, PCM is being processed.

Doug:

Pioneer SC series receivers (with surround back set to Auto or off) will allow pure (no proprietary audio re-encode or other decoding) bitstreamed data in PURE DIRECT HDMI modes. Be the source 5.1 or 7.1. That mode disables MCACC and other time alignment calibration.

Is that an example you are looking for in your reference. I am not sure I understand the second paragraph.

[cpcat]

For those concerned about the potential effects of jitter---remember that if any audio delay is provided by the AVR for lipsync correction then the audio is necessarily reclocked and any differences due to jitter (in the PCM vs bitstream argument) would therefore likely be rendered moot.

[andydumi]

Originally Posted by eldithomaso

Doug:

Pioneer SC series receivers (with surround back set to Auto or off) will allow pure (no proprietary audio re-encode or other decoding) bitstreamed data in PURE DIRECT HDMI modes. Be the source 5.1 or 7.1. That mode disables MCACC and other time alignment calibration.

Is that an example you are looking for in your reference. I am not sure I understand the second paragraph.

I believe Onkyo 605 also does this. A receiver which is incredibly popular around here. I remember it because it was one of the things people loved about the 606 when it came out, that it added those processing modes.

[Robert George]

I believe you are confused...

You can believe what you want. I have done the testing. I don't need some internet amateur to tell me what he THINKS is going on inside these components.

Now, if you have a background in engineering and have some bench tests that can prove that the audible differences between the PCM output of a PS3 that is then sent over any variety of HDMI cables, a mediocre software decoding solution by the way, is exactly the same as the decoding of native bitstream audio in multi thousand dollar AVRs, then I will accede to your position. On the other hand, if all you have is the tired old "bits is bits" argument with nothing to back it up but your own belief, then go peddle that to the unwashed because I know better.

Lastly, what the hell difference does it make to you anyway? You seem to be personally offended by the idea that bitsteam audio MAY be a better solution for some people.

[SAVholic]

the "bitstreaming" feature is the buying point for me. Personally I was going to buy a stand alone bd player with 'bitstreaming" capabilities. difference or no difference i'll just want my Yamaha AVR to do all the decoding.

[Hughmc]

These are quoted from different forums, but they are from audio insiders, sound engineers:


"Player decoding or Receiver decoding, that is the question
I know there has been much back and forth regarding the player doing the decoding or the receiver doing the decoding. However I would like to preface this question with this comment.

When you look at all of the myriad of issues regarding proper playback and getting the best sound, many folks have completely overlook the most important component chasing after minor benefits. Proper room acoustics play a far larger role in getting better performance than something as small as which component does the decoding. The arguement for which sounds better (if it actually does) belongs in the studio(which acoustics are tightly controlled) or in the upper 5-10% of the folks who actually have their room properly treated based on acoustical measurements. To actually answer the question of which is better, the answer is neither has any sonic benefits over the other. I will explain.

When the player does the decoding(or transcoding), the process of transcoding is lossless. In other words nothing is lost converting the bitstream to PCM to send to your receiver. All PIP audio will be mixed in along with the program audio, and the user has access to the audio of all interactive and program material. Whether you choose to do bass management and speaker alignment in the player, or the pcm audio is sent to the receiver for these functions, they are done in PCM because that is how the DSP chips function, is with PCM signals. So no matter which way you turn, the audio will have to be converted.

If the player passes the audio to the receiver in bitstream form, the receiver will have to convert that bitstream to PCM for any bass mangement or speaker alignment to take place. That process is also lossless, and is much like we have seen with legacy Dolby Digital and Dts. The drawback is that no audio from PIP or any interactive material will be heard because this process bypasses the internal mixer of the player. So no matter which direction you choose, PCM conversion will have to take place whether the player does it, or the reciever does it. In the end, there is no sonic benefit that either has over the other, and why when looked at critically, the receiver doing it becomes a marketing ploy and nothing else."


And the myths and reality about jitter:




"Some say that jitter affects the sound, and there is jitter over HDMI if not bitstreamed. Just how much jitter is there, is the question.

Jitter to the best of my knowledge, is when you transfer a digital signal and some 1's and 0's get lost in the transfer. Therefore not being a perfect source with no error correction method.

Someone correct me if I am wrong here.

...except that the HDMI protocol has error correction built into the spec, so the people worrying about jitter are gullible fools who pay a little too much attention to the marketing PR of companies like Monster Cable.

See the discussion here for an interesting look at what HDMI does/doesn't do regarding protecting data integrity:

http://episteme.arstechnica.com/eve/...r=488004880831

The important parts quoted here, from the original HDMI specification:
http://www.hdmi.org/download/HDMI_Spec_1.3_GM1.pdf

Quote:
Originally Posted by HDMI specification
From 4.2.5 (physical layer):
Quote:
For each channel under all operating conditions specified in this section the following conditions shall be met. At TMDS clock frequencies less than or equal to 165MHz, the Sink shall recover data at a TMDS character error rate of 10-9 or better, when presented with any signal compliant to the eye diagram of Figure 4-20. At TMDS clock frequencies above 165MHz, the Sink shall recover data on each channel at a TMDS character error rate of 10-9 or better, when presented with any signal compliant to the eye diagram of Figure 4-20 after application of the Reference Cable Equalizer.

Quote:
Originally Posted by HDMI specification
From 5.2.3 ("data" coding, basically everything that isn't video or a control signal -- audio, content protection, gamut metadata, etc.):
Quote:
During the Data Island, each of the three TMDS channels transmits a series of 10-bit characters encoded from a 4-bit input word, using TMDS Error Reduction Coding (TERC4). TERC4 significantly reduces the error rate on the link by choosing only 10-bit codes with high inherent
error avoidance.

...

All data within a Data Island is contained within 32 clock Packets. Packets consist of a Packet Header, a Packet Body (consisting of four Subpackets), and associated error correction bits.

Each Subpacket includes 56 bits of data and is protected by an additional 8 bits of BCH ECC parity bits.

...

To improve the reliability of the data and to improve the detection of bad data, Error Correction Code (ECC) parity is added to each packet. BCH(64,56) and BCH(32,24) are generated by the polynomial G(x) shown in Figure 5-5.

If you don't sling the lingo, a character data error rate of 10-9 or better means that one in 10^9 (that's 1 out of 1,000,000,000 - yes, 1 billion) characters or less must pass without error to meet the specification.


And more:

Hello everyone!

I wanted to register to share some information straight from the horse's mouth (a sound engineer). With these lossless digital codecs (TrueHD and DTS Master Audio), the decoded LPCM signal will always contain exactly the same information; regardless of where the decoding is done.

You need to keep in mind that TrueHD and DTS:MA are nothing more than compression algorithms, similar to .ZIP files on your PC. If you create a .ZIP archive containing 5 pictures, you can take that file to ANY computer in the entire world; and so long as it can decompress .ZIP files, your pictures will come out exactly the same.

Believe me, if digital compression formats had subjective outcomes depending on what device is doing the decompression, we'd be in trouble. Bottom line: It makes NO difference where the decoding is done, be it a PS3 or a receiver.

It's also important to mention that even sound post-processing technologies like Audyssey MultiEQ/DSX, and Dolby Pro Logic, are capable of applying their algorithm to multichannel PCM signals. There is simply nothing to be gained by letting the receiver do the decoding.

[Pugnax555]

To add onto what Hughmc wrote/quoted, you have only a finite amount of DSP processing power, with some of it in the receiver (most of it usually), and some in the player. (BTW, the Cell chip in the PS3 was designed as a DSP powerhouse, despite what many of you self-appointed "experts" may believe.) Decompressing the lossless audio from TrueHD or DTS-HD MA takes a considerable amount of horsepower--so much so that many of the early HD players and receivers couldn't even handle DTS-HD MA. And also keep in mind that decoding + applying post-processing will always require more resources than either decoding or applying post-processing, which is one of the points Doug was making up there. Now, I'm of the mind that when you have limited resources that can do the job equally well (which is the case in but the rarest of circumstances), it's best to spread the various duties over the different components that can handle it. However, some would rather have one component doing nothing with its resources, while loading another component up to do everything. If you have that much processing power available to you and it makes you feel better to say "Well, I spent $xxxx on that component, so I'm going to get my money's worth", then more power to you. But don't delude yourself into thinking that you can't get the exact same results using different means.

[drhankz]

Originally Posted by Hughmc

These are quoted from different forums, but they are from audio insiders, sound engineers:

Great WORK Hugh putting all that ACCURATE and CORRECT info Together.

Unlike Lossless Codecs - Humans aren't lossless

No matter how much you try to help educate them - some will never listen
and stick with their own incorrect conclusions.

One last Three cheers for Hugh getting it right.

[Jim Gilliland]

Originally Posted by Hughmc

These are quoted from different forums, but they are from audio insiders, sound engineers:

Jitter to the best of my knowledge, is when you transfer a digital signal and some 1's and 0's get lost in the transfer. Therefore not being a perfect source with no error correction method.

Someone correct me if I am wrong here.[/b][/i]

I've stayed out of this discussion, but I can't let this stand. The definition of jitter listed above is completely incorrect. Jitter is not a data error, it is a clocking error, a timing error. A signal that is affected by jitter will sound "harsh" not because the data is wrong, but because the individual samples are being delivered at an imprecise clock rate.

Jitter was a significant issue in the early days of digital audio because many D/A converters based their clocks on PLL circuits that derived a clock from the incoming digital signal. If that signal carried considerable amounts of jitter, then the recovered clock would retain that jitter and cause very real damage to the audio.

That mode of processing is no longer commonly used. I won't guarantee that there aren't some cheap audio processors on the market that still have problems with jitter, but they are very rare at this point. Most current devices use clocks that are either internally generated or have PLL circuitry that is far superior to those early examples. Jitter was a big problem in digital audio 15-20 years ago, but it's not a big problem today.

For the record, I am a broadcast engineer and a digital recording engineer, so I have considerable knowledge and experience in this area. Nonetheless, there are many experts who can offer much more depth on this topic than I can. One of the experts in this field is mastering engineer Bob Katz, who has written extensively on jitter both online and in his books. Here is a quote from an article that he wrote around 1997.

Jitter and A to D Converters

The A to D Converter is one of the most critical digital audio components susceptible to jitter, particularly converters putting out long word lengths (e.g. 24-bits). The master clock that drives an A/D converter must be very stable. A jittery master clock in an A/D converter can cause irrevocable distortion and/or noise which cannot be cancelled out or eliminated at further stages in the chain. A/D's can run on internal or external sync. On internal sync, the A/D is running from a master crystal oscillator. On external sync, the A/D's master clock is driven by a PLL, which is likely to have higher remnant jitter than the crystal clock. That is why I recommend running an A/D converter on internal clock wherever possible, unless you are synchronizing an A/D to video or to another A/D (in a multichannel setup). If you must use external sync, use the most stable external source possible (preferably video or wordclock over AES/EBU), and try to ensure that the A/D's designer used an ultra-stable PLL.

Jitter and DSP-based Processors

Most DSP-based software acts as a "state machine." In other words, the output result on a sample by sample basis is entirely predictable based on a table of values of the incoming samples. The regularity (or irregularity) of the incoming clock has no effect on the output data.

Exceptions to "state-based" DSP processes include Asynchronous Sample Rate Converters, which are able to follow variations in incoming sample rate, and produce a new outgoing sample rate. Such devices are not "state-machines", and jitter on the input may affect the value of the data on the output. I can imagine other DSP processes that use "time" as a variable, but these are so rare that most normal DSP processes (gain changing, equalization, limiting, compression, etcetera) can be considered entirely to be state machines.

Therefore, as far as the integrity of the data is concerned, I have no problems using a chain of jittery (or non-jittery) digital devices to process digital audio, as long as the digital device has a high integrity of DSP coding (passes the "audio transparency" test).

Note the difference here between his two sections. The first describes a simple D/A processor that use a recovered clock (a DAT machine, for example) which may be affected significantly by jitter if it is not well-designed (and some of those early '90s designs left a LOT to be desired!). The second section describes a more modern (even as of a decade ago) DSP-based system that uses internal processing and an internal clock. This describes our modern AVRs, which are by and large unaffected by jitter.

Here's the complete reference: http://www.digido.com/articles-demos.html Article #8 covers jitter.

[plm999]

Actually, I came to this thread to inquire about another issue, but the current topic of PCM vs. bitstream seems pretty hot, so i have a comment on that first.

There is nothing in the Blu-ray specification that prescribes the bit depth of either the internal mixer, or the PCM output in a Blu-ray player. I don't know that this is the case, but I have suspected for some time now that some players may only output 16-bit PCM from the mixer. It could be that, or it could be that the player is excessively pre-scaling the audio to guarantee no clipping post the mix, thus effectively losing bits. Either theory explains a lot of observations. Again, nothing proven, just a theory. Up to 3 audio sources can be mixed, (main audio, secondary audio and effects sounds), so that could be a loss 2-bits of resolution. My personal preference is to bitstream when I'm just watching the movie. Another reason I prefer to bitstream is that downmix coefficients (and other metadata) that exist in the bistream are lost when you go to PCM output. OK, stepping off the soap box now.

OK, my original question. Last night, my wife had on the movie "He's Just Not That Into You" on the PS3. I noticed the SPDIF input to the AVR was stereo PCM, so I looked a little closer, and the PS3 reported that the audio was Dolby 640K (I think it was really DTHD). I tried both audio tracks, but the output stayed PCM. Has anyone else seen this? I can understand the Dolby TrueHD going out as PCM, but the DD should have bitstreamed, right?

[Jim Gilliland]

Originally Posted by plm999

There is nothing in the Blu-ray specification that prescribes the bit depth of either the internal mixer, or the PCM output in a Blu-ray player. I don't know that this is the case, but I have suspected for some time now that some players may only output 16-bit PCM from the mixer. It could be that, or it could be that the player is excessively pre-scaling the audio to guarantee no clipping post the mix, thus effectively losing bits. Either theory explains a lot of observations. Again, nothing proven, just a theory.

Most modern DSP chips convert internally to floating point before doing processing, so there's no reason for concern about loss of resolution. I can't imagine any modern design that deliberately dithered the output back to 16 bits, but perhaps there are some out there. Even so, 16 bit audio can sound pretty darn good.

Caveat: I have no idea what processing hw/sw exists in the PS3 or any particular AVR or Blu-Ray player. I would assume (based on its design) that the PS3 does it all in software.

[Doug Blackburn]

Originally Posted by eldithomaso

Doug:

Pioneer SC series receivers (with surround back set to Auto or off) will allow pure (no proprietary audio re-encode or other decoding) bitstreamed data in PURE DIRECT HDMI modes. Be the source 5.1 or 7.1. That mode disables MCACC and other time alignment calibration.

Is that an example you are looking for in your reference. I am not sure I understand the second paragraph.

No, it would be expected that a "Pure" mode (or other mode intended to present signals with no processing) would work that way. The person who posted the original statement was implying the AVR would never synthesize 7.1 from a 5.1 and would not process the multi-channel PCM in any other way when receiving multi-channel PCM.

[nealh]

so is bitstreaming going to be a fw change for all PS3? or just the slim?

[rdclark]

Originally Posted by nealh

so is bitstreaming going to be a fw change for all PS3? or just the slim?

It appears to be a hardware change exclusive to the Slim. CNET's review confirmed their Slim as bitstreaming, even though it was running current firmware.

[Doug Blackburn]

Originally Posted by Robert George

You can believe what you want. I have done the testing. I don't need some internet amateur to tell me what he THINKS is going on inside these components.

Now, if you have a background in engineering and have some bench tests that can prove that the audible differences between the PCM output of a PS3 that is then sent over any variety of HDMI cables, a mediocre software decoding solution by the way, is exactly the same as the decoding of native bitstream audio in multi thousand dollar AVRs, then I will accede to your position. On the other hand, if all you have is the tired old "bits is bits" argument with nothing to back it up but your own belief, then go peddle that to the unwashed because I know better.

Lastly, what the hell difference does it make to you anyway? You seem to be personally offended by the idea that bitsteam audio MAY be a better solution for some people.

Let's take the last paragraph first - I don't like misinformation spread around. You did that in your post. I challenged 1 specific thing you said that had nothing to do with bitstream vs PCM or whether the PS3 HDMI interface sounds good or not or whether the PS3 HDMI interface has a jitter problem. You ignored the challenge to prove your statement. In fact, I expressed no preference one way or the other for bitstream vs PCM - though in another post, I did mention it would be nice if you could select bitstream and have the player automatically switch to PCM if you select a disc feature that requires the secondary audio track. I'd rather not have to worry about manually switching back and forth and let the player do the switching automatically for me... bitstream when it can, PCM when it must use PCM to play the commentary or other features I select.

I ask for proof that your statement about AVRs was accurate and you offered nothing but name calling (which isn't permitted on AVS Forums so you may wish to edit your post). The post above is typical run away and hide tactics of someone who has made an incorrect statement and is trying to deflect attention from the statement being challenged. I was an engineer for 34 years. And I am paid to know what I am talking about when reviewing audio and video products. I own audio and video measurement equipment and software. I am also an internet professional. So there goes all your name calling right down the drain.

I'm going to quote the statement from your post that I challenged AGAIN. Let's see if you can actually address the issue in your next reply while being civil about it.

"[AVRs always able to process 5.1 to 7.1] is false, and has been a major part of the misinformation regarding internal decoding vs. bitstreaming since the HD DVD and Blu-ray formats were launched. Not all receivers/processors will apply post processing to multi-channel PCM audio. "

Post processing includes (but is not limited to): Dolby Digital Pro Logic IIx Music and Movie mode, DTS Neo:6 Music and Movie mode, proprietary surround modes the manufacturer may add, correction for speaker distance, speaker size, LFE yes/no, and bass management. I said all 7.1 AVRs that decode TrueHD and DTS-HD also apply all the same processing to multi-channel PCM - you said that is false.

It is obvious from playing test discs, switching between PCM and bitstream modes and measureing the output of each speaker channel (not using a PS3, obviously) that PCM and Bitstream are processed in the same ways by the AVR. If you select PLIIx or Neo:6 with multi-channel PCM, you get stereo in 7.1 or 5.1 converted to 7.1. I've seen a lot of AVRs and they have all done that - a Pioneer, Onkyo and Denon all here right now all do that and the Pioneer doesn't even do TrueHD or DTS-HD. In fact, it can be difficult to get any given AVR to NOT process multi-channel PCM inputs if you need to do that for some reason. This has nothing to do with your quoted response above - you completely ignored the issue/question and tried to turn it into something entirely different that I did not question or comment on one way or the other.

But as long as you brought this up AGAIN, I'll comment on it: jitter on HDMI is a non-issue for Blu-ray movies (more later). However, I will agree that playing a CD on a PS3 using an HDMI connection to an AVR sounds MUCH WORSE than playing a CD on either of the 2 Pioneer DVD players I normally use as a CD transport (one highly modified with a precision master clock, mechanical vibration damping, EMI/RF shielding, power supply mods, BNC replacing original cheap RCA jack, etc, -- the other disc transport is more lightly modified). So why do CDs on a PS3 sound so poor (comparitively) and Blu-ray movies sound so GOOD via the same HDMI connection with PCM format data? It's obvious to me that the data paths are different in some significant way - but I don't have the information or equipment to determine why there is such a noticeable sonic gap between CD and Blu-ray.

Blu-ray audio is not read continuously like CD audio... Blu-ray audio is read in "chunks" with gaps between the chunks. The chunks have to be knit back together with high precision before they are decoded to PCM. Does the PS3 sound so bad playing CDs because of JITTER on HDMI? Without extremely expensive test equipment in a lab environment, no person at home will ever know. Jitter would have to be measured in lab conditions to learn if the problem is jitter or something else.

(By the way, all my equipment is operated from voltage regulated, frequency regulated AC power with precision filtering that drops the wide-bandwidth noise floor of the power line to -100dB or better.)

Because CDs sound relatively poor via the PS3's HDMI interface, will I make the leap and blame the problem on jitter? NO I cannot tell if it is jitter or if the problem is the result of some design deficiency in the PS3 that has nothing to do with jitter. There is a reason for this stance:

I can sent WAV or FLAC files from the same CD (using Exact Audio Copy software) over to the PS3 via wireless network (using the free download "PS3 Media Server") and use the same HDMI connection from the PS3 to the AVR and the sound quality is FAR better than playing the same disc on the PS3. This is easily detectable. That indicates the the PS3's HDMI interface itself is not the problem - but there IS something wrong that makes CDs sound worse when played on the PS3. The PS3's sound quality problem comes somewhere between reading the disc and presenting the data to the PS3's HDMI interface. Obviously, the same data sent wirelessly follows a different path and doesn't pick up whatever it is that harms the sound quality if you play the disc in the PS3.

(SIDEBAR: Somebody posted an quote that may have been a reprint from another thread somewhere that indicated jitter meant 1s and 0s were lost - that's just so technically ignorant that nothing else that person said should have any validity whatsoever. A simplified explanation of jitter is this: jitter refers to random or cyclical variations in the relative timing between bits. Ideal performance is
to have every "gap" between bits absolutely identical. In the real world, about the best jitter performance ever measured is variations in the range of 25-100 picoseconds. Many products are much worse measuring 1000 picoseconds or worse. So no jitter means all your bits are spaced with perfection in time. Having jitter means the bits form a non-uniform "line" with varying gaps between bits. This is important because SOME systems that convert the PCM bitstream to analog audio do the conversion ON THE FLY with no correction of the timing errors. This leads to audible distortion in the analog audio that is quite high enough to be readily audible when played back (see Dr. Malcolm Omar Hawksford's technical paper on the topic if you think you can handle the technical explanation for why this is true). There is much more to say on the topic, but this message is already too long...

[nealh]

Originally Posted by rdclark

It appears to be a hardware change exclusive to the Slim. CNET's review confirmed their Slim as bitstreaming, even though it was running current firmware.

Ok why would need a hardware change to send the info as a bitstream? Can someone explain this too me?

[gluvhand]

Originally Posted by nealh

Ok why would need a hardware change to send the info as a bitstream? Can someone explain this too me?

Only for the HD audio codecs. The current PS3's decode internally and can't send them out as bitstream. The HDMI being used apparently isn't capable of doing this. The one in the "slim" can.

[nealh]

Originally Posted by gluvhand

Only for the HD audio codecs. The current PS3's decode internally and can't send them out as bitstream. The HDMI being used apparently isn't capable of doing this. The one in the "slim" can.

Ok..seems weird that there are different HDMI ports like that. Thanks you

[Hughmc]

Originally Posted by nealh

Ok why would need a hardware change to send the info as a bitstream? Can someone explain this too me?

Older versions of the PS3 had a different HDMI chipset that was NOT capable of passing the HD audio codecs which is why a software update would not resolve the issue.

[sivartk]

Originally Posted by nealh

Ok why would need a hardware change to send the info as a bitstream? Can someone explain this too me?

Originally Posted by nealh

Ok..seems weird that there are different HDMI ports like that. Thanks you

Same reason I can't hit a button on my car remote and unlock the doors...the hardware used in my car's doors doesn't have the capability.

[nealh]

Originally Posted by Hughmc

Older versions of the PS3 had a different HDMI chipset that was NOT capable of passing the HD audio codecs which is why a software update would not resolve the issue.

well that makes sense..thanks for the info.

[tomrowe125]

Originally Posted by Geaux Tigers

He will sponsor the program only if the government controls the program and decides who is entitled. I may be confusing this program with the health care proposal. It is hard to keep track with the government creating so many programs to control our lives or should I say help us.

Wow, try getting your news from NPR or PBS once in a while, instead of the tinfoil-hat crowd at Faux Noise... or did I just somehow blunder onto the Drudge Report?!- Seriously, can we stick to PS3 news?

[seggers]

Originally Posted by tomrowe125

Wow, try getting your news from NPR or PBS once in a while, instead of the tinfoil-hat crowd at Faux Noise... or did I just somehow blunder onto the Drudge Report?!- Seriously, can we stick to PS3 news?

Hey, if Uncle O'bamy can rid the world of a few thousand clunkers, then he can cough up some to rid the world of non bitstream PS3s....

I for one would love some cash so that I can go buy a slim.

Oh, and

Seggers

[x64Man]

Ok, it is well known what HDMI chipset was used in the older versions of the PS3, now it would be nice to know what HDMI chipset is used in the Slim? This will end my speculation that the original HDMI chipset was capable of doing it, but just was not implemented.

No need to post all the data and crap about the original HDMI chipset, that we have all read many times. I just want to know that they have infact changed it.

Thanks