[thomaspf]

For the Edirol I have only done the DTS PCM test but again this test is sufficient to test for bit perfect playback. I no longer have access to an HDCD capable decoder but if you have access to a higher end Denon receiver you can easily verify that.

Either the system leaves all 16bit/44.1 Khz PCM streams alone or none. As fas as the system is concerned the system is just playing a normal stereo stream for these DTS encoded tracks.

Cheers

Thomas

 

[Crowbar]

HDCD seems like a marketing scam to me. Unless one is using data compression, there's no way you can encode more than 16-bits worth of information into 16 bits without breaking the laws of information theory. But HDCD is not based on data compression, and even if it were, there's no way perceptually significant information could be fit into the LSB.

 

[thomaspf]

Quote:

Originally Posted by Crowbar HDCD seems like a marketing scam to me. Unless one is using data compression, there's no way you can encode more than 16-bits worth of information into 16 bits without breaking the laws of information theory. But HDCD is not based on data compression, and even if it were, there's no way perceptually significant information could be fit into the LSB.

I have never seen the details on how the data in HDCD is actually encoded. I thought it is indeed compressed and the bit stream is random noise when played on a normal player.

I just used it as a somehwat easier to understand example of PCM data that is carrying an encoding.

Quote:

Originally Posted by zheka what would happen if IEC61937 data stream (DTS, DD, whatever) is being passed via S/PDIF but S/PDIF frame headers indicate that enclosed data is regular audio?

Think about the example of a plain old CD player with digital output that knows nothing about DTS and you play a DTS encoded CD on it. The output is an encoded stream with the S/PDIF header indicating a normal stream, however the surround decoders still recognize and decode it. That is exactly what is happening when you play these tracks on a PC bit for bit.

Cheers

Thomas

 

[Crowbar]

Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif I thought it is indeed compressed

Reversible dynamic range compression, not normal data compression (and note that this would cause peaks to be distorted on a non-HDCD player, so there's more to this than just added LSB noise on unsupporting systems). Of course, human difference thresholds of perception between levels is nonlinear, but HDCD is a far cry from a proper nonlinear upgrade for PCM. HDCD also can switch antialiasing filters on the fly, to control whether tansients or HF should be preserved. With 24 bit 96 kHz systems with 4x or more oversamling, both of these are irrelevant.

 

[thomaspf]

Independent on the merits of HDCD to which I have no opinion it is another good test case for bit perfect playback if you happen to have a DAC that can decode that signal.

I thought the material question is whether regular PCM streams get actually impacted and it still looks like they do.

Cheers

Thomas

 

[zheka]

Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif Independent on the merits of HDCD to which I have no opinion it is another good test case for bit perfect playback if you happen to have a DAC that can decode that signal. I thought the material question is whether regular PCM streams get actually impacted and it still looks like they do. Cheers Thomas

what happened when you ran the HDCD test - did it not play at all or the decoder did not register it as HDCD and it played back at red book cd resolution?

thanks

 

[thomaspf]

After kmixer it can no longer detect the HDCD signature and plays these files as standard redbook 16/44.1 PCM streams.

Switching over to kernel streaming made it work again.

Cheers

Thomas

 

[thomaspf]

I have to get back to other stuff so unless Elias feels like he wants to contribute anything else I would like to wrap this up.

For me the status looks like this. It appears that USBaudio.sys is not bit perfect due to kmixer and this is also true for the Benchmark DAC1 like it is for everyone else in the industry. Since Elias has been such a great supporter to get to the bottom of this issue I assume he was simply mislead by the tests he has been conducting.

The DAC1 is still an excellent converter but you need to use it in combination with kernel streaming or a custom ASIO driver like everyone else to get to its full potential. Elias, you might want to update the audio setup tips on your web site to reflect that.

Cheers

Thomas

 

[Crowbar]

thomaspf, when you used kernel streaming, did you still output through usbaudio.sys?

 

[zheka]

good question

 

[zheka]

@Crowbar,

i can see you getting tired of this exchange, yet please answer my question when you have time

what would happen if DD/DTS data stream is being passed via S/PDIF inside frames marked as normal audio? would receiver somehow know that incoming data needs to be decoded?

thank you

gd

 

[Crowbar]

The answer must obviously be yes for DTS if the data is able to be output by S/PDIF, as is demonstrated when ASIO or kernel streaming is used to play back DTS data and the player is able to decode it. I don't know anything about DD.

 

[zheka]

Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif The answer must obviously be yes for DTS if the data is able to be output by S/PDIF, as is demonstrated when ASIO or kernel streaming is used to play back DTS data and the player is able to decode it. I don't know anything about DD.

perhaps you misunderstood my question.
i know that DTS data can be output via S/PDIF.
however, AFAIK, at the very least, the s/pdif frame header must indicate that it is not an ordinary audio stream but IEC61937 compliant data stream ( AC3, DTS, etc), otherwise receivers would not know that the stream needs to be decoded.

the implications must be obvious - if all output from KMixer is encapsulated in regular audio frames, then the stream will never get passed to decoders even if (hypothetically) the data itself is bit perfect.

does it make sense?

 

[thomaspf]

This question now has been answered twice. Receivers do not rely just on the bit in the S/PDIF frame but analyze the stream in real time and switch to surround decoding for encoded data even if that bit is missing in the header.

Standard CD players play DTS discs just fine over their digital output even the models that existed before a DTS flag in the S/PDIF header was even defined.

Cheers

Thomas

 

[zheka]

Quote:

Originally Posted by thomaspf /img/forum/go_quote.gif Standard CD players play DTS discs just fine over their digital output even the models that existed before a DTS flag in the S/PDIF header was even defined. Cheers Thomas

i did not know
have you tried it yourself? i am asking because, based on what i read, the bit setting is only one of the requirements. each frame also needs to be zero padded to make it equal in size to standard PCM frame which i would not expect standard CD players being able to do.

respectfully

gd