Calling all experts on digital music data

A discussion in the current thread Melco N10 Part 2 focussing on different sound of CD files ripped on different devices/software has speculated about whether rips were accurate, and on whether other factors such as metadata embedded in different ways by two different rippers might affect the playing process in some way.

However it has now reached the point where two files, one ripped by Melco and another on a PC, have been stripped of metadata and compared using cmp on a Linux machine, with no byte difference reported, meaning on that basis the two are identical. However, in listening tests on the two stripped files, same player/system, several people consistently heard a difference. And the two stripped files looked slightly different when the audio was analysed using Audacity.

On the face of it this is impossible - identical files yielding different audio. This is beyond me, hence this thread - what else might be going on to explain the anomaly?

Hereā€™s a link to the post in the other thread reporting the data: Melco N10 Part 2

If you enjoy the way your system replays digital music why worry about it?

Who said Iā€™m worried? I am curious, it being something I donā€™t understand.

And for anyone considering what device to buy/use for ripping CDs it may be of great significance, as, seemingly, even that process can affect the sound of the music forever after. Except if the affecting factor can be identified there may be a way of converting files to whatever the apparently different format (or whatever) might be.

2 Likes

If they are identical they canā€™t sound different. Iā€™m a bit surprised, however, that two different products would rip bit-identical. Did you cmp the entire length of the files or did you skip?

Are the 2 files consistently identified when listened to blind?

If they are truly bit-identical then I canā€™t see how they could sound differentā€¦

2 Likes

I, too cannot understand how two files with identical bytes can sound different - which is the very reason for this thread!

It is not my file/testing: I put a link in my OP, but for simplicity I will take the liberty of copying @Peter1480ā€™s report below. It followed reports by several people, some of whom seem quite measured in their assessments, reporting that rips on Melco sounded better, regardless of device on which played, and speculation then about rip accuracy and if not that then passible side-effects of supplementary embedded like metadata.

In principle, there are different reasons why two identical files could sound differently.

All these reasons, however, are external to the files themselves and most of them would not yield reproducible outcomes. This would be, for instance, the case if a system would sound differently at different times, perhaps because of differences in the power grid, electrical load, etc. In this case, two identical files or, indeed the same file would sound differently.

Another possible (albeit unlikely) reason is that a system is sensitive to file names. This possibility could be easily tested (and falsified or verified) by renaming the files.

Yet another possibility is that the two identical files do actually sound the same but that the experiments done to assess whether the two files sound the same or not are flawed.

But thatā€™s precisely what bit-perfectness tests are designed to assess: that the relevant part of a rip (that is, what is not metadata, leading or trailing zeros, etc.) is identical (typically checksum identical) to a specification. Perhaps I am missing somehting?

Thereā€™s something ā€œstrangeā€:
If files are bitwise identical (which would include any meta-data to be removed or identical), Audacity will NOT be able to tell them apart in whatever way.
Iā€™d export both files to ā€œWAVā€ and compare again, but that should just ā€œexpandā€ otherwise identical files.

(And Iā€™d like to know the test setup: device(s) used, sequence/play-back condition, ā€œblind-testā€, ā€¦) - but then again, these people wonā€™t convince me it sounds different, unless they ā€œshowā€ it to me live - which will not happen, so Iā€™ll spare the bits for more text here.)

2 Likes

Looking forward to see if anyone comes up with anything with better test methology or can reproduce what we tried.

I would be interested in seeing and testing the files myself. I donā€™t have a Melco so cant do a rip test myself.

That is where Audacity was interesting.
I think it needs repeating with more rips to see if there is any consistency. (@Peter1480, is your son-in-law sufficiently interested?)

Have you examined the file headers using a file editorā€¦
there will be a difference somewhere, and you may find itā€™s in the file header description, or even one is canonical and the other is in the extensible format perhapsā€¦ this may invoke a different method or process when the file is streamed and rendered.

By all means drop box the files, and I can examine with bit editorā€¦
Remember there are multiple ways of encoding a ā€˜WAVā€™ fileā€¦ and the sample data is only fully defined when associated with its headerā€¦
We/I have seen this before in the early days of comparing CD rips.

Simon

1 Like

I believe they where ripped as flac not Wav, although this is likely a two stage process of ripping to Wav then encode that as flac. So perhaps the first stage is done differently for the Melco compared to eac?

If the melcos are quieter perhaps its putting metadata in to reduce gain. Obviously it would sound different and be easily identifiable as the volume is not the same?

1 Like

Itā€™s certainly interesting, Iā€™ve always found it slightly odd how much emphasis is given to Ethernet cables and switches but not the ripping and play back sources, which inevitably must be sources of noise. This is exactly why I went for a Uniti Core, to isolate it from a PC and have a cleaner power supply to the source. Rips are the best Iā€™ve heard.

Most comments on data files are made by software engineers who seem to really and truly believe that ACTUAL ones and zeroes are somehow floating down the wire and thus electrical interference just doesnā€™t apply, even though it applies to just about every other thing weā€™ve ever discovered because I code apps etc etc.

Their furious insistence that data is actually a real thing (not just an expression of switch state on a whiteboard) is now accepted wisdom. Theyā€™re experts! Even though they have no actual engineering expertise in the area of RF etc etc. Thatā€™s my cynical view, any way.

The fact is the device is an ELECTRICAL SWITCH and is thus subject to noise, so if your gear is sensitive enough, itā€™ll show up the differences. Therefore it is ENTIRELY POSSIBLE, unless you simply ā€˜refuse to accept it, despite evidence to the contrary.ā€™

Remember what Abraham Lincoln said: ā€˜I have a pair of Beats By Dre bluetooth headphones for my iPhone, and Spotify sounds just fine.ā€™

Apparently the tests were done on files with the metadata stripped out.

But when analysis of the file shows that the binary data comprising the whole files are identical, and they are played in the same system, where can the difference be coming from?

Hi - I really have no idea, but thereā€™s SOMETHING making the difference. All Iā€™m saying is ā€˜itā€™s just data, thereā€™s no differenceā€™, just isnā€™t true.

Exactly