Power cables test

[Nathan]

Ok so as promised I have done a power cable test that does not rely on the ear. The principle at test was this:

A CD player will read the disc and transmit what it reads as a digital stream. The receving unit will then do something with that. In the case of a DAC it will convert it to an analogue signal and send it to an amp and then to the speakers. If the receiving point is a computer though the resultant stream of data can be saved instead of being converted and hashed.

Different CD players will read the file slightly differently, picking out additional details - this is why the sound from different CD players is different. If it wasnt then the resulting data stream that the DAC receives would give the same sound regardless of whether it is a £20 CD player or a £10,000 one. So, if we save the digital data stream then we can hash the file to get its fingerprint. The format that we save the file in is irrelevant - be it wav, flac, mp3. As long as the compression algorithm is constant the hash of the resulting file will always be the same if the incoming digital stream is the same every time. However, I chose to save the file as an uncompressed wave file.

So, if two power cables can alter the output of the CD player then the resultant digital stream must be different for each. So the test is simple: get a CD to read a file, send it as a digital signal to a computer which will then save it. To make sure that the CD player is working consistently I performed the rip three times with the first cable and then three times with the second cable. The test track was first saved three times using a stock power cable and each resulting file was hashed using MD5. I then swapped for a Kimber power cable (£100) and re-ran the test three times.

The Result

Well the result was fairly conclusive. The hashes for the three copies made with the stock cable matched so we know that the CD was consistently reading the disc. The hashes for the three copies made with the upgraded cable were also the same so the CD was still reading consistently with the upgraded cable. However, all six hashes were identical as can be seen below:-

Conclusions

So what does this prove? Well what I have done is keep everything constant except the power cable. If the cable were to make a difference such as causing the CD player to provide a better read then the hashes between the two sets of three files would not match. The fact that they do shows that by changing the power cable makes no difference whatsoever to the resultant digital output. Now, I would stress that this only tests the effect on a CD player. Once the digital file is received by the DAC and converted to an analogue signal, an upgraded power cable may make a difference to that resulting signal but I have no easy way to capture and hash an analogue output.

As a final point I re-did the test with a different CD player and got a different hash - although the hash was still the same for all six tests. This shows that different CD players can result in a different digital read of the disc (which is as expected) but once more the power cable has no effect.

 

[shadders]

Hi,

All CD players read the data the same - the second CD player used which provided a different file, and hence different checksum, may be providing additional data which is not sound data (or vice versa). If you were to examine the file (wav file) for both CD player outputs, the core data will be the same. As such - each CD player will be presenting the same data to the internal DAC chip.

The claims by the power cable manufacturers is that the RF energy which appears on the mains supply affects the CD player internal clock mechanism, which causes extra jitter. Their statement is, if you use their cable, it reduces significantly the RF energy on the mains appearing at the power input of the CD player, which negates this extra jitter in the clock.

If their cable is just that - a cable with no filter, then this claim is not valid.

If their cable includes a filter, it may be possible that the cable will reduce the RF energy. Most cables do not have a filter - each manufacturer will state there is a filter if one is part of their cable.

The equipment, such as a CD player will have all the necessary filters designed into the product as standard. The power supply components by their very design and circuit topology, will be a natural low pass filter.

I would expect that there is significantly more RF energy from peoples wifi, cellular phone, dimmer switch, cable TV, satellite dish downlink cable, appearing within CD player, than that introduced into the CD player by the mains using a normal cable.

Regards,

Shadders.

 

[andyjm]

Nathan,

I don't think that even the 'true believers' think that mains cables effect the bit error rate when reading a CD. As Shadders explains, the claims are more subtle than that and are related to bitstream jitter and RF energy injected into the replay chain. Nonsense in my opinion, but those are the claims.

CDs are remarkably good, and although errors do occur, the error correction techniques employed on the disk seem to catch nearly all of them. Having ripped 100s of CDs on a pretty mediocre PC, (and I guess budget CD spinner inside it), I can only recall two or three disks that failed dBPoweramp's checksum test - and those CDs were pretty beatup.

The reason you are getting a different hash between players is that unlike a yellowbook CD ROM, a redbook CD spinner seems to be a bit vague about where to define the start of the track. This is the 'drive offset' parameter in dBPoweramp which allows for drives that insert a few extra (or less) bytes at the beginning of the track. It doesn't effect the music data, that is later in the file, but it does mean you end up with a different hash.

If you want to do the test properly, then test the claim - 'changing mains cables makes an audible difference'. Get a copy of Audiodiffmaker (free) and record the before and after output of the downstream DAC using a soundcard. Any change will be picked up by diffmaker, no change will produce a null file.

 

[Nathan]

Thanks guys - all interesting comments. Personally I did not know whether the different cables would make a difference. If the pro-upgrade view was correct in that it had a effect on the CD player - be it the clock or anything else - then there should be a difference in the output. There isn't though. So RF interference or anything else seems to have been taken out of the equation. The digital stream of the output is the output. If that is constant then there is either no interference or it has no impact whatsoever on the output. Having seen people claim that the upgraded cable help the sound produced by the CD player, this seemed the place to start on the test - and it is the easiest.

It does raise a different question though. As mentioned above the hash differences may be due to the CD player having a different start point. This could be checked using a hex viewer on the files by examining the data well into the files to see if the 'middle' bits are the same. Personally I would hope that this is not the reason. If the difference in the file hash is a few zeros at the end or the beginnning then expensive CD players are a bigger waste of money than the cables! Something I don't believe and I'm pretty sure no one does. I will have a look at the hex in due course as a side point.

However as mentioned above, piping the analogue stream post DAC into a sound card and comparing that when the cables are changed is a valid test of if there is a 'sound' difference. In fact a feed from the headphone socket on the amp to the mic on the computer should do this. Hashing the file won't work though as the start/stop point won't be the same each time as that's a manual process. But if the hex from a few seconds in until a few seconds before the end are looked at that would a valid test. Both samples would capture that part and if the hex differs from power cable to power cable then we have a difference caused. Longer test but I will work on that next. If anyone sees a problem with this method, shout now!

 

[andyjm]

As mentioned above the hash differences may be due to the CD player having a different start point. This could be checked using a hex viewer on the files by examining the data well into the files to see if the 'middle' bits are the same. Personally I would hope that this is not the reason. If the difference in the file hash is a few zeros at the end or the beginnning then expensive CD players are a bigger waste of money than the cables! Something I don't believe and I'm pretty sure no one does. I will have a look at the hex in due course as a side point.

Nathan,

Google 'CD drive offset'.

As far as I can tell, the issue dates back to the original design of CDs when players were simple hardware devices that couldn't handle complex files or a directory structure. As such, the tracks aren't stored on an audio CD with defined hard start and stop points in the same way a data file is organised on a PC hard drive or CDROM - there was no need. As long as the player got to within a few millseconds of the track start, it was probably close enough.

 

[andyjm]

However as mentioned above, piping the analogue stream post DAC into a sound card and comparing that when the cables are changed is a valid test of if there is a 'sound' difference. In fact a feed from the headphone socket on the amp to the mic on the computer should do this. Hashing the file won't work though as the start/stop point won't be the same each time as that's a manual process. But if the hex from a few seconds in until a few seconds before the end are looked at that would a valid test. Both samples would capture that part and if the hex differs from power cable to power cable then we have a difference caused. Longer test but I will work on that next. If anyone sees a problem with this method, shout now!

Nathan,

This type of test is generally referred to as a 'null test'. You don't have to know what you are testing for, but if the two tracks (before and after a change) null, then you can be pretty sure there has been no change. If they don't null, then it won't tell you what has changed, but you can be sure there is a difference.

To do it properly, you need to level match and time align the before and after recordings. The software I mentioned, 'Audiodiffmaker' is designed to do exactly that. It has been a long time since I have used it, but it was free to download.

Edit: Just checked, the software is still available, but quite old now - I dont know if it will run on current OS. There is a link to the paper presented to the AES that explains it. Just google 'Audiodiffmaker'.