You been on the sauce John 
No.
If it is true they sound different ( the files with metadata stripped out and with no differences derected by cmd), and they look different on Audacity, then something must be different that is not being picked up by the cmp test - yet that doesnât seem possible, so it falls back on the âifâ. It would be good to have blind listening tests, more than one person try with Audacity, and all on multiple files
What do we know about this âthey look different on Audacityâ matter?
Screenshots?
Because weâve heard two things: (1) âThey sound different.â But likely not via a blinded test. and (2) âThey look different on Audacity.â
1 Like
As PhilippVH and IB say⌠No itâs not possible.
Users of the Melco say that rips using the D100 are superior or at least differnet to others they have ripped using a normal CD drive and a pc or other drives on the Melco. As its possible to use the D100 with a pc maybe a good test would be to try it with DBPowerAmp or EAC? If the drive is the reason the rips are better/differnet then surely it would offer up this improved SQ using when using other software on a pc?
Be good for us sceptics for anyone with a D100 to give this ago and compare a rip via D100 and the Melco with a rip via D100 on pc/mac with ripping software and then that same software with a standard CD drive. It may then show if its the drive or their software thats accounting for the difference or both.
Iâm going to have a try this weekend, I have to be kept out of the kitchen during the xmas prep!
D100 to pc with DBPowerAmp and EAC
D100 to Melco
Teac DVD drive in the pc with DBPowerAmp and EAC
probably with an old cd before everthing got mastered for volume. I will just be a listening test with my a friend who has an all Linn system so it will be unscientific but a blind test conducted by my son.
1 Like
Good stuff Peter. Look forward to your findings.
Yup blind tests are the only way to test whether this all down to some sort of bias such as experimenter effect.
If there was a real difference, my hypothesis would be (as the order of 1s and 0s is the same between the two files) to see whether there was a difference in the timing or spacing between them.
I expect that this is all taken care of in the dac by the sampling process lining up the 1s and 0s 16,100 times a second. But if there had to be a difference, and it wasnât the âcontentâ, then Iâd be looking at the gaps between and around the content to see whether they could influence the reconstruction process.
Hereâs one more hypothesis of what could cause a SQ difference (if there is one).
In the processing of the respective files, each of them are stored on different media (e.g. on a PC HDD vs on a Melco ssd?).
Then they are transferred by different particular electronic output processes/channels to the systems in which they are compared sonically and datawise.
Those different processes could perhaps change the files enough to make the difference.
e.g. could the storage, retrieval and transfer processing alter way the data are framed/coded - and thus audibly change the timing or other asepcts of processing at playback?
Once they are encoded as a digital file, then no file transfer utility programme, no digital transmission protocol (e.g. Ethernet, WiFi, TCP/IP, http, https, etc., etc., etc.) nor any of the storage media (HDD, SSD, optical disk, tape, etc.) will make any iota of a difference.
Why not?
dBPoweramp claim on their own forum as long as itâs ripped accurately it will sound the same on identical playback hardware regardless of drive used. So interesting times ahead. If this is the case then the differences may be down to some post processes of the software. I need to do a test myself ripping via Linux on my Roon core compared to EAC on my laptop to see of OS and software change things.
1 Like
Because thatâs the very principle of digital transmission and storage in the computing world. All the worlds computers are totally reliant on this principle.
For example:
First, take a computer programme to be downloaded via the internet: Itâs stored on various distribution servers at various places around the world, primary storage is on HDD, however thereâs cache storage where a temporary copy is made on SSD. A user downloads the programme (over the internet, various Ethernet links at different speeds across different transmission media, and eventually via WiFi to their laptop and on to itâs HDD or SSD); after all this mucking about, the file still has to be identical to the one stored on the distribution servers or the programme wonât work properly - even a single bit change will prevent the file from loading (the CRC check will fail).
Second, take a bank transaction record, how big a variation in the amount can be tolerated? a single bit change can turn ÂŁ1 into more than ÂŁ1,000,000! Is this sort of error acceptable?
2 Likes
It is if it happens in my favour. 
2 Likes
If it was > ÂŁ10m, then, just perhaps, emigrating to somewhere without an extradition treaty becomes a viable option, but for ÂŁ1m - nah. 
1 Like
But the end test on yr 2 examples were binary.
Either the bits are there and it works or theyâre not and it doesnât.
thatâs also true of audio files
if the bits ainât there, they are sent again until the bits are all there
thatâs totally different from the question of SQ in a very delicate hifi system, which is dependent not merely on whether the bits are there, but on the electromagnetic noise thatâs always swirling around in all the cables and boxes (plus rooms, ears, and brain/mind)
1 Like
Thereâs different types of streaming, some involve copying files (or parts of files) and then converting the data in the file into data that is sent to the dac. The file transfer part has all the error checks, so the file on the source storage (NAS, Tidal server, PC drive etc) is the same data that reaches the streamer. If there is noise then the issues impacting sound will happen after that.
And during that?
The output from the streamer to the dac can certainly include noise, but it is on a digital signal and there are varying opinions on whether it can make an audible difference or not. Iâd guess the prevailing opinion on this forum is that it does (plus jitter considerations).
1 Like
But these considerations are different from the statement that started this thread, namely that someone had ripped the same music with two different devices & software (one the Melco), stripped out the metadata to remove that potential variable, compared the files with a program that reveals whether there are differences at digital bit level, with none reported, then:
- Conducted listening tests, not blind but with several people of differing ages, who universally said they sounded different, and
- Compared the two on screen with Audacity (a program that visually displays the waveform of extracted audio), reporting that the files looked different, âlooking as if one was recorded âquieterâ than the otherâ, which I take to mean the waveform had a smaller amplitude, though no more information was given and I donât know if that was a simple view of the entireity of file on screen at once, or looked at with expanded x-axis (time) to scrutinise in more detail.
It seems to me that there is a need to repeat the original experiment, with blind audio testing and more detailed scrutiny with audacity (IIRC Audacity has the capability to subtract one waveform from the other, which would reveal any differences). If the experiment is repeatable, rips with one device/software different sounding different and looking different on Audacity yet indistingishable as a binary file, then the inexplicable outcome remains to be explored and explained - but would quickly go away if it was just a one-off artefacr.
1 Like