Linear Powered Rips & flash drives sound better - Alex was right !

[miguelito]

So what I take from this is you don't trust your ears either. Don't know of any other viewpoint one could take.

I trust my ears will perceive most real differences in the music. If you tell me that 51% of the time I will here a better voice rendering if I stand on my head and breathe lightly, I will tell you I pass.

[prot]

So what I take from this is you don't trust your ears either. Don't know of any other viewpoint one could take.

 

I dont trust Miguelito's ears either . Dont trust yours. Dont trust mine.

 

Trustyourears is fine for matters of preference but almost useless for *proving* something.

 

Trustyourears isn't even literally true cause you actually hear with your brain. And your eyes influence the brain more than any other sensor...and visual input can easily override any other sensorial input. Btw, that's the reason for the B in DBT.

 

I trust logic...scientifically & mathemathically proven theories...calibrated instruments...and there is quite a long list of stuff that comes before trustyourears. Including trustyourbrain, eyes, feet, etc. Although highly sophisticated, hearing is actually one of the least precise and most gullible senses...and not particularly well studied/understood...and according to many knowledgeable ppl, not particularly well suited for music since its evolutionary purpose was very different...and audio memory (few secs only) is the shortest and least precise of all your sensorial memories...and, and, and...

 

In my book the "I trust my ears before all else" attitude is a clear sign of ignorance. If one doesnt know any better of course he's gonna trusthisears.

 

Oh well, lets just say thats just like my oppinion and there is no need to argue.

[Jud]

Oh, I'm much more rigorous when it comes to theory than "Don't trust your ears." I don't trust anyone's supposed "logic" either, unless it's peer reviewed.

 

When it comes to practical purchasing decisions, I tend to do months or years of prior research unless we're talking small dollar amounts. Once I've narrowed the list of candidates, then yes, I do trust my senses for the final decision - hearing for audio, vision for TV, touch for beds and chairs, etc.

 

Miguelito and prot, the mechanism I'm thinking of (and that I believe John Swenson was talking about) is different than either of you has described. I'll discuss it more fully, probably tomorrow.

[Jud]

I hope she's not reading this forum...

 

Inelegantly said, I must admit.

 

Translated, it means "If you think my wife cares about my opinion overmuch, especially if it might lead to my spending our money on foolishness, you've obviously never met her."

[jhwalker]

I'm a scientist by training (PhD in physics). I do not believe that there's anything we are discussing here that does not have a physical explanation (excluding listener-specific aspects such as physiology, psychology, preference).

 

I think 1's and 0's of a data packet are "absolute" in the mathematical sense - and two identical files are identical. However, once it comes to hardware, a particular sequence of bits might cause a drain in the power rails that results in a 1 interpreted as a 0 and so on and so forth - but I think it's important to distinguish these two situations - a file is a file and any uncertainty in the file content (such as a 1 flipping to a zero) is an anomaly and I don't think this is what we are considering here.

 

I am excluding cases where we see file/memory corruption - I don't think this is what we are talking about here.

 

. . . and the type of "sounds different" Alex and others are describing would require literally millions of 1s and 0s to "flip", not just one or two (which would probably be completely inaudible - or at least very transient). Plus we've already agreed all the 1s and 0s are the same, as proved by identical hash calcs, so . . .

[prot]

.

Miguelito and prot, the mechanism I'm thinking of (and that I believe John Swenson was talking about) is different than either of you has described. I'll discuss it more fully, probably tomorrow.

 

If you (or anyone) could come up with a reasonable expl for this stuff, you got my full attention.

Based on my previous exp as IT-guy and audio-forums reader, I highly doubt this is anything but another deluded/mistaken audiophile thread. Wish you luck though.

[sandyk]

. . . and the type of "sounds different" Alex and others are describing would require literally millions of 1s and 0s to "flip", not just one or two (which would probably be completely inaudible - or at least very transient). Plus we've already agreed all the 1s and 0s are the same, as proved by identical hash calcs, so . . .

 

Not at all. What I hear with each further improvement in the PSU area is more like a removal of a fine veil, which appears to improve low level HF detail and higher order low level harmonics. I think that the JS fan controller for the Mac Mini has been reported as doing something similar (lifting a fine veil)?

[Jud]

. . . and the type of "sounds different" Alex and others are describing would require literally millions of 1s and 0s to "flip", not just one or two (which would probably be completely inaudible - or at least very transient). Plus we've already agreed all the 1s and 0s are the same, as proved by identical hash calcs, so . . .

 

I'm kind of amazed that this many decades after the main causes of distortion in digital audio were the subject of numerous AES and academic papers, and this information made its way into the popular press, the first thing people tend to think of is the virtually impossible scenario of altering 1s and 0s wholesale. Under the laws of probability, flipping bits will get you better music, rather than nasty and very evident ticks/pops, some time after the heat death of the universe. In other words, ain't gonna happen. So no bit flipping. As I'll go on to explain in another comment, the only plausible mechanism I can think of is jitter.

[Jud]

If you (or anyone) could come up with a reasonable expl for this stuff, you got my full attention.

Based on my previous exp as IT-guy and audio-forums reader, I highly doubt this is anything but another deluded/mistaken audiophile thread. Wish you luck though.

 

Hey, from "physically impossible" to "highly doubt" is progress, as far as I'm concerned.

 

Really, skepticism is a good thing (as long as it's not a reflex substitute for deeper thought).

[sandyk]

As I'll go on to explain in another comment, the only plausible mechanism I can think of is jitter.

 

That appears to be a distinct possibility. Low level wideband noise has also been reported elsewhere by an E.E. to be generated by a certain type of Jitter. I doubt that I can find the reference again though .

[alfe]

I'm kind of amazed that this many decades after the main causes of distortion in digital audio were the subject of numerous AES and academic papers, and this information made its way into the popular press, the first thing people tend to think of is the virtually impossible scenario of altering 1s and 0s wholesale. Under the laws of probability, flipping bits will get you better music, rather than nasty and very evident ticks/pops, some time after the heat death of the universe. In other words, ain't gonna happen. So no bit flipping. As I'll go on to explain in another comment, the only plausible mechanism I can think of is jitter.

 

And now we are back to the other thread "can the jitter be imbedded in digital file" if it's Yes than Alex is not a mistaken audiophile ¨-)

Digital data are periodic samples of voltage and the magic word is periodic,so if there is no timing for a digital file what about samples?

[Jud]

So, a shot at a plausible mechanism:

 

Back in 1991, Ed Meitner and Robert Gendron presented an AES paper showing how a very slight change in the reference voltage of the source will cause jitter in the signal. I don't have access to the paper itself, but a figure from that paper which IMHO does a really wonderful job of presenting the phenomenon in intuitive visual form is shown as Figure 1 here: http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf . Please take a moment to follow the link and have a look at it.

 

Remember now the earlier discussion regarding whether variations in signal strength values could be preserved in flash memory. We wouldn't be talking about variations large enough to flip bits, because as I think we all grant, bit flipping would be audibly evident and nasty-sounding. Rather, we'd be talking about relatively small variations in signal strength that would be of the same proportion as tens or hundreds of picoseconds of jitter are to a sampling rate of 44.1kHz. John Swenson, an electrical engineer and audio designer, whose day job experience (as I've mentioned before) appears highly relevant to this issue, says such signal strength variations can indeed be stored as tiny variations in field strength at the storage locations. So let's grant this possibility for the moment.

 

Now let's consider the ripping process. Say the power supply for the disc drive is electrically noisy, resulting in noise on ground. When signal strength of a bit is evaluated against that noisy ground, it will be evaluated as slightly diminished from its "true" value, i.e., the amplitude of the signal will not be evaluated against a zero ground but against a ground that has a level of "signal" on it. The effect will be to make the signal strength of the bitstream look like that Figure 1 we saw earlier, i.e., the bitstream will behave as if it had some amount of jitter added, just as Meitner and Gendron found over two decades ago. If these slightly diminished signal strength values are then stored as memory locations with slightly diminished field strength, this jitter will in effect be preserved in memory.

 

Remember, I'm just talking about plausible mechanisms here. I have no idea whether this actually occurs. But it's a mechanism that requires no magic, just a phenomenon (voltage induced or logic modulated jitter, as it is variously called) discussed in a research paper published over two decades ago. Whether this jitter in the bitstream can then be preserved in memory absolutely depends on whether these signal strength variations can be stored as field strength variations in memory locations. I don't know whether that can occur; I'm just depending on my understanding of something John Swenson said in an old comment in these forums. But that's fine. A characteristic of real rather than magical explanations is that the former can be shot down. And I'm happy for anyone to do that - or to confirm it can happen. But be prepared either way to back up what you're saying with good hard facts.

[alfe]

So, a shot at a plausible mechanism:

 

Back in 1991, Ed Meitner and Robert Gendron presented an AES paper showing how a very slight change in the reference voltage of the source will cause jitter in the signal. I don't have access to the paper itself, but a figure from that paper which IMHO does a really wonderful job of presenting the phenomenon in intuitive visual form is shown as Figure 1 here: http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf . Please take a moment to follow the link and have a look at it.

 

Remember now the earlier discussion regarding whether variations in signal strength values could be preserved in flash memory. We wouldn't be talking about variations large enough to flip bits, because as I think we all grant, bit flipping would be audibly evident and nasty-sounding. Rather, we'd be talking about relatively small variations in signal strength that would be of the same proportion as tens or hundreds of picoseconds of jitter are to a sampling rate of 44.1kHz. John Swenson, an electrical engineer and audio designer, whose day job experience (as I've mentioned before) appears highly relevant to this issue, says such signal strength variations can indeed be stored as tiny variations in field strength at the storage locations. So let's grant this possibility for the moment.

 

Now let's consider the ripping process. Say the power supply for the disc drive is electrically noisy, resulting in noise on ground. When signal strength of a bit is evaluated against that noisy ground, it will be evaluated as slightly diminished from its "true" value, i.e., the amplitude of the signal will not be evaluated against a zero ground but against a ground that has a level of "signal" on it. The effect will be to make the signal strength of the bitstream look like that Figure 1 we saw earlier, i.e., the bitstream will behave as if it had some amount of jitter added, just as Meitner and Gendron found over two decades ago. If these slightly diminished signal strength values are then stored as memory locations with slightly diminished field strength, this jitter will in effect be preserved in memory.

 

Remember, I'm just talking about plausible mechanisms here. I have no idea whether this actually occurs. But it's a mechanism that requires no magic, just a phenomenon (voltage induced or logic modulated jitter, as it is variously called) discussed in a research paper published over two decades ago. Whether this jitter in the bitstream can then be preserved in memory absolutely depends on whether these signal strength variations can be stored as field strength variations in memory locations. I don't know whether that can occur; I'm just depending on my understanding of something John Swenson said in an old comment in these forums. But that's fine. A characteristic of real rather than magical explanations is that the former can be shot down. And I'm happy for anyone to do that - or to confirm it can happen. But be prepared either way to back up what you're saying with good hard facts.

 

Jud,

 

During ripping process Jitter is part of the game?

Have a look to the Jitter value for a laser diode

 

https://www.jsap.or.jp/jsapi/Pdf/Number03/CuttingEdge2.pdf

[Audio_ELF]

So, a shot at a plausible mechanism:

 

[...snip...]

The problem with any explanation akin to yours Jud is it ignores the fact that a DAC does not directly access the "data" stored on the hard drive. Between the platter (where there are the minute variations in the voltage level) and the DAC there will be multiple solid state buffers. For differences in the writing of that data to the drive to affect the eventual SQ at playback, you have to account for these variations being passed along through each of theses buffers - this just does not hold up.

 

Eloise

[miguelito]

So, a shot at a plausible mechanism:

 

Back in 1991, Ed Meitner and Robert Gendron presented an AES paper showing how a very slight change in the reference voltage of the source will cause jitter in the signal. I don't have access to the paper itself, but a figure from that paper which IMHO does a really wonderful job of presenting the phenomenon in intuitive visual form is shown as Figure 1 here: http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf . Please take a moment to follow the link and have a look at it.

Yes, this makes perfect sense - it is the key source for jitter.

 

Remember now the earlier discussion regarding whether variations in signal strength values could be preserved in flash memory. We wouldn't be talking about variations large enough to flip bits, because as I think we all grant, bit flipping would be audibly evident and nasty-sounding. Rather, we'd be talking about relatively small variations in signal strength that would be of the same proportion as tens or hundreds of picoseconds of jitter are to a sampling rate of 44.1kHz. John Swenson, an electrical engineer and audio designer, whose day job experience (as I've mentioned before) appears highly relevant to this issue, says such signal strength variations can indeed be stored as tiny variations in field strength at the storage locations. So let's grant this possibility for the moment.

Problem with this argument is that DAC does not work this way, there's no reading of a DSD stream directly from the file or memory per-se. What is read from disk/memory gets re-casted into the proper voltage values that represent 0 or 1 in the hardware we are using.

 

Now let's consider the ripping process. Say the power supply for the disc drive is electrically noisy, resulting in noise on ground. When signal strength of a bit is evaluated against that noisy ground, it will be evaluated as slightly diminished from its "true" value, i.e., the amplitude of the signal will not be evaluated against a zero ground but against a ground that has a level of "signal" on it. The effect will be to make the signal strength of the bitstream look like that Figure 1 we saw earlier, i.e., the bitstream will behave as if it had some amount of jitter added, just as Meitner and Gendron found over two decades ago. If these slightly diminished signal strength values are then stored as memory locations with slightly diminished field strength, this jitter will in effect be preserved in memory.

The probability that the error correction in a CD does -not- detect an error when there indeed was one is 2^-19 (this is such a tiny number that for all intents and purposes it is zero). I just looked this up yesterday. In other words it is impossible to have a read error and not detect it as such - i.e. if we did not have a read error, what we get out of the CD (having done error correction) is exactly what was in the master that was used to press the CD (not all of which are identical obviously).

 

Remember, I'm just talking about plausible mechanisms here. I have no idea whether this actually occurs. But it's a mechanism that requires no magic, just a phenomenon

I don't think this explanation is correct. I am not saying that there are no possible reasons, just that this explanation is not up to snuff.

[Audio_ELF]

Jud,

 

During ripping process Jitter is part of the game?

Have a look to the Jitter value for a laser diode

 

https://www.jsap.or.jp/jsapi/Pdf/Number03/CuttingEdge2.pdf

The problem is that that document is referring to real time reading of the disc ... when you are ripping this is just not the case.

 

When you rip the process is something akin to (and I am not saying this is exact but simplified)

<< read the first sample

>> 01100111 00110010

<< read the first sample again

>> 01100111 00110010

== do the two reads agree? Yes, but two passes isn't enough confidence

<< read the first sample

>> 01101111 00110010

== do we have a positive consensus? No ... only 66% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 75% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 80% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 83% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 85% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? Yes ... 88% agreement

 

Now as I say this is very simplified; but shows how a single bad read caused by SMPS noise is going to be eliminated and all noise is averaged out.

 

This is nothing to do with playback where noisy PSU can make a difference.

 

Eloise

[alfe]

The problem is that that document is referring to real time reading of the disc ... when you are ripping this is just not the case.

 

When you rip the process is something akin to (and I am not saying this is exact but simplified)

<< read the first sample

>> 01100111 00110010

<< read the first sample again

>> 01100111 00110010

== do the two reads agree? Yes, but two passes isn't enough confidence

<< read the first sample

>> 01101111 00110010

== do we have a positive consensus? No ... only 66% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 75% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 80% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 83% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? No ... only 85% agreement

<< read the first sample

>> 01100111 00110010

== do we have a positive consensus? Yes ... 88% agreement

 

Now as I say this is very simplified; but shows how a single bad read caused by SMPS noise is going to be eliminated and all noise is averaged out.

 

This is nothing to do with playback where noisy PSU can make a difference.

 

Eloise

 

So 6x speed for DVD and 48xspeed for CD is real time?

[Audio_ELF]

So 6x speed for DVD and 48xspeed for CD is real time?

No; but what is your point?

 

That document talks about jitter in a realtime playback system.

 

Jitter CANNOT BE STORED IN A FILE so is irrelevant when ripping!

 

The linking of that document is just another example where totally non-analogous systems are being used to justify erroneous claims.

 

Eloise

[alfe]

No; but what is your point?

 

That document talks about jitter in a realtime playback system.

 

Jitter CANNOT BE STORED IN A FILE so is irrelevant when ripping!

 

The linking of that document is just another example where totally non-analogous systems are being used to justify erroneous claims.

 

Eloise

 

I have no claims, I'm not trying to justify anything to anyone,I'm just taking the risk (adrenaline) to participate to this thread.

[miguelito]

No; but what is your point?

 

That document talks about jitter in a realtime playback system.

 

Jitter CANNOT BE STORED IN A FILE so is irrelevant when ripping!

 

The linking of that document is just another example where totally non-analogous systems are being used to justify erroneous claims.

 

Eloise

+1

 

Although I don't think your argument was all that great. The point is there is very elaborate error correction in CDs. The algorythm is both able to correct read errors and if it is not able to correct the error it will indicate there's an error. The probability of having a read error and not identifying it as such is 2^-19 which is as good as zero.

 

Additionally there's the pervasive belief underlying some comments in this thread that digital data stored in analog form (which is effectively always the case) somehow is used as-is without recasting into "newly minted" 1's and 0's. This is simply not the case.

[Jud]

 

Problem with this argument is that DAC does not work this way, there's no reading of a DSD stream directly from the file or memory per-se. What is read from disk/memory gets re-casted into the proper voltage values that represent 0 or 1 in the hardware we are using.

 

I'm very interested in the details of this recasting into the proper voltage values, if you can provide additional information.

 

The probability that the error correction in a CD does -not- detect an error when there indeed was one is 2^-19 (this is such a tiny number that for all intents and purposes it is zero). I just looked this up yesterday. In other words it is impossible to have a read error and not detect it as such - i.e. if we did not have a read error, what we get out of the CD (having done error correction) is exactly what was in the master that was used to press the CD (not all of which are identical obviously).

 

I don't know if you are responding to what I wrote or relating independent thoughts, but I want to reiterate that *nothing* I am talking about has anything whatever to do with read errors or bit flipping. What is being read in my potential scenario is what is in the memory locations.

[Paul R]

 

The probability that the error correction in a CD does -not- detect an error when there indeed was one is 2^-19 (this is such a tiny number that for all intents and purposes it is zero). I just looked this up yesterday. In other words it is impossible to have a read error and not detect it as such - i.e. if we did not have a read error, what we get out of the CD (having done error correction) is exactly what was in the master that was used to press the CD (not all of which are identical obviously).

 

 

I don't think this explanation is correct. I am not saying that there are no possible reasons, just that this explanation is not up to snuff.

 

I believe it is mostly correct, but I wonder how many times CD players just skip over errors instead of actually rereading and correcting them? (grin) Actually, I know the answer to that, and it is "quite often." Effectively, these boo boos are not audible, but in reality, a ripped file, which has been subject to error correction, in a non-real time setting, is probably going to sound better. How much better? I would not even venture a guess for in general, but to me specifically, significantly better.

 

Remember, CD players have to correct in real time, and often they do not have enough time to do that.

 

For some of the clsims that are being talked about here, well, I will say I can not duplicate the claimed results- not in a controlled environment. Such changes vanish when played back on the same system from the same media. At least neither I nor anyone else down here that has tried with me has been able to reliably tell the difference. (shrug) It is not impossible for these differences to be real, but it is impossible for the digital information to be affected by any ripping process, except for causing readily identifiable errors.

 

Note that Alex has not -and adamantly refuses to- even try this in a controlled environment, with any kind of double blind testing. Not that double blind testing is the be all or end all of testing mind you, but so obvious a difference should easily be audible in such testing and would provide far more confidence in his results. Most of the people he claims back up his findings practice similar poor testing practices.

 

A few, a very few, are reliable witnesses and also use test techniques that provide some measure of confidence in their results. Not all of those people agree they can even hear a difference though.

 

To me, that is enough reason not to dismiss these claims out of hand, but far from enough reason to accept them. And those results give me no reason to assume the explanations Alex offered for the possible audible difference are correct, while there are many reasons that suggest the explanations are incorrect.

 

 

And with that, we enter the strange world of possible, but unlikely reasons for bit perfect data streams, DACs, and software olayers to sound different. Once you eliminate media differences, testing differences like matched volume, and mitigate any transmission interference, many -but not all- of those differences vanish.

 

It is reasonable to assume that very small factors, such as electrical loads in the computer, may have an amplified effect on the analog output signal. Proving that, however, is anything but easy!

 

YMMV, IMO, etc.

 

-Paul

[alfe]

The point is there is very elaborate error correction in CDs. The algorythm is both able to correct read errors and if it is not able to correct the error it will indicate there's an error. The probability of having a read error and not identifying it as such is 2^-19 which is as good as zero.

 

Sorry I'm just learning how CD works

[Jud]

Jitter CANNOT BE STORED IN A FILE so is irrelevant when ripping!

 

Eloise

 

With respect, Eloise, what you are saying may well be true, but all caps don't make it so.

 

I'm interested in whether signal strength variations in the bitstream can be preserved as field strength variations in the storage medium, and from there once again converted to signal strength variations in the bitstream that is sent to the DAC. In this connection I would like to learn about what miguelito calls "recasting" or "'newly minted' 1s and 0s" being sent to the DAC. Please (you, or anyone else) feel free to jump in and provide additional information on this.

[miguelito]

I'm very interested in the details of this recasting into the proper voltage values, if you can provide additional information.

When a HD magnetic head or a CD optical head read data from a disk they will read something like a "squarish" waveform. The peaks and troughs represent 1's and 0's. The levels will not be exact, there will be some slop, "jitter" in the terminology we are using here. An ADC is then used to make up "true" 1's and 0's out of that - i.e. the waveform is not simply "carried over" (how would you even use the data if you didn't do an ADC off of that?).

 

Not all 1's and 0's out of the ADC will be correct, some will have been misread/misinterpreted due to "jitter". However, this is where the beauty of math kicks in: Due to redundant information in that bitstream, which is used to do error correction, you will get the exact 1's and 0's that were meant to be written initially.

 

In the CD case, this error correction is such that either the data is corrected or is known to be bad. The probability of read error that gets undetected as such is 2^-19 in the CD case (paper reference below) which is zero for all intents and purposes.

 

http://www.info.biz.hr/Typo3/typo3_01/dummy-3.8.0/fileadmin/Mirko_Brand/ATT00045.pdf