Bit-identical playback CAN sound different

[PeterSt]

17 hours ago, EdmontonCanuck said:

Sure, it's a con. Funny how the fellow who recommended it could hear a difference though 😊

 

Yeah, you are correct. You did not call the poster a con. You would win this lawsuit on wording.

But only once. In reconvention, however ...

 

:-)

 

Edit: You would probably win from me on wording always because of my English (with apologies). But at least you should be able to digest some of this French product. No ?

[PeterSt]

10 hours ago, March Audio said:

We know that it makes no changes to the file.  The only thing left is that it tries to "optimise" how it is read off the disc. Even PeterSt admitted this is meaningless when using an SSD, as you do.  Copying a file will make no difference

 

If I would be set to the task of optimizing an SSD for Audio, I would definitely organize its structure so it would be reading functionally sequentially the most efficient. If you don't know what I mean by this, the please investigate SSD speed tests (in all forms) and use different SSDs for it which you have physically at hand.

That I would not know how to organize this, is something I might have hinted at and which is true. But the differences clearly exist and it is all about that (for an SSD that is).

 

SSDs are terrible beasts when it comes to SQ and they are better not used. However, each couple of years another type emerges and YMMV.

But hey (and this is serious) if you are not worried about Foobar's playback SQ then all is moot. Roon no different and generally even worse. ... sorry ...

[March Audio]

7 hours ago, manueljenkin said:

I said I don't like the way foobar sounds. And I don't care about roon anyway, do foobar vs roon is a lost cause for me. But I wouldn't go into a discussion of roon and push it unlike what you do here.

 

You're not using the tool as it was intended. So that alone invalidates your "conclusions". It's like getting a submarine and then accusing the manufacturer because it didn't fly.

No one is pushing Roon.  All you have been asked to do is identify the foobar tracks to confirm that you can really hear how bad you think it sounds.

 

I can repeat the test with any playback software you like instead of Roon.

 

What would you like me to use?

[March Audio]

3 hours ago, PeterSt said:

.

 

SSDs are terrible beasts when it comes to SQ and they are better not used. However, each couple of years another type emerges and YMMV.

But hey (and this is serious) if you are not worried about Foobar's playback SQ then all is moot. Roon no different and generally even worse. ... sorry ...

Do you have any evidence to support that claim?

[March Audio]

4 hours ago, PeterSt said:

 

Yeah, you are correct. You did not call the poster a con. You would win this lawsuit on wording.

But only once. In reconvention, however ...

 

:-)

 

Edit: You would probably win from me on wording always because of my English (with apologies). But at least you should be able to digest some of this French product. No ?

The software claims it optimise the file.  This means it is acting on the file.

 

We have proven it makes no changes to the audio content of the file and only appends the file name.

 

During the alleged optimisation the application indicates there is no disk activity.  There is no memory activity, there is no obvious CPU activity.  It is clear it is not accessing, loading or reading the file.

 

It takes precisely 2 minutes to allegedly optimise the file regardless of file size.  10Mb or 1 Gb.

 

So, can you provide some ideas as what you think the software is doing which requires no disk access, no memory usage and can be competed in 2 minutes regardless of file size?

 

[pkane2001]

16 minutes ago, March Audio said:

So, can you provide some ideas as what you think the software is doing which requires no disk access, no memory usage and can be competed in 2 minutes regardless of file size?

 

 

Sleep(120000)?

 

(sorry, a programmer joke 🤓)

 

[March Audio]

4 hours ago, PeterSt said:

 

If I would be set to the task of optimizing an SSD for Audio, I would definitely organize its structure so it would be reading functionally sequentially the most efficient. If you don't know what I mean by this, the please investigate SSD speed tests (in all forms) and use different SSDs for it which you have physically at hand.

That I would not know how to organize this, is something I might have hinted at and which is true. But the differences clearly exist and it is all about that (for an SSD that is).

 

SSDs are terrible beasts when it comes to SQ and they are better not used. However, each couple of years another type emerges and YMMV.

But hey (and this is serious) if you are not worried about Foobar's playback SQ then all is moot. Roon no different and generally even worse. ... sorry ...

 

You do realise the controller on the SSD decides what cells are written? Check out wear levelling.

 

From Samsung:

 

 

Also all those cells can be accessed equally fast. There is no benefit to try and optimise it like a mechanical hard disk.

 

 From Samsung:

 

 

Also with (in relative terms) small audio files the drives are so quick its irrelevant.

[March Audio]

15 minutes ago, pkane2001 said:

 

Sleep(120000)?

 

(sorry, a programmer joke 🤓)

 

You beat me to it.  Its just a progress bar and a 2 minute timer. 😄

[fas42]

The first time I tried the foobar software ABX comparator, I thought, "Hey, why does the playback sound much poorer than when using foobar directly!" ... which led me to work out what the comparator was doing. Right! It was making those temp copies ... so, its functionality as a comparison tool was inherently broken ...

 

It seem some people are incapable of understanding that circuitry that's reading and processing the track data are capable of generating electrical noise that by some route interferes with the analogue areas of the replay system. So long as one has faith that areas marked, Digital, and others marked, Analogue, are by magical means kept 100% apart, under all circumstances, then the gap of understanding will never be crossed ...

[March Audio]

19 minutes ago, fas42 said:

The first time I tried the foobar software ABX comparator, I thought, "Hey, why does the playback sound much poorer than when using foobar directly!" ... which led me to work out what the comparator was doing. Right! It was making those temp copies ... so, its functionality as a comparison tool was inherently broken ...

 

It seem some people are incapable of understanding the circuitry that's reading and processing the track data

 

are capable of generating electrical noise that by some route interfere with the analogue areas of the replay system. So long as one has faith that areas marked, Digital, and others marked, Analogue, are by magical means kept 100% apart, under all circumstances, then the gap of understanding will never be crossed ...

 

 

Indeed.  Do people think the data travels directly from the hard disk to the DAC chip? 😄

 

This is a very generic/smplified description but the playback software will probably have a memory buffer for the audio data taken from the disk.   An asynch USB connection will ask for data as and when it needs it from the computer (ie when its memory buffer needs filling).  There is probably also more memory buffering in the USB driver.  The USB receiving end in the dac has a buffer.  Data is then accurately locally clocked out to the DAC chip.

 

There is no direct relationship between the data on the hard disk and what enters the dac chip.  The data has been copied and moved multiple times.  That by definition breaks the alleged functionality of the Juniwhatever software.

 

The real area of concern ground currents flowing from the computer to the dac along the USB shield and noise on the power lines.

 

This is neatly avoided by galvanic isolation which is incorporated into some dacs.  Otherwise buy a proper galvanic isolator (maybe the Intona devices) and the job is done.  There is no physical connection between computer and dac.

[fas42]

10 minutes ago, March Audio said:

There is no direct relationship between the data on the hard disk and what enters the dac chip.  The data has been copied and moved multiple times.

 

The issue is not the data per se, but electrical processes which by whatever means enable a copy of that data to be presented to the DAC input.

 

Quote

 

The real area of concern ground currents flowing from the computer to the dac along the USB shield and noise on the power lines.

 

This is neatly avoided by galvanic isolation which is incorporated into some dacs.  Otherwise buy a proper galvanic isolator (maybe the Intona devices) and the job is done.  There is no physical connection between computer and dac.

 

And that's the nub of it. Using the term "neatly avoided" doesn't mean that such is the case in the majority of rigs out there. That a well implemented solution is indeed possible is no guarantee that such is in place. And we still haven't worked out precisely what needs to be done to guarantee that RF noise, and noise fed between the two via their mains power leads is not having an impact

[danadam]

17 minutes ago, March Audio said:

This is a very generic/smplified description but the playback software will probably have a memory buffer for the audio data taken from the disk.   A asynch USB connection will ask for data as and when it needs it from the computer.  There is probably also more memory buffering in the USB driver.  The USB receiving end in the dac has a buffer.  Data is then accurately locally clocked out to the DAC chip.

Also the operating system will probably cache the whole file when it is accessed. For example, time it takes to calculate md5 hash of an 80 MB file stored on a spinning disk:

]$ time md5sum "01. BWV 1080_ Contrapunctus 1.flac"
dad4cde3971af6ece247ff1d10b3b218  01. BWV 1080_ Contrapunctus 1.flac

real    0m2.582s
user    0m0.378s
sys     0m0.129s

and then called for the second and third time:

]$ time md5sum "01. BWV 1080_ Contrapunctus 1.flac"
dad4cde3971af6ece247ff1d10b3b218  01. BWV 1080_ Contrapunctus 1.flac

real    0m0.216s
user    0m0.175s
sys     0m0.041s

]$ time md5sum "01. BWV 1080_ Contrapunctus 1.flac"
dad4cde3971af6ece247ff1d10b3b218  01. BWV 1080_ Contrapunctus 1.flac

real    0m0.205s
user    0m0.172s
sys     0m0.033s

The 2.5 vs 0.2 s difference is because the data did not have to be read from the disk in the subsequent cases.

That's on Linux but I'm pretty sure it's the same on Windows.

[yamamoto2002]

2 hours ago, March Audio said:

This is a very generic/smplified description but the playback software will probably have a memory buffer for the audio data taken from the disk.   An asynch USB connection will ask for data as and when it needs it from the computer (ie when its memory buffer needs filling).  There is probably also more memory buffering in the USB driver.  The USB receiving end in the dac has a buffer.  Data is then accurately locally clocked out to the DAC chip.

 

This is about Windows 10

 

• Music player app may have a PCM buffer of arbitrary size on main memory.
• WASAPI exposes a PCM buffer of 3 ms to 3000 ms or so for music player app to write next PCM data to play.
• About WaveRT port driver: it has a cyclic buffer there. https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/WaveRTport.doc
• There is a software stack chart: https://docs.microsoft.com/en-us/windows-hardware/drivers/audio/usb-2-0-audio-drivers

  Quote

  

   

About USB Audio device:

• USB audio stream controller on USB Audio device has a cyclic buffer or ping pong buffer as a receive buffer of USB isochronous packets, then a FIFO buffer cascaded to send PCM to I2C bus of DAC chip.
• DAC chip itself has a FIFO buffer of 128 samples or so, in order to apply oversampling digital filter

 

[March Audio]

2 hours ago, fas42 said:

 

The issue is not the data per se, but electrical processes which by whatever means enable a copy of that data to be presented to the DAC input.

 

 

And that's the nub of it. Using the term "neatly avoided" doesn't mean that such is the case in the majority of rigs out there. That a well implemented solution is indeed possible is no guarantee that such is in place. And we still haven't worked out precisely what needs to be done to guarantee that RF noise, and noise fed between the two via their mains power leads is not having an impact

 

But this is my point.  Some are intent on faffing around with trying to "optimise" the PC operation when its not the problem.  PCs are fundamentally noisy devices.  The ground plane in a PC is a mess of high frequency currents.  It will still be so whatever "optimisations" you feel like making.

 

However, having said this it doesnt follow that your audio gets messed up as a result. Plenty of dacs out there that are well isolated.  However if its something that concerns you get a proper galvanic isolator.  Job done.

[opus101]

9 minutes ago, March Audio said:

However, having said this it doesnt follow that your audio gets messed up as a result.  If its something that concerns you get a proper galvanic isolator.  Job done.

 

Given a random galvanic isolator, how would an owner be able to determine if its a 'proper' one or not?

[March Audio]

2 hours ago, opus101 said:

 

Given a random galvanic isolator, how would an owner be able to determine if its a 'proper' one or not?

What I mean by this not one of these "USB Noise Purifiers".  Not the sort of thing that just puts a cap and maybe an inductor across the supply rails.

 

Products such as the Intona properly isolate power and data lines.

[opus101]

50 minutes ago, March Audio said:

Products such as the Intona properly isolate power and data lines.

 

How about mansr's 'USB troll' which isolates GND but not the data lines - proper or not?

[PeterSt]

1 hour ago, March Audio said:

Products such as the Intona properly isolate power and data lines.

 

No it does not.

[March Audio]

43 minutes ago, PeterSt said:

 

No it does not.

It really does, demonstrably so.

[PeterSt]

5 minutes ago, March Audio said:

It really does, demonstrably so.

 

You should open a new thread for all you spout. It would be a nice collection for people to review how all should NOT be done.

[March Audio]

24 minutes ago, PeterSt said:

 

You should open a new thread for all you spout. It would be a nice collection for people to review how all should NOT be done.

Well its really up to you to provide some evidence to back up your claims of things being otherwise.

 

I asked you earlier to provide some answers as to what the Junilabs software is actually doing.  You havent.

 

I have asked you to compare recordings of files played back on Foobar (which you claim sounds bad) and another player to see if you can identify which is which.  You havent.

 

[semente]

On 5/9/2021 at 6:12 AM, March Audio said:

BTW I will be at an audio society meeting next week, about 40 people.  I will take the opportunity to perform a test and see if people can hear a difference when they dont know anything about the files.

 

40 people listing in an unfamiliar room, sitting outside of the sweet-spot, over an unfamiliar system and probably unfamiliar music using Foobar as a player.

The result is easy to predict...

[March Audio]

6 minutes ago, semente said:

 

40 people listing in an unfamiliar room, sitting outside of the sweet-spot, over an unfamiliar system and probably unfamiliar music using Foobar as a player.

The result is easy to predict...

OK, we have been told that Foobar apparently sounds bad.  Would you like to participate in a listening test found here:

https://1drv.ms/u/s!AnQ0c7fb_4zLglIhoPA6EbZnidgr?e=JwsP4E

 

and identified which files were replayed by Foobar?

 

You can listen in whatever surroundings make you comfortable using whatever replay software.

[manueljenkin]

10 minutes ago, semente said:

 

40 people listing in an unfamiliar room, sitting outside of the sweet-spot, over an unfamiliar system and probably unfamiliar music using Foobar as a player.

The result is easy to predict...

Looks like he is going to do a triple blind test. The player would not know which among the 40 people are listening to it. 😁

[semente]

Just now, March Audio said:

OK, we have been told that Foobar apparently sounds bad.  Would you like to participate in a listening test found here:

https://1drv.ms/u/s!AnQ0c7fb_4zLglIhoPA6EbZnidgr?e=JwsP4E

 

and identified which files were replayed by Foobar?

 

You can listen in whatever surroundings make you comfortable using whatever replay software.

 

I hate AB comparisons, X or no X. You'd have to pay me to install Foobar in my computer and do one.

 

By the way, can you hear differences between filters?