Well we've already established in this thread that a certain number of readers are colour-blind - surely this could effect ability to judge nuances of colour? (I'm not being disrespectful, by the way, just bringing up a relevant point).
Clare Newsome:Well we've already established in this thread that a certain number of readers are colour-blind - surely this could effect ability to judge nuances of colour? (I'm not being disrespectful, by the way, just bringing up a relevant point).
guilty as charged your honour, give me red and green together, and im all over the place
edit, im also left handed, does that count
guilty as charged your honour, give me red and green together, and im all over the place
edit, im also left handed, does that count
maxflinn:
im also left handed, does that count
Other than making it more likely you'll scrape some skin off your knuckles trying to get HDMI cables/in out of kit designed for the right-handed majority no
Plenty of us sinister types here....
im also left handed, does that count
Other than making it more likely you'll scrape some skin off your knuckles trying to get HDMI cables/in out of kit designed for the right-handed majority no
Plenty of us sinister types here....
There is a detailed report that if people hook their equipment up by their left hand it does make a difference in sound and picture quality.
I think it was the same study with the difference between HDMI cables.
I think it was the same study with the difference between HDMI cables.
Professor, I have never said it is impossible for data to be degraded, please do not imply that I did. What I have said is that claims that one cable will for example have more vibrant colour than another to be unlikely. I am prepared to conceive that a cable allows the data to be corrupted, but the effect would be random, which is not what is reported. A faulty cable can be just as likely to make a colour brighter as duller, but this is never described.
The protocol used by HDMI is described here:
Transition Minimized Differential Signaling (TMDS) is a technology for transmitting high-speed serial data and is used by the DVI and HDMI video interfaces, as well as other digital communication interfaces.
The transmitter incorporates an advanced coding algorithm which reduces electromagnetic interference over copper cables and enables robust clock recovery at the receiver to achieve high skew tolerance for driving longer cables as well as shorter low cost cables.
The method is a form of 8b/10b encoding but using a code-set that differs from the original IBM form. A two-stage process converts an input of 8 bits into a 10 bit code with particular desirable properties. In the first stage each bit is either XOR or XNOR transformed against the previous bit, whilst the first bit is not transformed at all. The encoder chooses between XOR and XNOR by determining which will result in the fewest transitions; the ninth bit is added to show which was used. In the second stage, the first eight bits are optionally inverted to even out the balance of ones and zeros and therefore the sustained average DC level. The tenth bit is added to indicate whether this inversion took place.
The 10-bit TMDS symbol can represent either an 8-bit data value during normal data transmission, or 2 bits of control signals during screen blanking. Of the 1024 possible combinations of the 10 transmitted bits:
TMDS was developed by Silicon Image Inc. as a member of the Digital Display Working Group.
TMDS is similar to low-voltage differential signaling (LVDS) in that it uses differential signaling to reduce electromagnetic interference (EMI) which allows faster signal transfers with increased accuracy. TMDS also uses a twisted pair for noise reduction, rather than coaxial cable that is conventional for carrying video signals. Like LVDS, the data is transmitted serially over the data link. When transmitting video data, three TMDS twisted pairs are used to transfer video data. Each of the three links corresponds to a different RGB component.
The physical layer for TMDS is current mode logic (CML), DC coupled and terminated to 3.3 Volts. While the data is DC balanced (by the encoding algorithm), the DC coupling is part of the specification. TMDS can be switched or repeated by any method applicable to CML signals. However, if DC coupling to the transmitter is not preserved, some transmitters' "monitor detection" features may not work properly.
The protocol used by HDMI is described here:
Transition Minimized Differential Signaling (TMDS) is a technology for transmitting high-speed serial data and is used by the DVI and HDMI video interfaces, as well as other digital communication interfaces.
The transmitter incorporates an advanced coding algorithm which reduces electromagnetic interference over copper cables and enables robust clock recovery at the receiver to achieve high skew tolerance for driving longer cables as well as shorter low cost cables.
The method is a form of 8b/10b encoding but using a code-set that differs from the original IBM form. A two-stage process converts an input of 8 bits into a 10 bit code with particular desirable properties. In the first stage each bit is either XOR or XNOR transformed against the previous bit, whilst the first bit is not transformed at all. The encoder chooses between XOR and XNOR by determining which will result in the fewest transitions; the ninth bit is added to show which was used. In the second stage, the first eight bits are optionally inverted to even out the balance of ones and zeros and therefore the sustained average DC level. The tenth bit is added to indicate whether this inversion took place.
The 10-bit TMDS symbol can represent either an 8-bit data value during normal data transmission, or 2 bits of control signals during screen blanking. Of the 1024 possible combinations of the 10 transmitted bits:
- 460 combinations are used for representing an 8-bit data value, as each of the 256 possible values has two encoded variants (except some values which have one),
- 4 combinations are used for representing 2 bits of control signals (such as HSync and VSync); these combinations have such properties that they can be reliably recognized even if sync is lost and are therefore used also for synchronizing the decoder,
- 560 remaining combinations are reserved and forbidden.
TMDS was developed by Silicon Image Inc. as a member of the Digital Display Working Group.
TMDS is similar to low-voltage differential signaling (LVDS) in that it uses differential signaling to reduce electromagnetic interference (EMI) which allows faster signal transfers with increased accuracy. TMDS also uses a twisted pair for noise reduction, rather than coaxial cable that is conventional for carrying video signals. Like LVDS, the data is transmitted serially over the data link. When transmitting video data, three TMDS twisted pairs are used to transfer video data. Each of the three links corresponds to a different RGB component.
The physical layer for TMDS is current mode logic (CML), DC coupled and terminated to 3.3 Volts. While the data is DC balanced (by the encoding algorithm), the DC coupling is part of the specification. TMDS can be switched or repeated by any method applicable to CML signals. However, if DC coupling to the transmitter is not preserved, some transmitters' "monitor detection" features may not work properly.
professorhat
Well-known member
Okay, thanks for the link. So, I may be missing something, but I gather from this that effectively what it's saying is the data is transformed using XOR so that, for example, 11111111 (or 255 in decimal) would be XORed to 10000000 (as each bit following the first bit is the same number and therefore is changed to a 0). However, what I don't understand is what stops this from being corrupted in transport over the cable to 10001000? When this is translated on the other end, you would then get 11110000 (or 240 in decimal). I may be being stupid (as I'll admit I've not really delved this deep into error checking prior to this), but I really don't see how data being XORed prevents corruption. Unless of course you send both the original data and the XORed data to check it (but this isn't stated above). And even then of course, if one has been corrupted and changed in transit, how can the receiver tell which is correct (if either)? Again, in normal computing terms, this is easy as the data can simply be requested to be resent until the original data and the XORed data agree. But when streaming video, there's not time for this request / resending of data to occur so this can't be relied upon.
hammill:Professor, I have never said it is impossible for data to be degraded, please do not imply that I did.
Whilst I agree you haven't specifically stated this, you have stated that it's impossible for different cables to create a different picture / sound. And if that is the case then, the signal sent in each case must be the same as the one received no matter which cable you use. And if that is the case, then it stands to reason that the signal has not been degraded in transit - this may mean of course data that was corrupted was fixed, but this is what I'm trying to get to the bottom of here!
Please also note, I am enjoying this back and forth and am keen to learn how you can be so sure that cables can't make a difference, so please don't take offence from anything I say. It's nice to be having a civil conversation on this subject for once
hammill:Professor, I have never said it is impossible for data to be degraded, please do not imply that I did.
Whilst I agree you haven't specifically stated this, you have stated that it's impossible for different cables to create a different picture / sound. And if that is the case then, the signal sent in each case must be the same as the one received no matter which cable you use. And if that is the case, then it stands to reason that the signal has not been degraded in transit - this may mean of course data that was corrupted was fixed, but this is what I'm trying to get to the bottom of here!
Please also note, I am enjoying this back and forth and am keen to learn how you can be so sure that cables can't make a difference, so please don't take offence from anything I say. It's nice to be having a civil conversation on this subject for once
professorhat:
Okay, thanks for the link. So, I may be missing something, but I gather from this that effectively what it's saying is the data is transformed using XOR so that, for example, 11111111 (or 255 in decimal) would be XORed to 10000000 (as each bit following the first bit is the same number and therefore is changed to a 0). However, what I don't understand is what stops this from being corrupted in transport over the cable to 10001000? When this is translated on the other end, you would then get 11110000 (or 240 in decimal). I may be being stupid (as I'll admit I've not really delved this deep into error checking prior to this), but I really don't see how data being XORed prevents corruption. Unless of course you send both the original data and the XORed data to check it (but this isn't stated above). And even then of course, if one has been corrupted and changed in transit, how can the receiver tell which is correct (if either)? Again, in normal computing terms, this is easy as the data can simply be requested to be resent until the original data and the XORed data agree. But when streaming video, there's not time for this request / resending of data to occur so this can't be relied upon.
hammill:Professor, I have never said it is impossible for data to be degraded, please do not imply that I did.
Whilst I agree you haven't specifically stated this, you have stated that it's impossible for different cables to create a different picture / sound. And if that is the case then, the signal sent in each case must be the same as the one received no matter which cable you use. And if that is the case, then it stands to reason that the signal has not been degraded in transit - this may mean of course data that was corrupted was fixed, but this is what I'm trying to get to the bottom of here!
Please also note, I am enjoying this back and forth and am keen to learn how you can be so sure that cables can't make a difference, so please don't take offence from anything I say. It's nice to be having a civil conversation on this subject for once
I am enjoying it too and am not offended. I have no axe to grind, I simply dont understand how HDMI cables differences can be as described given my (perhaps flawed) understanding of the technology.
Regarding XOR, of course I do not suggest that in itself could prevent errors (although the explanation does suggest it is sent in this seemingly obscure way to reduce errors). I am suggesting that errors will result in data that is not simply one bit away from the original.
Okay, thanks for the link. So, I may be missing something, but I gather from this that effectively what it's saying is the data is transformed using XOR so that, for example, 11111111 (or 255 in decimal) would be XORed to 10000000 (as each bit following the first bit is the same number and therefore is changed to a 0). However, what I don't understand is what stops this from being corrupted in transport over the cable to 10001000? When this is translated on the other end, you would then get 11110000 (or 240 in decimal). I may be being stupid (as I'll admit I've not really delved this deep into error checking prior to this), but I really don't see how data being XORed prevents corruption. Unless of course you send both the original data and the XORed data to check it (but this isn't stated above). And even then of course, if one has been corrupted and changed in transit, how can the receiver tell which is correct (if either)? Again, in normal computing terms, this is easy as the data can simply be requested to be resent until the original data and the XORed data agree. But when streaming video, there's not time for this request / resending of data to occur so this can't be relied upon.
hammill:Professor, I have never said it is impossible for data to be degraded, please do not imply that I did.
Whilst I agree you haven't specifically stated this, you have stated that it's impossible for different cables to create a different picture / sound. And if that is the case then, the signal sent in each case must be the same as the one received no matter which cable you use. And if that is the case, then it stands to reason that the signal has not been degraded in transit - this may mean of course data that was corrupted was fixed, but this is what I'm trying to get to the bottom of here!
Please also note, I am enjoying this back and forth and am keen to learn how you can be so sure that cables can't make a difference, so please don't take offence from anything I say. It's nice to be having a civil conversation on this subject for once
I am enjoying it too and am not offended. I have no axe to grind, I simply dont understand how HDMI cables differences can be as described given my (perhaps flawed) understanding of the technology.
Regarding XOR, of course I do not suggest that in itself could prevent errors (although the explanation does suggest it is sent in this seemingly obscure way to reduce errors). I am suggesting that errors will result in data that is not simply one bit away from the original.
professorhat
Well-known member
hammill:I am suggesting that errors will result in data that is not simply one bit away from the original.
Yes, I do see where you're coming from on this now as change of one bit on the XORed data could have dramatic changes when translated at the other end. Since this doesn't happen though, I have to assume something else is going on to prevent that which we're missing!
So at the moment, no further to a solution either way unfortunately!
Yes, I do see where you're coming from on this now as change of one bit on the XORed data could have dramatic changes when translated at the other end. Since this doesn't happen though, I have to assume something else is going on to prevent that which we're missing!
So at the moment, no further to a solution either way unfortunately!
Similar threads
TRENDING THREADS
-
I'm a LiAV(!) and the future is Not Vinyl or CD, it's DAC / Streaming, what do yo think?- Started by Jasonovich
- Replies: 43
-
-
-
-
-
-
Facebook
Twitter
Instagram