rips are just rips?
Posted by: French Rooster on 19 October 2018
On the Nd555 impressions thread, Dark Bear found that 3 different rips from the same album, by 3 different softwares, sound different for him.
I hope i make no mistake here in resuming his idea. Some members don’t agree with that, thinking or hearing no differences at all.
Dark Bear found that the rips made by the melco 100 ripper sound the best.
I am asking myself if the differences can be explained, if they really exist, by the quality of the cd drive mechanism. The one in the melco must be better made than the cheap one in a pc or mac (?).
Frank Yang posted:Alley Cat posted:Frank Yang posted:French Rooster posted:On the Nd555 impressions thread, Dark Bear found that 3 different rips from the same album, by 3 different softwares, sound different for him.
I hope i make no mistake here in resuming his idea. Some members don’t agree with that, thinking or hearing no differences at all.
Dark Bear found that the rips made by the melco 100 ripper sound the best.
I am asking myself if the differences can be explained, if they really exist, by the quality of the cd drive mechanism. The one in the melco must be better made than the cheap one in a pc or mac (?).
Can you just copy all the files to same machine and test?
I know that there are some command lines utils such as diff, checksum, sum, etc to check if the file contents are the same, try that first and then listen.The problem I suspect will be that even if the audio data is the same the files won't be due to subtle differences in metadata, perhaps even just a field specifying the ripping/encoder software.
Yes, I would suspect that the diff tools would say these files do not have the same contents even the data are the same. I have seen that many times, but my goal is to encourage folks here to dig deeper and investigate if there are any noticeable diffs in the actual data and why.
I know this can be challenging for some non-computer data specialists, but for some who are computer software professional or data experts would know what I meant here.
As already discussed, metadata and headers have to be stripped off before the files get compared. There are well established tools to do this and SIS has offered to help. He already did so when we were discussing the differences between Core rips and US rips and we came to the same conclusions by using different methods, if I remember correctly. There is nothing really new here, the difficulties in comparing rips, if any, are of technical nature.
Hej!
I'm not an audiophile, just an IT guy. So my simple world-view:
IF the components (CD drives, storage systems, network devices, cables, ...) work correctly AND you use lossless formats, then the differences in sound CAN only occur at the DAC and later. And it won't matter, how expensive the servers, drives, cables, switches are, as long as they work "good enough" on binary level (i.e. have very low bit error rates, which usually are corrected at least on storage/transmit levels).
Of course anything can have an impact on the analogue parts of the DAC... power issues, electronics in the vicinity, ... - also the clock of the DAC and other components around it impact the result.
And of course the CD itself is an analogue representation of digital data which a laser tries to read. The CD is not perfectly manufactured, can be "worn" (not from being read really, but by being physically touched) or have dirt on the surface. Plus audio CDs (as compared to "data CDs") deploy less "protection mechanisms" against data faults. (Less correction information to detect/faults faults.)
So yes of course: different CD of the same production, different CD drives, and different software reading the data (how they steer the drive, how hard they try to re-read assumed faulty areas, how they behave when re-reads yield different data) do have an impact on the ripped music. This will be visible in the decoded data of the audio file: it will be different. They might also make a difference at the beginning or end of the file, when detecting the beginning/end of the track on the CD.
If you want to compare those, even for lossless formats, I would always recommend to convert the files into WAVs and then compare them. If the length/start/end was perfect, a simple "diff" will work. If there's some difference in the number of samples, it should be checked, if the files can be "shifted" and then have the same content on the shared length.
Aside from that, as mentioned, all the parameters of the format (bit rate, sample rate, value representation, ...) are fixed. No debate to interpret them in different ways.
Once you have the data on disk, in whatever lossless format, and transmit it to the DAC: there won't be an impact of the components in between, as long as each transit uses lossless formats.
IF components are broken and produce frequent faults / data loss, you will usually have dropped streams, cracks/noise in the sound, etc. pp. - but those will be noticeable as such.
(Assuming the DAC is fed by a sufficiently well programmed buffer to remove the little bit of jitter occurring in local systems and LAN/WLAN networks. It definitely should not convert data at the speed they arrive - e.g. (W)LAN anyway is not intended for synchronized streams, just for sending small packages of data.)
There's the comment on "world is more complex than binary abstraction" - that's fully true. Within each component there's electrical (or even optical) noise. But that's the purpose of the digital abstraction digital computers (and other exist, but are not very prominent) work with: that the abstraction to binary values yields an initial loss of complexity/detail (compared to real world analogue data) - but once you have data digitalized and work correctly with them, you maintain the data "as is".
That's the reason why a digital phone call across the world is way more crisp and better to understand than an analogue phone call - you lose information at the very point of digitalization (and you decide how much, but the format, technology to ADC, plus encoding) and after that you copy the data (usually, depends on requirements, e.g. real-time vs. quality) without further loss across the world.
Digital data abstraction allows you to regain data from analogue noise (by re-digitalization of analogue interim data) and thus to "refresh" your data at every transmission step. When adding check-sums, you will be able to detect nearly every transmission fault and can correct them. (Here you will usually make a difference between real-time data like a phone call: responsiveness is more critical then perfect replication - so you'll drop data recognized as faulty; it time is not critical, you transmit faulty data again and the copy is "perfect", like at file transfers.)
Since "refresh" is not possible with analogue signals (usually you cannot separate "noise" from "data"), their quality will degrade with each step/hop they are transported.
Now you can take my world-view apart. :-)
Philipp
PS: Okay, we can discuss "data rot of data not protected by check-sums on storage" and "occasional bit faults in non-ECC protected RAM" and these things... those would not be detected and can lead to degradation of data quality. But those are such infrequent, I very much doubt anybody will hear them. If they were frequent, all your digital devices would constantly crash or present wrong textual data or tell you, that data cannot be read, ...
PPS: Sorry, got longer than intended.
Frank Yang posted:French Rooster posted:On the Nd555 impressions thread, Dark Bear found that 3 different rips from the same album, by 3 different softwares, sound different for him.
I hope i make no mistake here in resuming his idea. Some members don’t agree with that, thinking or hearing no differences at all.
Dark Bear found that the rips made by the melco 100 ripper sound the best.
I am asking myself if the differences can be explained, if they really exist, by the quality of the cd drive mechanism. The one in the melco must be better made than the cheap one in a pc or mac (?).
Can you just copy all the files to same machine and test?
I know that there are some command lines utils such as diff, checksum, sum, etc to check if the file contents are the same, try that first and then listen.
you must ask DB.
Darke Bear posted:nbpf posted:..I do not know what an "high-level abstracted level" is. My suggestion was simply to check if your files are identical or not. This is be done by inspection: no measurements are needed, just a plain bit-by-bit comparison.
That is the problem - not understanding what I'm actually describing.
What do you think a 'bit' is? Can you hold it in your hand? no.
Abstraction is looking at things at too high a level and missing the trees for the wood to reverse that old saying. It is very useful - and essential - to be able to use high-level view on things, but it does not explain what is happening when actual non-abstract devices handle all of the data via physical media and electricity and hence magnetism - and then 'electromagnetism'.
We are not talking 'woo woo' stuff here, this was taught me 40 years ago in my First Year 'Electromag' course when I was a naive youth.
A bit is stored via a media (usually) - my 'Solid State' first year coarse... not weird science (good film though).
I'm trying - unsuccessfully and on verge of giving up - to explain you can't ignore the underlying reality because the higher-level abstraction is naturally easier to grasp when the former may - just may - have something to do with the perceived effect.
But people often want things simple and is worse when they think they understand something but actually are missing it. The 'unknown Unknown' of Donald Rumsfeld fame - in my case it is the 'known Unknown' is all.
DB.
I am actually not sure that not understanding what "high-level abstracted level" means is a problem. I would rather feel uneasy if I would end up convincing myself that I understand what it means.
Again, if you really believe that two files cannot be checked for equality, then you should probably abandon the route that you are about to undertake: without reliable equality checks there are no safe backups, no way to reliably transmit data across a network, no way to upgrade your ND555. In fact, most of your electronic devices would actually be bricks if the question of whether two files are identical or not could not be answered with a very simple and reliable test.
And, again, if two music files are not identical, there is no reason why they should sound the same and hence no reason to be surprised if they sound differently.
dBpoweramp and foobar both have tools to allow you to compare the audio data in files. They strip out metadata and compute checksums. It is extremely unlikely that two files with the same checksums are different. As close to impossible as it is possible to get. In addition dbpoweramp has a tool to allow you to compare the checksums of your rips with the checksums in the accuraterip database. Melco themselves use Accuraterip.
It is just pointless to speculate about why two files might sound different unless you first establish whether they are different.
(Of course if you believe that it is possible to transmit data which evades checksum based error detection then you should arguably stop reading or posting on this thread, for we might all be reading entirely different posts.) (And close your bank account).
Dark Bear never said that the rips are identical, just 3 different rips of a same album, done by 3 different software, and not sounding the same. Tell me if i am wrong.
French Rooster posted:Dark Bear never said that the rips are identical, just 3 different rips of a same album, done by 3 different software, and not sounding the same. Tell me if i am wrong.
Which is why this discussion becomes pointless.
Three different cups of Verona coffee from Starbucks. "They don't taste the same." Ok . . . different employees made them? Starbucks changed the beans or roast over time? The equipment was cleaned, or not? The coffee connaisseurs MAY be interested in the fact that the three cups taste different, but probably are MORE interested in why. Because maybe the variability in preparation is significant. Or maybe nothing changed, and, maybe to 237 other customers, they all taste the same. Which leads to the conclusion that while that one customer had faithfully reported her or his experience, or maybe a number of customers report the same experience (they taste different, but in perhaps different ways to different customers) it is nothing MORE than that. Inherent variability in the perception of taste. A report of perception that whilst interesting gives the connaisseur community nothing more than the reality that "we all taste differently." Perhaps that was the only intent of the original customer -- he reports his experience with no desire (stated without judgment) to figure out WHY, and its the community that "demands" answers.
Here, it is reported that rips on one piece of hardware sound different than rips on another. See above.
There is no way of telling which rip, if they are not identical, is identical to the file sent to the CD stamper....
best
David
It must be a big thing if dbPoweramp is not accurate?
Frank Yang posted:It must be a big thing if dbPoweramp is not accurate?
perhaps dbpoweramp is accurate but not the cd drive of a pc or mac....
French Rooster posted:Frank Yang posted:It must be a big thing if dbPoweramp is not accurate?
perhaps dbpoweramp is accurate but not the cd drive of a pc or mac....
In that case, dbpoweramp always reports issues, did DB check that?
Frank Yang posted:French Rooster posted:Frank Yang posted:It must be a big thing if dbPoweramp is not accurate?
perhaps dbpoweramp is accurate but not the cd drive of a pc or mac....
In that case, dbpoweramp always reports issues, did DB check that?
in unitserve vs uniticore rips, the two softwares claimed bit perfect ripping. The rips appeared identical but sounded not the same, ( 2017 thread). Mystery...
Philipp vH posted:Hej!
I'm not an audiophile, just an IT guy. So my simple world-view:
IF the components (CD drives, storage systems, network devices, cables, ...) work correctly AND you use lossless formats, then the differences in sound CAN only occur at the DAC and later. And it won't matter, how expensive the servers, drives, cables, switches are, as long as they work "good enough" on binary level (i.e. have very low bit error rates, which usually are corrected at least on storage/transmit levels).
This statement is contradicted by numerous observations / experiments. When a theory is contradicted by numerous observations / experiments, the most likely explanation is that the theory is wrong.It very rarely works the other way around.
alainbil posted:Philipp vH posted:Hej!
I'm not an audiophile, just an IT guy. So my simple world-view:
IF the components (CD drives, storage systems, network devices, cables, ...) work correctly AND you use lossless formats, then the differences in sound CAN only occur at the DAC and later. And it won't matter, how expensive the servers, drives, cables, switches are, as long as they work "good enough" on binary level (i.e. have very low bit error rates, which usually are corrected at least on storage/transmit levels).
This statement is contradicted by numerous observations / experiments. When a theory is contradicted by numerous observations / experiments, the most likely explanation is that the theory is wrong.It very rarely works the other way around.
"Experiments?" you take much license with that word.
French Rooster posted:Dark Bear never said that the rips are identical, just 3 different rips of a same album, done by 3 different software, and not sounding the same. Tell me if i am wrong.
Dark Bear never said whether the rips were identical or different, he has not given us a piece of information that is critical to the understanding of why he might be hearing a difference. That’s why some folk on this thread are getting aggravated with a level of speculation that is entirely pointless until a basic fact is established. Are the audio portions of the rips the same, or are they different? Simple question, simple to find the answer. Depending on the answer, further questions can be asked.
French Rooster posted:Frank Yang posted:French Rooster posted:Frank Yang posted:It must be a big thing if dbPoweramp is not accurate?
perhaps dbpoweramp is accurate but not the cd drive of a pc or mac....
In that case, dbpoweramp always reports issues, did DB check that?
in unitserve vs uniticore rips, the two softwares claimed bit perfect ripping. The rips appeared identical but sounded not the same, ( 2017 thread). Mystery...
But they weren’t identical, no mystery at all. I measured them with professional file analysis tools.. simple
i know it’s fun to speculate on some extra dimensional interaction, but I am afraid life is somewhat more grounded and less exotic.
Alley Cat posted:Darke Bear posted:I just ripped a new copy via Melco D100 of an early Linda Ronstadt album CD of that name and put it alongside the renamed folder containing the Rip I did a few days ago on my PC, so I have both sets of files on the same server in folders side by side and can select and play from each - and they sound different and the D100 version has better low-level detail and note-purity.
Don't know why, but I can hear it.
DB.
Have been following this with interest - presumably they are all ripped to the same format.
I'd imagine that if all the rippers are AccurateRip based that the actual audio data should be identical, metadata, position of audio data within the file and so forth may not be.
Differences could be down to the actual encoder for the particular format you're saving in. Quite possible the encoder/ripping software could be buggy even if metadata looks ok, no guarantee the audio saved is true to source even if the software says (and has) ripped it accurately if errors creep in creating the audio file.
I assume as far as possible each file is being played from the same USB device or NAS, though it might be difficult to differentiate one from another unless you can actually play based on a specific filename ?
I think in all honesty this may be the kind of thing you'll obsess with for a little while then ultimately forget in the grand scheme of things unless the sonic difference is huge. Played with 'audiophile' ethernet cables for a while, have now forgotten about them and just use what I have.
It is useful to distinguish between the notion of bit perfectness, bit perfectness tests and methods for obtaining bit perfect rips.
There is only one natural notion of bit perfectness but, of course, many methods of ensuring that and testing if rips are bit perfect or not.
AccurateRip is one such methods. It relies on internet databases to store track checksums and CD reader offsets. Thus, its effectiveness very much depends on the quality and coverage of the databases. If one rips a track that is not annotated in the database, no checksum comparison can be made, of course. In this case any decent ripping software will make multiple rips of the track and compare them locally bit by bit.
It is almost inevitable that the question of "which rips are better" keeps on surfacing from time to time. When the Core came out, for instance, early adopters found out that Core rips and UnitiServe rips were different. You can find the remainders of week long discussions in this forum.
The main source of confusion in discussing the question of "which rips are better" is that different contributors naturally have different understandings of what it means for a rip to be "better" than another one.
It goes without saying that each of us is entitled to adopt whatever notion of "better" one likes most: more bit perfect, richer in metadata, better sounding are all legitimate notions of "better".
But no matter what our individual preferences are, we should be aware of the fact that there is no obvious correlation between sound quality and accuracy: it is perfectly possible (albeit not necessary, of course) that a bit perfect copy of an album sounds significantly worse than a non bit perfect copy: what best pleases our hearing is not necessarily what comes closer to the original. This implies that, if one aims at obtaining copies that are as accurate as possible, listening tests are completely irrelevant. Conversely, if one in primarily interested in sound quality and does not care about ripping accuracy, one does not need to care about bit perfectness.
French Rooster posted:Frank Yang posted:French Rooster posted:Frank Yang posted:It must be a big thing if dbPoweramp is not accurate?
perhaps dbpoweramp is accurate but not the cd drive of a pc or mac....
In that case, dbpoweramp always reports issues, did DB check that?
in unitserve vs uniticore rips, the two softwares claimed bit perfect ripping. The rips appeared identical but sounded not the same, ( 2017 thread). Mystery...
No, the rips did not appear identical and they were not identical. They were very obviously different and some found that they sounded differently. Other found that they sounded the same. As always, the outcome of listening tests is highly subjective. This makes listening tests very unsuitable methods for assessing the equality of music files.
In contrast, checksum tests and bit by bit comparisons are very robust equality tests. They are very fast, can be easily reproduced and the probability of false positives is nearly zero. If this was not the case, it would be impossible to install operating systems from disks, backup data, send files across networks, etc.
Simon-in-Suffolk posted:French Rooster posted:Frank Yang posted:French Rooster posted:Frank Yang posted:It must be a big thing if dbPoweramp is not accurate?
perhaps dbpoweramp is accurate but not the cd drive of a pc or mac....
In that case, dbpoweramp always reports issues, did DB check that?
in unitserve vs uniticore rips, the two softwares claimed bit perfect ripping. The rips appeared identical but sounded not the same, ( 2017 thread). Mystery...
But they weren’t identical, no mystery at all. I measured them with professional file analysis tools.. simple
i know it’s fun to speculate on some extra dimensional interaction, but I am afraid life is somewhat more grounded and less exotic.
good to hear that and clarify. I read the end of the thread « serve vs core rips » and the conclusion was that they were identical. But the thread was continuing on another thread that i have not read. With my french / english it is not also easy to understand all....
likesmusic posted:French Rooster posted:Dark Bear never said that the rips are identical, just 3 different rips of a same album, done by 3 different software, and not sounding the same. Tell me if i am wrong.
Dark Bear never said whether the rips were identical or different, he has not given us a piece of information that is critical to the understanding of why he might be hearing a difference. That’s why some folk on this thread are getting aggravated with a level of speculation that is entirely pointless until a basic fact is established. Are the audio portions of the rips the same, or are they different? Simple question, simple to find the answer. Depending on the answer, further questions can be asked.
It would be cool if DB could send its 3 rips to analyze by someone here, with appropriate tools.
nbpf posted:French Rooster posted:Frank Yang posted:French Rooster posted:Frank Yang posted:It must be a big thing if dbPoweramp is not accurate?
perhaps dbpoweramp is accurate but not the cd drive of a pc or mac....
In that case, dbpoweramp always reports issues, did DB check that?
in unitserve vs uniticore rips, the two softwares claimed bit perfect ripping. The rips appeared identical but sounded not the same, ( 2017 thread). Mystery...
No, the rips did not appear identical and they were not identical. They were very obviously different and some found that they sounded differently. Other found that they sounded the same. As always, the outcome of listening tests is highly subjective. This makes listening tests very unsuitable methods for assessing the equality of music files.
In contrast, checksum tests and bit by bit comparisons are very robust equality tests. They are very fast, can be easily reproduced and the probability of false positives is nearly zero. If this was not the case, it would be impossible to install operating systems from disks, backup data, send files across networks, etc.
thanks Nbpf, Simon had already clarified it . It was what i understood when i read a bit the end of the thread « unitserve rips vs uniticore « . But this thread was continuing in other thread that i didn’t found.
nbpf posted:Alley Cat posted:Darke Bear posted:I just ripped a new copy via Melco D100 of an early Linda Ronstadt album CD of that name and put it alongside the renamed folder containing the Rip I did a few days ago on my PC, so I have both sets of files on the same server in folders side by side and can select and play from each - and they sound different and the D100 version has better low-level detail and note-purity.
Don't know why, but I can hear it.
DB.
Have been following this with interest - presumably they are all ripped to the same format.
I'd imagine that if all the rippers are AccurateRip based that the actual audio data should be identical, metadata, position of audio data within the file and so forth may not be.
Differences could be down to the actual encoder for the particular format you're saving in. Quite possible the encoder/ripping software could be buggy even if metadata looks ok, no guarantee the audio saved is true to source even if the software says (and has) ripped it accurately if errors creep in creating the audio file.
I assume as far as possible each file is being played from the same USB device or NAS, though it might be difficult to differentiate one from another unless you can actually play based on a specific filename ?
I think in all honesty this may be the kind of thing you'll obsess with for a little while then ultimately forget in the grand scheme of things unless the sonic difference is huge. Played with 'audiophile' ethernet cables for a while, have now forgotten about them and just use what I have.
It is useful to distinguish between the notion of bit perfectness, bit perfectness tests and methods for obtaining bit perfect rips.
There is only one natural notion of bit perfectness but, of course, many methods of ensuring that and testing if rips are bit perfect or not.
AccurateRip is one such methods. It relies on internet databases to store track checksums and CD reader offsets. Thus, its effectiveness very much depends on the quality and coverage of the databases. If one rips a track that is not annotated in the database, no checksum comparison can be made, of course. In this case any decent ripping software will make multiple rips of the track and compare them locally bit by bit.
It is almost inevitable that the question of "which rips are better" keeps on surfacing from time to time. When the Core came out, for instance, early adopters found out that Core rips and UnitiServe rips were different. You can find the remainders of week long discussions in this forum.
The main source of confusion in discussing the question of "which rips are better" is that different contributors naturally have different understandings of what it means for a rip to be "better" than another one.
It goes without saying that each of us is entitled to adopt whatever notion of "better" one likes most: more bit perfect, richer in metadata, better sounding are all legitimate notions of "better".
But no matter what our individual preferences are, we should be aware of the fact that there is no obvious correlation between sound quality and accuracy: it is perfectly possible (albeit not necessary, of course) that a bit perfect copy of an album sounds significantly worse than a non bit perfect copy: what best pleases our hearing is not necessarily what comes closer to the original. This implies that, if one aims at obtaining copies that are as accurate as possible, listening tests are completely irrelevant. Conversely, if one in primarily interested in sound quality and does not care about ripping accuracy, one does not need to care about bit perfectness.
I can follow your argumentation fully. Sometimes perfect might sound less good to the ears than non perfect. I have experienced this also in the past where at first the system seems to sound better with more distortion than without. Only when you start to dig into it more you realize the positive aspect of the change...... I guess a similar experience can be the case with the ripping. And we also have to realize that the brain is capable of dealing with all kinds of inaccuracies. With music I have always found that when the level of relaxation increases things normally are better.
Bert Schurink posted:With music I have always found that when the level of relaxation increases things normally are better.
Undoubtedly so, Bert. The "experiment" has not been done. Which is why this thread died with zero resolution. But while we failed to address the matter with rigor, the discussions around our perceptions, including yours about the level of relaxation, are still (somewhat) interesting to me.
[@mention:1566878603992423]. Are your non-Melco rips from Naim machines or other devices?
Thanks,
Jan
no naim rippers involved, unfortunately.