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

[idiot_savant]

Hi @manueljenkin, maybe this is the old grizzled non-believer in me, but I’m assuming you’ve compared the “before” and “after” files -

“fc unoptimised_file.wav optimised_file.wav” /b 

 

This is a ( pedantic) first step? We can all speculate, but we can *prove* the file is bit identical before we start, no? This way no one can claim identical CRC’s etc

 

your friendly neighbourhood idiot 

[idiot_savant]

I’m afraid I’ve committed the cardinal sin here in going all command line, so let’s start at the very beginning - there is a claim that files can be optimised *without* changing their contents, so being even handed the first thing to verify is that the contents are *unchanged^
 

if you’ve done this, grand, and you’ll be happy to share how this was done?

 

I’m interested, but before we go into the subjective realm, a quick objective check - which matches the objective claim - is worth it? Does this seem common sense?

 

your friendly neighbourhood idiot 

[idiot_savant]

Whoa!

 

we have a claim here where we *really* need to verify the foundations, because everything on top of that is conjecture and supposition. 
 

Are the optimised and un-optimised files the same ( content-wise )? This is easy to confirm, so why not start there?

until this has been verified ( and I am casting no doubt ) then discussions are pointless

 

your friendly neighbourhood idiot 

[idiot_savant]

If you’re going to quote me, could you do me the courtesy of not being selective?

 

”The decompilation doesn’t help, but whatever  it is trying to do looks pretty pointless to me - but it *is* trying to do something, even if misguided - I’m not sure if there’s a magic sequence it’s trying to write to the disk whilst copying a file at the same time? 
 

anyway, I’ve seen nothing ( so far ) that could explain any difference in sound”

 

your friendly neighbourhood idiot 

[idiot_savant]

@manueljenkin- right, so I’ve been thinking about this some more. So your suggestion is that by writing random numbers to the page file *somehow* makes that file different in electromagnetic terms. 
 

Even, and I must say this is a *big* if, this is true, then surely only the first fraction of a second during playback whilst the file is read can this make a difference? I.e from seconds 0.01 - end of track the file is not being accessed any more ( as it’s being deliberately read in one go, or from the file system cache )
 

I’m sure you and your friends are picky, but you can’t be suggesting that the electromagnetic interference continues from here? Or am I being an idiot again?

 

You say you have an EE background, so I’ll patiently await your response,

 

your friendly neighbourhood idiot

[idiot_savant]

@PeterSt 

 

couple of points here:

 

firstly, we’re talking about this page-file thrashing being done at a different time to playback ( optimising a file ). So my point still stands - even *big if* this made some difference to the file how does this affect *anything* after it’s been read? I.e the first fraction of a second?
 

secondly : are you seriously as a manufacturer of cables and equipment coming on to a public forum and saying you have no idea how they work or why they are beneficial?

*edit* got my threads mixed up, here is what was said on the other thread

 

”Along with this goes another kind of example (interesting for your subject here), ... because of his knowledge but by far more merely because of his education, poor me is not able to talk with him about my own cables, because, well, I am not educated in the cable field.”

 

thirdly : as a manufacturer selling product in the EU, don’t you need to do EMC testing as part of CE? Couldn’t you use this time in the test chamber to get some measurements to support your theories?

 

 

your friendly neighbourhood idiot 

[idiot_savant]

@manueljenkin - no problem, I await your response

 

 

 

your friendly neighbourhood idiot 

[idiot_savant]

@PeterSt I know English is not your first language, so I’ll try to be more explicit

 

I am not talking about *your* software

 

I am not talking about playback software *at all*
 

I’m talking about this “optimising of a file”

 

understand?

 

your friendly neighbourhood idiot 

[idiot_savant]

@PeterSt

 

Right, so to be clear : this *whole* thread is about a single executable that can “optimise” a file so it sounds better, but is *identical* in terms of content. 
I believe it has been stated it is not defragmentating the file. 
 

Looking at the executable, it *appears* to spend 2 minutes writing random(ish) numbers to the windows page file. It then copies the original file to a new name. 
 

Now the question is : even *if* this did anything, be that by angels dancing on electrons, defragmenting the file by accident, electromagnetic “effects” or noise, *how* can this effect last longer than the reading of the file ( I.e. the first fraction of a second ). 
 

 

your friendly neighbourhood idiot 

[idiot_savant]

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

 

 

 

your friendly neighbourhood idiot

[idiot_savant]

@manueljenkin - I look forward to your response

 

 

your friendly neighbourhood idiot 

[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 

 

 

 

 

 

[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 

 

 

 

[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

 

[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

 

 

[idiot_savant]

@yamamoto2002- the claimant is using an SSD,  and the player reads the whole file into RAM before starting playback. 
 

Your friendly neighbourhood idiot 

[idiot_savant]

On 6/1/2021 at 5:29 PM, manueljenkin said:

copies to RAM directly (like playpcmwin) and plays to enjoy the benefits, as long as you don't move or edit the file (moving between different local drives, making a copy and editing would likely nullify the optimization).

 

Playback system is surface book 2016 256gb SSD with gt940m feeding a few usb dacs

your friendly neighbourhood idiot 

[idiot_savant]

Oh, and junilabs player most definitely loads into RAM before playback. 

your friendly neighbourhood idiot 

[idiot_savant]

24 minutes ago, PeterSt said:

 

If you suggest it is played from RAM ... maybe. But you are guessing that. Abd if you are not guessing that, the "claimant" is guessing that (assumed you refer to @manueljenkin here). The author is not claiming that - at least not that I am aware of.

Is what you said. I quoted from the very first post in the thread, saying he had an SSD, and any player that played from RAM would be improved. 
 

How, exactly is this out of context? 
 

The buffers post is the one out of context ?

 

Ive said before, English is clearly not your first language so if you’re going to be rude, wouldn’t it be worth being sure before spouting off? 

 

 

your friendly neighbourhood idiot 

[idiot_savant]

@yamamoto2002- if you read the very first post in this thread, this is a specific claim, on a specific system. 

 

@PeterSt - I’ve read the source code of the player. It most definitely reads the file into RAM, *then* starts playback. 
 

 

 

your friendly neighbourhood idiot 

[idiot_savant]

@andrewinukm- sorry, perhaps my post wasn’t clear? I’m not asking anyone to do anything but thought experiments?

 

I’m not trying to hang anyone - @manueljenkin hasn’t measured anything, claims to have an EE background and makes preposterous claims. I’ve given him every opportunity to back out, but he keeps digging…

 

like I’ve said numerous times, I’m not disputing what people are subjectively experiencing, but some claims deserve a bit of challenging? The industry is full of snake oil, so if a little bit of critical thinking can reduce that, isn’t that a good thing?

 

 

your friendly neighbourhood idiot 

[idiot_savant]

@manueljenkin - I was merely responding to the thanks you were given for doing measurements. If you have provided measurements, I do apologise.

Please, take as long as you need, but I'll keep reminding you - if you can come up with a plausible explanation, I'm sure we'd all love to hear it,

 

 

 

your friendly neighbourhood idiot

[idiot_savant]

@manueljenkin- any luck with your tests?

 

 

your friendly neighbourhood idiot