I’ve sent you two files.
I have no doubt what I am hearing, and which rip is the better. If I get time I’ll try CueTools, as you suggest.
Just in case some readers don’t know what AccurateRip (AR) is, here’s some info.
Many CD rippers allow for matching rips back to AR (dbpoweramp, EAC, cuetools, and others). Essentially, one’s CD rip is compared to the rips others have submitted of the same CD. Consequently, if one’s rip is a bit perfect match back to another person’s rip of a different copy of the CD, using different drives, on a different computer, then one can be 100% sure that they got a bit perfect rip. Even matching ONE other person’s rip is very strong evidence (think about the odds that another person’s rip would have exactly matching frame errors; it has to be billions to one). One does have to be a bit careful if there is only one AR match. That’s only because the single match could be back to your own submission to the AR database. Obviously that wouldn’t be true with one’s initial rip. But if you’re comparing your rip to the AR database at some later time, this could be true. In this case, an AR of 2 or more gives one complete confidence of a bit perfect rip.
First of all, let’s commend David for his honesty. Unlike many audiophiles who are certain that they can hear a difference in SQ, even where there is none, David was willing to put his beliefs to the test.
I received the files in question from David. First, I removed the metadata (which surely differs between the two).
% ffmpeg -y -i '14 - Nashville Cats 1.WAV' -map_metadata -1 -codec copy a.wav % ffmpeg -y -i '14 Nashville Cats.wav' -map_metadata -1 -codec copy b.wav
Now, let’s check that they are the same length:
% ls -l a.wav b.wav -rw-r--r-- 1 distler 27647838 Dec 18 09:14 a.wav -rw-r--r-- 1 distler 27647838 Dec 18 09:14 b.wav
So far, so good. Alas, an examination in Audacity points out a problem: there’s a 12ms time-shift between the two files (12ms more silence at the beginning of b.wav; 12 ms more silence at the end of a.wav). They’re the same length, but they’re not quite the same.
That’s not a problem. We can trim the silence from the beginning and end of both files.
% ffmpeg -i a.wav -af silenceremove=start_periods=1:stop_periods=-1 c.wav % ffmpeg -i b.wav -af silenceremove=start_periods=1:stop_periods=-1 d.wav
Let’s check that the files with the silence removed are still of exactly the same length.
% ls -l c.wav d.wav -rw-r--r-- 1 distler 27069974 Dec 18 10:07 c.wav -rw-r--r-- 1 distler 27069974 Dec 18 10:08 d.wav
Great! OK, but are they the same?
% sha256sum c.wav d.wav 1b7ef363eeaee1b6e3dea359c3ba983a0b989075a7a59804896f6af63aa26763 c.wav 1b7ef363eeaee1b6e3dea359c3ba983a0b989075a7a59804896f6af63aa26763 d.wav
Yup! They are exactly byte-for-#@%&-byte the same.
So, what does that teach us about the ability of even the most honest of audiophiles to fool themselves?
If you’re not willing to put your beliefs to the test, then you are almost certainly fooling yourself.
I accept everything except your conclusion. Given that one sounds significantly better than the other in my system, I can only conclude that there is something relevant which is not being measured. Please remember that I did not want this to be the case, as it has cost me €1k and now requires a significant time input.
You are of course welcome to come and hear it for yourself if you are ever in my part of the world.
There’s nothing being “measured” here. We’re just comparing the two files — bit-for-bit.
- The metadata is different. I removed it.
- The silence at the beginning and ending of the track? I removed it.
Everything else is bit-for-bit identical. You are welcome to imagine that one sounds better than the other, but they are identical.
I once had the idea that discs ripped with dbpoweramp sounded better if I used the slow speed rather than the full speed. I then downloaded the binary comparator plugin for Foobar and found that my rips were bit identical regardless of speed. So now I use full speed unless the disc is scratched.
Since it’s so easy to find out whether rips are bit identical or not I cannot help but be sceptical about the Melco D100. I just looked again at the product page, and I don’t see, as a ripping tool, any technical data on benchmarking accurate rip levels compared to alternatives, ie a technical explanation of why the product has any value.
I’m not suggesting that there aren’t products out there that do poor sounding rips, but let’s get some basic foundations in place first, ie are we comparing bit identical rips or not.
It’s trivial to assess this for anyone who owns a D100 and a PC, if they dare.
Invert phase null test ? Would be able to ‘hear’ the differences in isolation.
But if they are bit for bit identical then there should be silence if you invert the phase of one of the files and play them both at exactly the same time.
I beg to differ. I know I am not imagining it, and it appears to apply to all of my rips.
There is some other factor at play here. No doubt it will emerge eventually. It always does!
If you, or the vendor you bought your device(s) from were right, the control mechanism of nuclear weapons wouldn’t be reliable.
Two identical files cannot sound different.
I did that, too. Here are the two files in Audacity:
Now we invert
And, finally, we choose
Tracks→Mix→Mix and Render:
Dead silence. The two tracks are identical. Any difference David is hearing is entirely in his head.
But could we even have expected anything different? Of course not. Ripping a CD to WAV is simply transcribing the PCM data from pits on a silvered disk to bits on your hard drive. It’s either done correctly (same bits in both media) or it’s done incorrectly.
If it’s done correctly, then the bits transcribed are identical to the bits on the CD. There’s no “room” for improvement.
Very elegantly explained and done.
Unfortunately, you can’t have a discussion about being “bit-for-bit identical” with someone that that doesn’t understand the basics of digital audio. I’ve watched this discussion play out endlessly on Audiophile Style, which is loaded with well-meaning people that don’t know what a “bit” is; hence, can’t understand that “bit-for-bit identical” means they will sound “exactly the same” because the embedded PCM data is identical.
Similarly, this demographic cannot grasp that these digital files themselves do not contain data with “timing” information that can be “smeared” by a NAS storage device or via asynchronous Ethernet transmission, so that a discussion of “jitter” is meaningless outside of synchronous digital transmission and the D-to-A conversion process.
Finally, the lossless compression process is “mystifying” - one person explained lossless compression to me like this: it’s like taking a sheet of paper, crumpling it up, then spreading it back out flat on a table. It’s the same piece of paper, but is it really the same? That’s the difference between FLAC and WAV.
Snake Oil… it’s not just for breakfast anymore.
Nail in the coffin. Well done.
As ALAC is supposed to be bit for bit perfect copy when unwrapped does that mean there is no sound difference also? Not being scientifically minded at all I’m just interested.
That piece of bullshit is trivially rebutted, by the same technique as above.
- Take a WAV file and convert it to FLAC, using the highest compression possible.
- The FLAC file (crumpled paper) is clearly different from (in particular, much smaller than) the original WAV file.
- Now convert the FLAC file back to WAV (uncrumple the paper).
- Compare the original WAV file with the new one. They are identical.
With the greatest of respect to all of you, you are wrong. I know what I am hearing and you don’t. The explanation will emerge eventually. Meanwhile, I am hearing familiar music better than ever before.
Also with the greatest respect, my sincere answer is that the explanation is already well-known:
@Jacques_Distler just to be clear, I assume you listened to the two files before any modifications where made and to you they sounded the same in your system?
If his system is of sufficient quality, he will hear the difference.