Do you hear what I hear (bit perfect files sounding different)?

[manueljenkin]

6 hours ago, idiot_savant said:

@manueljenkin - I guess it really is very deep thinking that's required?

 

 

 

your friendly neighbourhood idiot

I asked a couple of days gap, half more day left.

[manueljenkin]

3 minutes ago, fas42 said:

 

Both techniques are about reducing electrical noise

No. This tool works completely different from the working of an oversampler. If any, the oversampler would be causing more noise due to the processing brute involved, unless it's coded in a super efficient way, like in xxhighend.

[idiot_savant]

@manueljenkin - I look forward to your response

 

 

your friendly neighbourhood idiot 

[EdmontonCanuck]

1 hour ago, fas42 said:

 

How it reduces noise is not the point ...

 

How it works is the point of this thread, isn't it? And I still think people are getting confused about playback of the audio file, and the file optimizer which is the point of this thread.

 

Let's be clear...it's as if you email me an audio file, I fiddle with it and email a bit-perfect copy back to you and you play back that bit perfect copy, and you claim to hear an improvement in SQ. Wouldn't you want to know what I did to the file to make that improvement? That's the point of this discussion, not how the player during playback improves SQ. If it was just about that, we wouldn't be talking about the file optimizer. 

[fas42]

46 minutes ago, PeterSt said:

 

Frank, please. You are overplaying your hand.

 

Overplaying it? I don't care what the source is of a sound degrading element in a system - there are literally dozens of areas which are intrinsically weak in audio playback chains; and you do have to play a game of Whac-a-mole to nail all of the worst ones - my method is to keep knocking them over, one by one, until the SQ is acceptable.

 

So, whether the PC is spewing out garbage, or the DAC is too crappy to sound good unless it is fed exactly the right format of the data doesn't interest me, as something to take sides over - a weakness is a weakness, and manifests as substandard sound; my only concern is to do whatever it takes to lift the quality level - and the smart approach is to do the least expensive things which get one beyond the goalposts ...

[PeterSt]

47 minutes ago, fas42 said:

Overplaying it? I don't care what the source is of a sound degrading element in a system

 

As long as you understand that a signal is not noise. 🙂 Upsampling that thus also does not remove noise. Unless, unless you get way more specific into aliasing and (non-)analogue filters and what not. And I have never seen anyone calling aliases "noise" as such.

Noise is a too common term to use in these cases.

 

51 minutes ago, fas42 said:

I don't care what the source is of a sound degrading element in a system

 

Sure you care. Otherwise you can't attack it.

 

Think like this: you won't arrange for reconstruction of Redbook with a ferrite ring around your cables. Similarly you won't get rid of coupled-in oscillator noise by means of upsampling.

[manueljenkin]

@fas42 just wanted to let you know I requested a couple of days gap on this thread, as I'm working on something relevant to this topic and I feel it would channelize things better for the rest of the thread. Everyone else who has been on this thread has shown their part of kindness. Kindly co-operate. Just this one day.

[andrewinukm]

On 6/7/2021 at 3:50 PM, Confused said:

The PGGB thread is about upsampling.  This does offer the possibility to reduce electrical noise buy reducing activity in the DAC, but this is not what the Junilab player is doing.  The Junilab playing is not changing bits, whereas PGGB is.  For my main system I use HQPlayer to upsample to the native rate of the DAC input, which is a different approach but has some similarities.  Both PGGB and HQPlayer are changing bits, Junilabs is not.  (as far as I am aware)

 

That is a bit of a general statement.  In my case my "main rig" has a higher standard of playback than my desktop headphone set up.  The main system uses Ethernet streaming, Ethernet isolators, a network endpoint, a device for cleaning USB, a Mutec MC3+USB (galvanically isolated)  This is a complex set-up, and debating if this is a good or bad approach is off-topic here, but it does mean that any noise in the PC is very remote from the system.  Indeed, you can disconnect the Ethernet cable from the Router and music continues playing for a couple of seconds, indicating that "bits" are being buffered remotely from the PC.  With my desktop set-up the PC is connected direct to the DAC, so is far more likely to be susceptible to any electrical influences of the PC playback.

 

And none of this goes any way towards establishing what this Junilabs file "optimising" might actually be doing.   For that I suggest we wait to see what @manueljenkin comes up with and take it from there.

 

Just to throw a wrench to this thought process: I have a DAC that buffers all audio inputs for 1 second before upsampling in an internal DSP, and yet changes at the digital front end still made observable differences (i.e. Iso Regen vs iFi iUSB, change of audio software, footers on my laptop, laptop vs RaspPi, etc.). Sometimes they are easily observable, sometimes barely, and some not at all. It baffles the mind as I have the same expectation that the buffer should have buffered it from the source. 🤯

 

Also, the less coloured, better resolution, and better "audio hygiene" (clean power & what not), the easier it is to observe small changes. A buddy once brought a DAVE (way beyond my budget), and holy macaroni we could easily identify the effects of tweaks that I had put aside as "no observable effect" pile.

 

So I've learned "never say never" when pushing beyond the measurable and explainable realm in audio. 

 

I'm in the midst of testing out Junilabs optimisation on audio files. In the mean time, lets see what Manueljenkin discovers.

[Confused]

@andrewinukmThat wrench has been in my own thought process for a while. (which might explain a lot)

 

But yes, I have observed similar in the past, which does leave me somewhat baffled, which is why this stuff is interesting I guess.

 

(going away now and waiting patiently for @manueljenkin update......)

[idiot_savant]

I’m not going to speculate in case I interfere with the big reveal…

 

 

 

your friendly neighbourhood idiot 

[idiot_savant]

But I will say to @andrewinukm - what purpose does this 1s buffer serve? Is it better than pressing “play” 1s later? How?

 

just a thought experiment , since we are running late with an explanation,

 

 

tour friendly neighbourhood idiot 

[idiot_savant]

@manueljenkin - look, I have no desire to make anyone look foolish - you’ve had a few days now to explain how this phenomenon you’ve described works, we’re still waiting after your self imposed time limit
 

I *can* talk to people on this thread about the values or not of buffers, but not while waiting for your explanation as promised

 

if you can’t come up with anything by the morning ( say UK time 9AM ) I’m going to lose interest I’m afraid.
 

you are, of course, welcome to discuss this, maybe you’ve even changed your mind? A little bit?

 

With the very best spirit of Co-operation and mutual knowledge 

 

your friendly neighbourhood idiot 

 

 

 

 

 

[manueljenkin]

53 minutes ago, idiot_savant said:

@manueljenkin - look, I have no desire to make anyone look foolish - you’ve had a few days now to explain how this phenomenon you’ve described works, we’re still waiting after your self imposed time limit
 

I *can* talk to people on this thread about the values or not of buffers, but not while waiting for your explanation as promised

 

if you can’t come up with anything by the morning ( say UK time 9AM ) I’m going to lose interest I’m afraid.
 

you are, of course, welcome to discuss this, maybe you’ve even changed your mind? A little bit?

 

With the very best spirit of Co-operation and mutual knowledge 

 

your friendly neighbourhood idiot 

 

 

 

 

 

If you're in such a haste, you can do as you wish. Or you can wait a little more. I'm sorry that it's taking a little longer than expected, things like this take some effort.

[manueljenkin]

People who are in touch with me will know the effort I'm putting, and for the rest, my absence from the rest of the threads might be able to let you know that I am working on the same thing.

[Racerxnet]

3 minutes ago, manueljenkin said:

If you're in such a haste, you can do as you wish. Or you can wait a little more. I'm sorry that it's taking a little longer than expected, things like this take some effort.

Some effort to understand exactly how it works? Shouldn't you have already known this prior to your post....

[manueljenkin]

25 minutes ago, Racerxnet said:

Some effort to understand exactly how it works? Shouldn't you have already known this prior to your post....

Not responding to your speculations on what I'm working on!

[andrewinukm]

3 hours ago, Racerxnet said:

Some effort to understand exactly how it works? Shouldn't you have already known this prior to your post....

This is like asking a customer to explain the chef's cooking method and prove it. 

After all, we are all just users being curious and figuring things out when there are observations that beffudles common measurable or scientific explanation. There's no need for hostility amongst us users. 

 

5 hours ago, idiot_savant said:

But I will say to @andrewinukm - what purpose does this 1s buffer serve? Is it better than pressing “play” 1s later? How?

 

just a thought experiment , since we are running late with an explanation,

 

 

tour friendly neighbourhood idiot 

I think we're OK to digress a little as long as we are all cool headed, and get back to the topic eventually. 

 

Digital audio signals are delivered "live" as it is without means to cross check with the source. 

So according to the manufacturer, the buffer sort of holds the information and buffer it against inconsistent or poorly transmitted data, before sending it to DSP. They tested various buffer sizes, and determined that 1 second is the most ideal for their DAC. This is my layman explanation. 

 

There's a switch that defeats the buffer for videos, and most people who have listened to my setup can easily observe a difference in sound quality. I personally prefer the buffer turned on when listening to music. It's not a big deal, but if I can max out the quality for my enjoyment, why not? 

 

I generally think measurements and science based approach for audio gears should be encouraged more. But I've listened to tweaks or stuff that current measurements or scientific information doesn't explain. Instead of denying my observations or arguing with other deniers... I build stuff, test them, get friends to measure and listen, etc to understand the phenomena. I find it odd there are many who make lots of noise and demand all sorts of information, but unwilling to test it themselves. 

[idiot_savant]

@manueljenkin- I’m in no rush, it’s merely you said you’d have something, so I’m waiting patiently

 

@andrewinukm - I’m not disagreeing with a single thing you’re saying. There *are* valid reasons for having a buffer ( eg to deal with the “bursty” nature of network/USB connections ), or to prevent pops and bangs when something upstream changes, but it’s not going to help with “inconsistent” or “poorly transmitted” data - this kind of problem won’t sound slightly worse, it will pop and crackle - what kind of input are you using, out of interest?

 

I’m not here to argue with what people hear, I’m here to discuss why these beliefs have become so widespread. I’m a big believer that if you hear something but can’t measure it, you should look at why you can’t measure it, and fix that

 

 

your friendly neighbourhood idiot 

 

 

 

[Confused]

@idiot_savantBuffers are a fascinating topic, I would agree.  I am not sure if you have seen this, but there is some interesting text regarding buffers in John Swenson's Ether Regen white paper:

 

https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_EtherREGEN_white_paper.pdf?v=1583429386

 

Also, if anyone is worried about this taking this thread too far off topic, the white paper linked above has its own thread, see link below.

 

 

There are also many threads that discuss buffers, a couple of examples below:

 

 

 

 

[Summit]

10 hours ago, andrewinukm said:

This is like asking a customer to explain the chef's cooking method and prove it. 

After all, we are all just users being curious and figuring things out when there are observations that beffudles common measurable or scientific explanation. There's no need for hostility amongst us users. 

 

I think we're OK to digress a little as long as we are all cool headed, and get back to the topic eventually. 

 

Digital audio signals are delivered "live" as it is without means to cross check with the source. 

So according to the manufacturer, the buffer sort of holds the information and buffer it against inconsistent or poorly transmitted data, before sending it to DSP. They tested various buffer sizes, and determined that 1 second is the most ideal for their DAC. This is my layman explanation. 

 

There's a switch that defeats the buffer for videos, and most people who have listened to my setup can easily observe a difference in sound quality. I personally prefer the buffer turned on when listening to music. It's not a big deal, but if I can max out the quality for my enjoyment, why not? 

 

I generally think measurements and science based approach for audio gears should be encouraged more. But I've listened to tweaks or stuff that current measurements or scientific information doesn't explain. Instead of denying my observations or arguing with other deniers... I build stuff, test them, get friends to measure and listen, etc to understand the phenomena. I find it odd there are many who make lots of noise and demand all sorts of information, but unwilling to test it themselves. 

 

Very small buffers (low latency) sound best IMO. The lowest possible latency just before it start lagging it is.  

[idiot_savant]

OK, so I said I wasn't going to comment on buffers, but...

 

There are numerous types and implementations of buffers, but to be clear we're talking about the memory kind, not the voltage translation kind, right?

So, there are a couple of types of these: 

Inside a DAC, you might have a FIFO ( First In First Out ), where (e.g.) a digital input from an SPDIF decoder is fed data at the rate supplied by the decoder, whilst the output is read (at the same rate*) by the DAC. In this way the length of the FIFO gives you both a delay ( so time to react if e.g. the input goes away ), and also gives a PLL a bit of wiggle room to not drop samples.

 

Now, you also have the kind of buffers @Summit is talking about, which is typically a PC application feeding "audio buffers" - in this case the sound device is pulling audio from a buffer to play it in "the real world", and when the buffer is empty, it asks for another one ( it's normally a bit more complicated than this, there's often a "now" buffer, a "prepared" buffer and a "filling" buffer ). Now the issue here is: If you make *these* type of buffer smaller, the CPU has *more* work to do because it keeps getting interrupted to muck about with buffers. The plus side of this is that the latency can be smaller.

But does this matter? For some applications ( e.g. with video, or listening to yourself in a studio ) absolutely, but for *pure* playback, how does it matter that the sounds comes out a few milliseconds earlier or later? As you've experienced, if you make the buffers too small, the CPU can't keep all the buffers filled reliably ( modern CPUs & OS's like doing things in quite sizeable chunks due to caches, context switches and such like )

 

*this is why FIFOs don't *cure* jitter by themselves - if the read & write rates aren't the same ( over time ), the FIFO either runs out of samples to provide to the DAC ( underflow ) or runs out of storage to put them ( overflow ). So you need a mechanism to match in to out, which may in and of itself cause problems. 

 

none of this helps make bit-identical files sound different

 

your friendly neighbourhood idiot

 

[PeterSt]

36 minutes ago, idiot_savant said:

none of this helps make bit-identical files sound different

 

You only think it does not. But it does wildly.

Could you be a tad more neutral on this one (I recall that you told you wanted to know about this all). The first thing you should do is try it out, agreed ?

[idiot_savant]

@PeterSt - I'm not the one making wild claims. Don't forget, the claim here is that two bit identical files played back under identical conditions sound different. Same playback software, same settings.

 

 

 

your friendly neighbourhood idiot

 

 

[PeterSt]

51 minutes ago, idiot_savant said:

Don't forget, the claim here is that two bit identical files played back under identical conditions sound different.

 

Fine and agreed. But your response was to @Summit's post and that had its own context.

[yamamoto2002]

1 hour ago, idiot_savant said:

the claim here is that two bit identical files played back under identical conditions sound different. Same playback software, same settings.

 

I calculated about the following worst case scenario:

• 192kHz 24bit 2ch uncompressed PCM (WAV file), HDD formatted with 4KB cluster size.
• One file is continuously stored to the disk, another file is heavily fragmented and every other cluster is placed to the different part  of the HDD platter.

On the heavily fragmented file, the head should seek at 288 times per second and HDD cannot do it, the heavily fragmented file causes buffer underruns and stuttering occurs.

 

This causes real problem with DAW (plays order of 100 tracks and mix in realtime) and it has a workaround such as baking several tracks to one

 

Also frequent seek causes more acoustic noise from HDD. You may have a experience to hear the sound of frequent head seek of thrashing caused by low available memory https://en.wikipedia.org/wiki/Thrashing_(computer_science)