Hmm someone has never booted Linux from an iso image then. OS loads and runs from CD. Same bits each time.
I have many times.
Hmm someone has never booted Linux from an iso image then. OS loads and runs from CD. Same bits each time.
Yeah, or booted from a win PE recover disk. Or any other of the many things you might boot and run from... We are wasting our time, I think!!
I have many times.
Hopefully you can help Leadbelly understand then!
Hmm someone has never booted Linux from an iso image then. OS loads and runs from CD. Same bits each time.
Generally after queueing up what it absolutely need, it lazy loads the remainder of the needed apps into memory.
Perhaps that's a little too detailed? 😀
Generally after queueing up what it absolutely need, it lazy loads the remainder of the needed apps into memory.
Perhaps that's a little too detailed? 😀
More comical than that: An iso image? And what's on the iso image, the raw executables, or a bunch of archive files with a loader? 😀
All depends what u think is different between an executable and an archive other than the archive is compressed?
All depends what u think is different between an executable and an archive other than the archive is compressed?
Is this demagoguery? A compression is a bit perfect copy with the executable? The compression algorithm cannot recover from bit errors?
Do you understand the difference between anecdote and direct evidence?
When listening to it thru an outboard DAC? It's dramatically different to what other transports?
OK, Dan, lets look at that. Many here would say that you are imagining the difference, but I'll take you at your word, that you hear a dramatic difference using this transport vs any other into the same DAC. Why or how could that be? I seriously doubt it has anything to do with bit perfection, but is more likely other factors. In no particular order.Yes. To get slightly off track, it's been my experience that power supplies can make a significant difference in audio.
- Your DAC receiver may not be all that good at recovering the SPDIF clock
- The Shin may have a higher voltage SPDIF signal than the other transports.
- It may have more drive current on the SPDIF signal (unlikely)
- The Shin may have a worse SPDIF signal, causing clock problems in the DAC. That can be noticeable.
- The Shin may have lower analog noise or an absence of ground problems that could get carried over SPDIF coax to the DAC.
- It may have higher noise than other transports, and you hear that. (noise isn't always bad)
All depends what u think is different between an executable and an archive other than the archive is compressed?
You'll never get through to the dedicated conspiracy theorist. The moon landings were faked too, you know... 😀
I go to Clinton, IA pretty regularly. If you'll permit me to set up the test blinded, I'd be happy to go out of my way to visit. I'll bring beer.
If you mean You will set up which transport is connected to the digital jack 1 or 2 on the DAC I have no problem with that. I figured that would be a given. How else would it be a blind test? Like I said you will control which transport is spinning. A screen will be set up to prevent me from seeing the transports or what you are doing/changing when switching from one transport to other.That would include you picking the same transport in repeat succession.
Before we start the actual ABX test I would guess you would want to listen to each transport on my system first. Starting with which ever transport you would like to listen to first. I would suggest you bring a few CDs you are familiar with. After the test You might want compare your CDs to the Arcam and the Marantz.
Is it possible we could do it on a Saturday? I know My Son would like to be here as well.
Jim
.
Most of the stuff on a distribution is libraries - executable code which is called by executable programs. Don't fall into the naive trap of thinking that only .exe files contain code.leadbelly said:Guess what, take a look at a software distribution CD or DVD from a major software publisher. Why there's hardly any executables on it? A lot of big files with the same extension. I guess these are archive files. Hmm, I wonder if during the hours it takes to install software on a computer that would take minutes to copy, while the installation program extracts these executables from their archive files, and seems to take an unreasonable amount of time to do it, if maybe the publisher put some elaborate checksum system in it to fix damaged archive files? You know that ancient stuff from the 60's.
Extracting from an archive, as far as I know, (I only worked in IT for 22 years) does not repair damaged files.
You asked a silly question, which I assumed was based on significant ignorance of computer systems. If correct loading of software from a CD required software to correct errors then you have created a bootstrap problem for bootable CDs.If you don't have the mental acuity to distinguish between some of what is argued, that this hypothesis has been directly tested by Pano and others, and the balance of what is argued, that "Oh look Windows installed from a copy of the CD, it must be bit perfect", then maybe you shouldn't be so condescending.
Not a problem, my wife loves day trips and is a big fan of Des Moines (she just had an exhibition there and had a great time in the city). It's more important that you have CDs that you know and are comfortable with, especially anything where you think you pick up the differences quickly. Mine would only be for entertainment. 😀
Randomized switching (determined in advance by coin flips), with a key sheet that can be held out of both our reach. Other than that, it's up to you- we can do A-B preference, A-B-X, triangle, whatever. You're in control of source material, volume, length of selections, everything other than which unit is playing as the variable (in an A-B-X format, you can switch to A or B on demand, if your ears need refreshing).
Kudos to you for being willing to put your beliefs to the test.
Randomized switching (determined in advance by coin flips), with a key sheet that can be held out of both our reach. Other than that, it's up to you- we can do A-B preference, A-B-X, triangle, whatever. You're in control of source material, volume, length of selections, everything other than which unit is playing as the variable (in an A-B-X format, you can switch to A or B on demand, if your ears need refreshing).
Kudos to you for being willing to put your beliefs to the test.
Bit errors in a compressed image would be harder to deal with as there is less redundancy - that is how compression works. Hence the fact that even compressed images can be read correctly from a CD is further evidence that CD reading is bit-perfect.leadbelly said:Is this demagoguery? A compression is a bit perfect copy with the executable? The compression algorithm cannot recover from bit errors?
Bit errors in a compressed image would be harder to deal with as there is less redundancy - that is how compression works. Hence the fact that even compressed images can be read correctly from a CD is further evidence that CD reading is bit-perfect.
Not necessarily. Again we're talking about streaming vs. burst reads to error correct. They're rather different.
Listen to a computer disc drive, notice that it makes a lot of noise and will go in and out of making louder noise for example while installing something. It operates at very different speeds, and doesn't have to keep a sync with a, limited by time, buffer. As long as the transport doesn't utterly lose track of where it's at, it'll move past the error before it's corrected if time runs out. Can you hear it? Probably not. Again, I'm not trying to say transports sound different due to tiny loss of bits. If they sound different I bet it has considerably more to do with their noise floor, common mode issues, etc.
I have one of the first generation Shigaclone controllers, and one of the second generation controllers.
I also have six transports including SF-P101N and I believe DA11VZ.
I have two DACs, (1) CS8416/CS4398, and (2) WM8741.
The Shigaclone uses 75 Ohm series termination and 75 Ohm termination to ground at the driver. Both DACs use 75 Ohm termination to ground at the receiver. The WM8741 input is capacitively coupled to 74HCU04 biased in the linear region, followed by additional stages to clean up the edges before sending the signal to the receiver. The CS8416/CS4398 capacitively couples the signal straight into pin 4 of the CS8416 per the data sheet.
One of the transports is way out of spec for rotational eccentricity which is specified at 0.06mm max. This unit is out by an estimated 0.5mm, possibly more. It is so bad the whole transport shakes when spinning. One can watch the servo mechanism tracking the eccentricity.
I can tell no difference between either of the Shigaclone boards, with any of the six transports including the defective one.
I can tell the difference between the DACs.
I also have six transports including SF-P101N and I believe DA11VZ.
I have two DACs, (1) CS8416/CS4398, and (2) WM8741.
The Shigaclone uses 75 Ohm series termination and 75 Ohm termination to ground at the driver. Both DACs use 75 Ohm termination to ground at the receiver. The WM8741 input is capacitively coupled to 74HCU04 biased in the linear region, followed by additional stages to clean up the edges before sending the signal to the receiver. The CS8416/CS4398 capacitively couples the signal straight into pin 4 of the CS8416 per the data sheet.
One of the transports is way out of spec for rotational eccentricity which is specified at 0.06mm max. This unit is out by an estimated 0.5mm, possibly more. It is so bad the whole transport shakes when spinning. One can watch the servo mechanism tracking the eccentricity.
I can tell no difference between either of the Shigaclone boards, with any of the six transports including the defective one.
I can tell the difference between the DACs.
Is this demagoguery? A compression is a bit perfect copy with the executable? The compression algorithm cannot recover from bit errors?
Do you understand the difference between anecdote and direct evidence?
It would appear you honestly believe what you wrote there. I have evidence. I spent a good portion of my days staring at terminal windows and debugging horribly complex systems. When you zip/tar/gzip etc then unzip a bit error will not be corrected. However it will cause the checksum to fail and the extract to be aborted.
I have once encountered a case where copying a file from one machine to another corrupted it, but the embedded machine died before I could find out exactly what it was doing. I did keep the file tho which oneday will fire up in audacity to see what went wrong.
I propose the ultimate blind test. A DCS Vivaldi transport Vivaldi CD/SACD Transport | dCS versus an Ebay Teac transport Teac CD P650 CD Player Transport W Remote Idevice USB Input CDP650 $300 List 043774026128 | eBay. DAC to be decided. Ten seats at $1K per seat. If you can consistently tell the difference between the two in four blind tests your seating fee will be refunded. If there is no audible difference then your seating fee will be donated to science.
Regards,
Dan
Regards,
Dan
Last edited:
Not a problem, my wife loves day trips and is a big fan of Des Moines (she just had an exhibition there and had a great time in the city). It's more important that you have CDs that you know and are comfortable with, especially anything where you think you pick up the differences quickly. Mine would only be for entertainment. 😀
Randomized switching (determined in advance by coin flips), with a key sheet that can be held out of both our reach. Other than that, it's up to you- we can do A-B preference, A-B-X, triangle, whatever. You're in control of source material, volume, length of selections, everything other than which unit is playing as the variable (in an A-B-X format, you can switch to A or B on demand, if your ears need refreshing).
Kudos to you for being willing to put your beliefs to the test.
Sounds great!
The only thing I ask of you is to post the results of the test here on this thread after words.
I will figure out how to send you a pm in the morning, with my address and phone number. We can work out the date and time then.
Jim
.
I got some information from guy who actually knows what he's talking about.
Typical CD players do not have a buffer. But they can re-read without the human ear noticing it. But generally it just interpolates missing bits here and there, and re-reads when it can't. Hence, not bit perfect. If the scratch or such is large enough you may get an audible representation as it can't re-read it to fool you.
A music CD has one set of bits, that's all, in a stream. Rom data on the other hand repeats in adjacent sectors. That's why it's so much easier to get better reads on data discs than audio, and faster with the type of reading that occurs. Think about it, computer drives have buffers, and they can burst read multiple adjacent sectors to compare with a ton of re-reads. They're superior in bit-perfection aspects.
He believes a good transport is important.
Typical CD players do not have a buffer. But they can re-read without the human ear noticing it. But generally it just interpolates missing bits here and there, and re-reads when it can't. Hence, not bit perfect. If the scratch or such is large enough you may get an audible representation as it can't re-read it to fool you.
A music CD has one set of bits, that's all, in a stream. Rom data on the other hand repeats in adjacent sectors. That's why it's so much easier to get better reads on data discs than audio, and faster with the type of reading that occurs. Think about it, computer drives have buffers, and they can burst read multiple adjacent sectors to compare with a ton of re-reads. They're superior in bit-perfection aspects.
He believes a good transport is important.
Last edited:
- Status
- Not open for further replies.
- Home
- Member Areas
- The Lounge
- Ping: John Curl. CDT/CDP transports