Posts: 23,254
Joined: Aug 2011
Reputation:
1,071
fritsch
Team-Kodi Developer
Posts: 23,254
It's not about "random" noise .. it's about data altering which ends up in some "bits" the AVR recognizes as PCM and not as DTS.
Consider the following: User has set kodi volume to 75%. Kodi decodes wv lossless to float (float 32 bit), from here it multiplie every sample with 0.75. And from here it maps the data to a 24 bit or 16 bit Sink for output. What do you think you will hear?
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 23,254
Joined: Aug 2011
Reputation:
1,071
fritsch
Team-Kodi Developer
Posts: 23,254
2017-01-02, 20:20
(This post was last modified: 2017-01-02, 20:20 by fritsch.)
Nope :-). But wanted to emphasize by repeating things. Cause I am 100% sure this thread will be highjacked by another audiophile guy once upon a time not understanding what is going on.
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Posts: 1,065
Joined: Oct 2011
Reputation:
27
Soli
Posting Freak
Posts: 1,065
2017-01-03, 00:09
(This post was last modified: 2017-01-03, 00:13 by Soli.)
AVRs do not decode this "by accident", they must differentiate between say pcm/dts/dd so they analyze the incoming stream. (Doesn't Kodi have to do this with wav files? To determine if the wav is really a wav or a frame packed dd or dts file? if so why don't we send all 2 channel pcm through this analyzer after decoding from their respective formats?) This will always take precedence regardless what the bit flag is set to.
Posts: 1,065
Joined: Oct 2011
Reputation:
27
Soli
Posting Freak
Posts: 1,065
2017-01-03, 00:18
(This post was last modified: 2017-01-03, 00:19 by Soli.)
Nah. It's not an accident that all AVRs since the Laserdisc ages will properly decode AC3 (and DTS for that matter, later on) regardless of the bit flag. They even released ac3 and dts compact discs they you were meant to playback through your normal cd player, only you had to use a toslink/coaxial cable to your avr. These sent the stream as normal 2 channel linear pcm, even though they weren't.
Posts: 1,065
Joined: Oct 2011
Reputation:
27
Soli
Posting Freak
Posts: 1,065
I humble suggest that you stop your humble suggestions and start talking like a normal person.
I read up on those specs over 10 years ago, and read up on general s/pdif 20 years ago when people were still using scart. The AVRs that predated iec61937 by 10 years didn't care about that bitstream flag, and they still don't. It's not an accident AVRs decode bitstream content even though they stream is flagged as linear pcm. This fact wont change, no matter how much you (or I) recite a standard that was made as a guideline to a 2 decade old technology.
Posts: 1,065
Joined: Oct 2011
Reputation:
27
Soli
Posting Freak
Posts: 1,065
I humbly suggest that you stop worry what I may or may have not read. Instead, argue your case properly, and not just reference sections from a pdf. What if lawyers did this in court?
Let's see what IEC 60958-1 Annex D is: It's not a spec, it's purely (pragmatic) information.
lS/iEC 60958-1:2004
Annex D
(informative)
Transmission of CD data other than linear PCM audio
This standard ailows the interface to carry data related to computer software or signals coded using non-linear PCM and the format specification for these applications is not part of fhis standard. The channel status Bit 1 of Byte O indicates whether the data is linear PCM or not, However, some CD applications currently set this Bit 1=“0 as meaning linear PCM data, while the actual data is not linear PCM but compressed audio data. Such applications do not conform to the IEC 60958 series.
Current data processing equipment such as computers and games machines have a CD-ROM drive and sometimes a IEC 60958 series interface, so there is a possibility of non-linear PCM data output that is dependent on the application software. Therefore, all equipment and applications should respect the channel status definitions in this standard to prevent unexpected behaviour in the decoder.
Consideration is required for applications that, for historic accordance with IEC 60958 with respect to channel status bit 1. level of noise being generated by the conversion of this signal data. Such noise might damage hearing or equipment.
-------------------
The "consideration" the manufacturers took was that the AVRs didn't strictly look at the channel staus bit, but actually the pcm frames itself and this would precede the channel status bit. This would protect the consumers equipment and hearing and as a result save the manufacturers for billions in law suits, warranties etc etc. It's not an "accident" that all AVR's do this, and besides: by the fact that all AVRs do this makes it's safe to say it's by design and/or choice.
..and don't know why you can only discuss things from this century, but fact is AVRs were doing this long before this century.
Now, please argue why you think that it's an "accident" that *your* AVR decodes compressed audio from a S/Pdif stream even though the channel status bit is set to linear pcm? And please explain why the hell this Annex D has anything with this being an "accident" or not in the first place, and why you think I haven't read up on it.
Posts: 23,254
Joined: Aug 2011
Reputation:
1,071
fritsch
Team-Kodi Developer
Posts: 23,254
Besides the technical details ... I hope no one will ever listen to such a file via headphones ...
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
