16 bit files almost unlistenable now...

[Jud]

4 minutes ago, numlog said:

Hi jud.

Do you know how this zero padding would translate to an electric signal? the files are double in size, Im trying to understand what is actually passing through the sata cable.

 

 

 

Hi numlog - it would do precisely zero, nothing, to it. 

[numlog]

Just now, Jud said:

 

Hi numlog - it would do precisely zero, nothing, to it. 

interesting

[numlog]

do you believe it possible to hear a difference between files with identical checksum? is this the same concept i.e the values are identical, including electrically?

[wgscott]

There is someone here who does make this claim.  I'll let @sandyk explain, lest I get it wrong.

 

A zero-filled file however will have a different checksum.  (As you note, it will be larger as well.)

[Jud]

14 minutes ago, numlog said:

do you believe it possible to hear a difference between files with identical checksum? is this the same concept i.e the values are identical, including electrically?

 

The process by which files with identical checksums were thought to sound different involved different electrical/noise conditions during ripping, if I remember correctly.  Here there's nothing like that - the DAC in one case receives a digit of 1 or 0 and assigns an analog value, in the other case receives 1.00000000 or 0.00000000, and assigns exactly the same analog value.  No electrical changes. 

[numlog]

26 minutes ago, Jud said:

 

The process by which files with identical checksums were thought to sound different involved different electrical/noise conditions during ripping, if I remember correctly.  Here there's nothing like that - the DAC in one case receives a digit of 1 or 0 and assigns an analog value, in the other case receives 1.00000000 or 0.00000000, and assigns exactly the same analog value.  No electrical changes. 

So you are saying the DAC receives 2 different things with the same meaning? this is what I tried to ask first, how do these extra zeros translate to voltage?

[wgscott]

If I understand correctly, the 16-bit file and zero-filled 24-bit file each get converted, separately, by the decoding software, in such a way that what gets fed to the DAC is the same in each case. So the DAC sees no difference.

[mansr]

36 minutes ago, Jud said:

I believe what the converter is doing is called "zero padding," adding eight zero bits (or 16) to the existing 16 to get 24 (or 32).

Let's work our way backwards from the DAC chip. Inside the chip, all processing (upsampling etc.) is performed using the same accuracy regardless of how wide the input is. Many chips support configuring the input for 16, 24, or 32 bits. Any additional bit clock cycles within a sample period are simply ignored by the chip. To simplify the design, a fixed bit clock corresponding to 32 bits per sample is often used regardless of the actual sample size.

 

Next we get to the interface between the computer and the DAC. Although the USB audio class permits sample sizes of 8, 16, 24, and 32 bits, many devices support only 24-bit or 32-bit input, again for simplicity. In this case, the audio player or OS driver must zero-pad smaller samples to the required size. S/PDIF always carries 24-bit samples, so 16-bit audio is padded by either hardware or software.

 

Sure, you can pad the samples already in the file, but it likely won't make any difference. If you don't do it, something else almost certainly will. Storing padded files will, however, do one thing. It will increase the amount of data transferred from the disk to memory. If that makes a difference, it won't be for the better.

[sandyk]

1 hour ago, Jud said:

 

The process by which files with identical checksums were thought to sound different involved different electrical/noise conditions during ripping, if I remember correctly.  Here there's nothing like that - the DAC in one case receives a digit of 1 or 0 and assigns an analog value, in the other case receives 1.00000000 or 0.00000000, and assigns exactly the same analog value.  No electrical changes. 

Hi Jud

It's not just the electrical noise during ripping, it's the PSU itself that mainly governs how an audio file will sound, just as with analogue.

I have previously tried to contact you to explain further and offer proof of my findings ,but you don't appear to have seen my PMs

Regards

Alex

[sandyk]

2 hours ago, numlog said:

do you believe it possible to hear a difference between files with identical checksum? is this the same concept i.e the values are identical, including electrically?

  numlog

 

 Please check your PMs

 

Alex

[mansr]

10 minutes ago, sandyk said:

I have previously tried to contact you to explain further and offer proof of my findings ,but you don't appear to have seen my PMs

We've all seen your PMs. We're just not swayed by them. Perhaps if you retyped them using a linear PSU, they would become more convincing.

[kumakuma]

11 minutes ago, mansr said:

We've all seen your PMs. We're just not swayed by them. Perhaps if you retyped them using a linear PSU, they would become more convincing.

 

The following suggests that the computer on which the PMs are read would also need a linear PSU.

 

23 minutes ago, sandyk said:

It's not just the electrical noise during ripping, it's the PSU itself that mainly governs how an audio file will sound, just as with analogue.

[sandyk]

26 minutes ago, mansr said:

We've all seen your PMs. We're just not swayed by them. Perhaps if you retyped them using a linear PSU, they would become more convincing.

 

 All that you have seen is photos that illustrate , but don't prove what some files on BR discs reveal.  Not only do you see everything in rigid black and white terms, you are also a master of the use of sarcasm.

13 minutes ago, kumakuma said:

The following suggests that the computer on which the PMs are read would also need a linear PSU.

A typical smart ass comment from you.

 Keep ignoring the very worthwhile improvements in SQ that numerous members have achieved with their " deaf" Mac Minis when retrofitted with an Uptone Linear PSU designed by John Swenson.

 

 I will be ignoring all further replies from you and your know-it-all buddies as they are completely OFF TOPIC.

 Neither will I discuss this matter further in this thread for the same reason.

 I will however respond to PMs.

[Jud]

29 minutes ago, mansr said:

We've all seen your PMs. We're just not swayed by them. Perhaps if you retyped them using a linear PSU, they would become more convincing.

 

Please don't speak for me in this regard (not bothered, just asking).

[Jud]

2 hours ago, mansr said:

Let's work our way backwards from the DAC chip. Inside the chip, all processing (upsampling etc.) is performed using the same accuracy regardless of how wide the input is. Many chips support configuring the input for 16, 24, or 32 bits. Any additional bit clock cycles within a sample period are simply ignored by the chip. To simplify the design, a fixed bit clock corresponding to 32 bits per sample is often used regardless of the actual sample size.

 

Next we get to the interface between the computer and the DAC. Although the USB audio class permits sample sizes of 8, 16, 24, and 32 bits, many devices support only 24-bit or 32-bit input, again for simplicity. In this case, the audio player or OS driver must zero-pad smaller samples to the required size. S/PDIF always carries 24-bit samples, so 16-bit audio is padded by either hardware or software.

 

Sure, you can pad the samples already in the file, but it likely won't make any difference. If you don't do it, something else almost certainly will. Storing padded files will, however, do one thing. It will increase the amount of data transferred from the disk to memory. If that makes a difference, it won't be for the better.

 

I thought something like that was happening, but didn't want to say since I wasn't sure.

[fas42]

Even though the data being presented to the DAC may be the same, it's the real time processing, digital chattering, required to process the information so that the actual conversion to analogue can occur - this can make the difference. Yes, theoretically it shouldn't make a difference, but the reality is that it can - interference effects are pernicious little bastards - they squeeze their way through the tightest, impossible gaps - and wreak a bit of damage; just enough to be audible ...

[Jud]

1 minute ago, fas42 said:

Even though the data being presented to the DAC may be the same, it's the real time processing, digital chattering, required to process the information so that the actual conversion to analogue can occur - this can make the difference. Yes, theoretically it shouldn't make a difference.but the reality is that it can - interference effects are pernicious little bastards - they squeeze their way through the tightest, impossible gaps - and wreak a bit a of damage; just enough to be audible ...

 

In this case there is nothing different to process.  The same values are in the same registers, either because the file didn't "tell" the DAC to change those values from zero (16 bit), or because the file "told" the DAC to keep those values at zero (zero padding).

[Ralf11]

15 minutes ago, fas42 said:

digital chattering

 

[fas42]

As PeterSt would be happy to point out, the tiniest, tiniest variations in how the data is dealt with can be enough to make an audible difference - why it should be so may take a major effort in diagnosing the precise internals of the circuitry. Of course the real solution is to make the final D to A transformation fully robust, but this is certainly not trivial - otherwise we wouldn't be constantly having these ferocious debates ...

[mansr]

2 minutes ago, fas42 said:

As PeterSt would be happy to point out, the tiniest, tiniest variations in how the data is dealt with can be enough to make an audible difference

Well, he has a business interest in maintaining that position.

[The Computer Audiophile]

54 minutes ago, sandyk said:

I will be ignoring all further replies from you and your know-it-all buddies as they are completely OFF TOPIC.

 Neither will I discuss this matter further in this thread for the same reason.

Promise?

[Jud]

6 hours ago, fas42 said:

As PeterSt would be happy to point out, the tiniest, tiniest variations in how the data is dealt with can be enough to make an audible difference - why it should be so may take a major effort in diagnosing the precise internals of the circuitry. Of course the real solution is to make the final D to A transformation fully robust, but this is certainly not trivial - otherwise we wouldn't be constantly having these ferocious debates ...

 

Let's make a picture.  I'm a terrible artist, but I'll try.

 

Here's a 24-bit register in a DAC before there is any data:  000000000000000000000000

 

Here's a 16-bit data word arriving at the DAC before the data is clocked out of the buffer:  0100010001000100

 

Here's that 16-bit data word with zero padding to convert it to 24 bits: 010001000100010000000000

 

Here's the 24-bit data register in the DAC as the 16-bit word fills it up, left-justified: 010001000100010000000000

 

Here's the 24-bit data register in the DAC as the 24-bit zero padded data word fills it up, left-justified: 010001000100010000000000

 

Exactly the same bits in exactly the same positions in the register.

 

Now let's suppose the mere filling up of that data register creates some electrical activity that means something, amongst all the activity of receiving the bitstream in the PHY chip, running the clock, clocking data out of the buffer, doing 8x oversampling, then delta-sigma modulation, then final analog filtering, and driving that analog signal through the outputs.  There would be more electrical activity, if at all, when filling all 24 bits in the register than when filling 16, so there would be more noise involved in taking in a zero-padded 24-bit file than the 16-bit file it was converted from (which is what @mansr was saying above).

[Jud]

6 hours ago, mansr said:

Well, he has a business interest in maintaining that position.

 

It's an ad hominem in any case, but you could argue the opposite as well.  His DAC is not especially complex; I don't think the PCs he builds are his revenue leader, or his USB cable; it's likely his software.  That is complex, with a GUI that looks something like a 747 cockpit.  He could make the software a lot sleeker and prettier-looking, probably sell more of it, if he didn't have a million toggles and controls in it.  So it's quite possible that his business interest would be better served by saying things were simpler.

[R1200CL]

1 hour ago, sandyk said:

Hi Jud

It's not just the electrical noise during ripping, it's the PSU itself that mainly governs how an audio file will sound, just as with analogue.

I have previously tried to contact you to explain further and offer proof of my findings ,but you don't appear to have seen my PMs

Regards

Alex

 

Well, what about the chosen block size of your storage ? 

Maybe that could influence also ? ?

 

I personally choose the hugest possible size, as audiofiles is huge themselves. 

[mansr]

10 hours ago, Jud said:

It's an ad hominem in any case, but you could argue the opposite as well.  His DAC is not especially complex; I don't think the PCs he builds are his revenue leader, or his USB cable; it's likely his software.  That is complex, with a GUI that looks something like a 747 cockpit.  He could make the software a lot sleeker and prettier-looking, probably sell more of it, if he didn't have a million toggles and controls in it.  So it's quite possible that his business interest would be better served by saying things were simpler.

I was thinking of the software. Given that he sells software with a million toggles and controls, would you expect him to say they don't matter? It may not be a good one, but his business model rests on maintaining a stance that all those things matter and offering a way to control them. Maybe he's right, maybe he's wrong. Either way, he is biased in the matter, and I see nothing wrong with mentioning this when someone refers to him as an authority.

 

Let's try a variation: "As Monsanto would be happy to point out, GMO foods are entirely harmless." Maybe this is true, but the source is still strongly biased in favour of this position. Therefore, them saying so means close to nothing.