Hand Made SATA Cable for CAT

Status
Not open for further replies.
Disabled Account
Joined 2006
Well Im sure of myself, care to visit me and I prove it to you, to make better odds Id insist on 100 files being tested, after being copied for 10 times over Id stake my electrocompaniet nemo as prize if I score less then 98 out of 100. If i score 98 or more you purchase me another of these beauties. Any takers ??? DBT bring it on. Ive used DBT to expell some myths by audiophools but regarding this DBT doesnt stand a chance. Try it.

The effect was brought to my attention by DJs I give jobs too, I dont use MP3s for myself. Ive had more than 30 do jobs for me and far more than half insist on orginal downloaded copy, direct to their pcs, imagine my surprise when told the reason for this.

Care to try answer the first one.
 
damm i came to Diy audio to get away from computer geekness.

You are in the "PC based" section of DIY Audio.

the only explanation i have at the moment is error correction getting things wrong . Only 1s and 0s not hard to understand . When we play a digital music file we are not able to use a checksum to detect errors so the error correction must make a guess to the missing bit being a 1 or a 0. Now that is easy to get wrong . the more error correction the more errors in the music file .

Once ripped from CD-Audio, a file with audio data is just like any other file.

The error correction is in the HDD, in the SATA controller, even some filesystems have a built-in checksums correction (e.g. ZFS). The audio software does no error correction, it assumes correct data. There is no room for data corruption of audio only. If your executables are unaffected by copying, so will your audio files. The underlying hardware cannot differentiate.

Actually, FLACs can be checksum-checked. But the claim above talks about hearing FLACs deteriorating sonically too. Definitely not by data corruption. IMO the deterioration does not in fact occur at all, it is only in our heads. Until someone proves me wrong which I doubt, so far nobody has ever published credible test results.
 
Well Im sure of myself, care to visit me and I prove it to you, to make better odds Id insist on 100 files being tested, after being copied for 10 times over Id stake my electrocompaniet nemo as prize if I score less then 98 out of 100. If i score 98 or more you purchase me another of these beauties. Any takers ??? DBT bring it on. Ive used DBT to expell some myths by audiophools but regarding this DBT doesnt stand a chance.

Why don't you describe us your test scenario and objective results you honestly stand behind.
 
On the issue of linux and windows . I made an obsevation some time ago . Windows XP seems to make the hard drive more mechanicaly noisey than in linux . Anyone else noticed this. Surley as said it must have somthing to do with Hardware drivers as the hardware was the same used for linux and windows.

Regards Ian

Possible reasons:

* windows filesystem more prone to fragmentation, the head travels larger distances

* windows filesystem more filled/filled with larger files, leading again to larger fragmentation

* windows accessing the HDD more often, worse block device caching

* windows using more RAM, utilizing swap file

* windows swap is file-based, unlike most linux partition-based less-fragmented swaps

etc, etc.

My netbook in windows keeps trashing the HDD constantly. Looking for time to reinstall to linux, it will relieve the HDD a lot.
 
Disabled Account
Joined 2006
I have done so, take a music file be it flac or mp3, copy and then move it over and over from one harddrive to another, memory sticks can be used as well, return the copy of the file used in the last drive where it was moved to, to the original harddrive, check number of bits to be the same as the original copy left behind on the drive and then compare with listening results.
 
Disabled Account
Joined 2006
Offcourse, I can easily discern between the two files, which I shouldnt be able to do. Like I said this was brought to my attention by others, people who use thousands of these type files. Instead of me proving them wrong, they proved me wrong or lets say I proved myself wrong.
 
Last edited:
Disabled Account
Joined 2006
So you don't really need someone to visit, just some data files which you could presumably sort?

I could email you some files, one original and one copied over a few times but with exact same bits if nothing goes wrong during the email sending and then you could judge by yourself. To verify that Im not cheating or using a different file which could have same size or doing any other type of tampering a visit would be required.
 
Tell you what, how about you email me a couple of files (or if they're too big, they could be put up in a dropbox). I'll make a disc or memory stick with ten files on it, 5 of each of the two you send, coded and randomized, then send them to you. I will provide the key to someone else. Then see if you can sort them. Does that work for you?
 
Disabled Account
Joined 2006
Could be done but youre forgetting the changing of the original file from one hardrive or memory stick over a couple of drives, then you could send the file which was gotten over the last move to me. Its the moving of the file around that I find deteriorates the sound heard although the file is unaltered according to size. You could do this with just one of the files and see if I can differentiate between the original file sent and a file that has been copied over a couple of times and versus files that have only been moved once.

I dont quite understand how youd want me to sort them, the original from the copies ??
 
It's possible that I don't understand your claim.

I would:
Put the original file on the stick. Call it A. On the same stick, clone 4 more copies of A. Now, bring A up to my hard disk, copy back and forth ten times, put that on the stick. Call it B. Clone 4 more copies of B on the stick. Verify that A and B are bit identical (very likely with standard file systems). Now, rename all the files with random codes, and remove the time stamps. Send you the stick. Send someone else the key, i.e., which codes correspond to A and B.

You would:
Sort the codes into two groups- you wouldn't have to tell me which groups are the originals and which are the 10x copies, you just need to be able to say, "These five are the same as one another, these other five are the same as one another and different from the first group." Post your answer.

The person with the key would then post the correct answers.
 
check number of bits to be the same as the original copy left behind on the drive and then compare with listening results.

I find deteriorates the sound heard although the file is unaltered according to size. You could do this with just one of the files and see if I can differentiate between the original file sent and a file that has been copied over a couple of times and versus files that have only been moved once.
what is the bit check you are doing?

Could you Email a couple of files, that you find sound different so that those that can can check if the files are the same. That's a different check from adding up the bits.
 
If the files are the exactly the same I would love to hear some explanation as to how they can be different, sound wise. Funny this doesn't happen with other digital data, such as CAD files, more magic that only can be heard! There are plenty of binary file comparision programs available on the web...
Of course this then causes me to woory about all the places CRC's are used such as the internet, and where digital systems are used for control etc.
So anyone, why does this digital magic only happen in the Audiophile world and why when we build things like CERN, can it only be detected by ears?
 
Well, first let's find out the facts. Are the files (original and multicopy) actually the same? If so, can hm sort them? I would certainly give an overwhelming probability to "yes" and "no," respectively, but it's such an easy experiment to do, why not? We can worry about explanations after the fact is demonstrated (if it is).
 
AFAIK only one wrong bit in an mp3 will create an audible click and no change in sound. If not in the header of cause.

Edit: Most likely it wouldn´t be to decrompress at all. The player may spit out a decoding error even for this 1 bit. Of cause some decode thru errors but this broken bit will be an clearly audible click or stutter.
 
Last edited:
We can worry about explanations after the fact is demonstrated (if it is).


You will not have to worry, it will never be demonstrated. Just as it has never been. Just read any discussion forum. The "hearers" never get to the point of proving they can actually do what they claim to be miraculously capable of, with some shiny exceptions that prove the rule. BTW the topic of identical files sounding different is a hit these days, stirred by one incompetent article :)

Ripping Software Comparison | Computer Audiophile

Computer Audio Asylum
 
I can differentiate between the original file sent and a file that has been copied over a couple of times and versus files that have only been moved once.



Is it at all possible that multiple copies result in a more fragmented file and this indirectly increases ps related jitter when reading? Or that some hdd areas are just easier to read than others. Not quite sure if it's easy to check for fragmentation of a particular file or if any hdd utilities allow writing a file to pre-determined sectors, so each subsequent copy gets written to the exact same physical location. It is also possible you may be hearing some secondary effects which just happen to occur after a copy. Like a cache gets full and needs flushing once reproduction begins. Who can possibly tell? Operating systems are complicated beasts these days and what seems like an innocuous operation may have unexpected side effects. Must be easy to find a program which once executed will mess up PC playback until restart.

Surely none of this can in any way be connected to the file and data contained in it. The notion of actually emailing such files (and especially to SY) i find deeply humorous.
 
Status
Not open for further replies.