SandyK is a friend of mine who I have known for a couple of years now. One thing that I have learned is that he does not joke, troll or hear things that are not there. He is sincere and passionate about music and accurate musical reproduction.
When he asked me to listen to two tracks, and see if I could hear differences, I was happy to listen and report what I heard, without pressure to hear anything or conform to an idea. Several others also listened to the same tracks. Independently, and without prompting, the majority heard the same difference. There were some people who could not hear the differences. The tracks we listened to were ripped on on a normal DVD-Rom and then a LG Blu ray drive. The BR drive sounded better. How much better is for yourselves to find out. SandyK's further experiments with dampening material on the drive had brought further audible improvements.
All I had to do is listen with my ears.
It was not an expected improvement at the end of a long and expensive build, or a pre-conceived idea, it was simply listening with my ears, and not having a closed mind when I found out the reason behind the improvement.
Cheers,
Will
When he asked me to listen to two tracks, and see if I could hear differences, I was happy to listen and report what I heard, without pressure to hear anything or conform to an idea. Several others also listened to the same tracks. Independently, and without prompting, the majority heard the same difference. There were some people who could not hear the differences. The tracks we listened to were ripped on on a normal DVD-Rom and then a LG Blu ray drive. The BR drive sounded better. How much better is for yourselves to find out. SandyK's further experiments with dampening material on the drive had brought further audible improvements.
All I had to do is listen with my ears.
It was not an expected improvement at the end of a long and expensive build, or a pre-conceived idea, it was simply listening with my ears, and not having a closed mind when I found out the reason behind the improvement.
Cheers,
Will
Yes, I used Exactfile, and the tracks were identical, as have been the further tracks he has passed my way to compare.
From a completely logical, looking at the facts basis, I do find it difficult to understand how or why they should around different, when they are the same 1's and 0's.
But they do sound different.
Personally, I think SandyK is on to something that will be excepted as standard normal thinking in a few years time. Just remember where you heard (or didn't
) first.
For the record, my intent for this thread was to discuss the data recovery capability and ease of use for various rippers. If the bits are confirmed by the accuraterip library then I'm not interested in opinions about the sound. I'd suggest this discussion concerning different sound from the same bits move to another thread with a suitable topic.
I'd say that these opinions fall into this category:
Boston Audio Society - ABX Testing article
Pete B.
I'd say that these opinions fall into this category:
Boston Audio Society - ABX Testing article
Pete B.
md5sum
md5sum produces an almost unique signature of any file, this allows you to see if two files are identical.
I don't know how to get an md5sum on windows but on unix (Solaris and Linux, MacOS and I imagine others too) its just
md5sum /your/path/to/your/files.wav
it will output a line like
b59238874de4924838be0d2801c4cf0f /your/path/to/your/files.wav
Rip your file with which ever ripper you use in which ever drive you want, then get the md5sum of the file. this will provide a check sum. Then rip the file again with the same drive and system, and compare the md5sum. Then try the second system and get the md5sum, repeat the process and get the md5sum. I have found ripping the file twice with the same hardware, does not always produce the same md5sum signature. I don't have a Blueray disk drive, but have found that DVD drives rip CD's do not hang or fail when ripping scratched as they did in the CDROM I used earlier.
md5sum is designed to make a UNIQUE signature for each file, but it is not possible to get from the signature back to the file. If you have different signatures who knows which CD rip was better? Especially if the CD was scratched.
Have fun
md5sum produces an almost unique signature of any file, this allows you to see if two files are identical.
I don't know how to get an md5sum on windows but on unix (Solaris and Linux, MacOS and I imagine others too) its just
md5sum /your/path/to/your/files.wav
it will output a line like
b59238874de4924838be0d2801c4cf0f /your/path/to/your/files.wav
Rip your file with which ever ripper you use in which ever drive you want, then get the md5sum of the file. this will provide a check sum. Then rip the file again with the same drive and system, and compare the md5sum. Then try the second system and get the md5sum, repeat the process and get the md5sum. I have found ripping the file twice with the same hardware, does not always produce the same md5sum signature. I don't have a Blueray disk drive, but have found that DVD drives rip CD's do not hang or fail when ripping scratched as they did in the CDROM I used earlier.
md5sum is designed to make a UNIQUE signature for each file, but it is not possible to get from the signature back to the file. If you have different signatures who knows which CD rip was better? Especially if the CD was scratched.
Have fun
Will,
This coincides closely to what we have found, over the last couple of years of experimentation at the Pacific Northwest Audio Society. Your friend Sandy is on the right track it seems. I've never read any of his posts before tonight, but his opinions validate what we've found to be true.
Concerning BluRay burners, one of our members who owns and operates a SOTA recording/mastering studio burned identical tracks off of a SSHD using a conventional (Plextor) CD burner and a LG BluRay burner. The BluRay burned disk sounded better to him, although he wasn't certain why this would be. The next day, he went to his other job (Anesthesiologist at the UW Medical Center) and placed them under an electron microscope. The conventional Plextor burner had produced irregular edges on the pits, which were fairly jagged and rough while the BluRay burner has produced sharp, uniform and exact edges to the pits.
IIRC, he was not able to detect any other differences on the CD discs.
Others members have found that balancing and damping the actual discs helped as well.
Subsequent listening test (ABX) by the Club members produced statistically a very high level of significance in favor of the differences.
FYI: Here in Seattle, we have a lot of Software Engineers that are members of our Club and after listening have changed their opinions.
Best Regards,
TerryO
Last edited:
Mr. Phofman,
I believe that it's not only "perfectly possible" that a BluRay burner produces higher-quality CD-Audio burns than a CD-RW drive, but based on our results it actually does produce higher quality CD-audio burns. Given, that by the very nature of BluRay this should not be surprising as it must maintain a level of precision and accuracy that CD burners were never intended, nor designed for.
I'll concede that a track ripped by a BluRay drive probably has no inherent advantage over a track ripped by conventional drive, and they could be bit-perfect matches in the digital domain. However, as others here have suggested, the same track played back several times may actually have different errors each time.
Our experience with regard to PC-based servers, running Windows software, is that there are problems introduced in the playback. It's not my intention to debate software architecture, other than to say that a lot of these problems can be avoided by the use of other operating systems.
Best Regards,
TerryO
Now Terry, be nice! You live up there near Redmond. You don't want that knock on the door in the middle of the night....
Now Terry, be nice! You live up there near Redmond. You don't want that knock on the door in the middle of the night....
Mike,
It's far worse than that. The area I live in is now infested with Microsloth software engineers, project managers and executives.
Actually, they tend to be an interesting group of people as a whole.
However, the Software guys, along with Pilots, Doctors and Teachers have a tendency to be almost as stubborn as Norwegians.
Best Regards,
TerryO
md5sum produces an almost unique signature of any file, this allows you to see if two files are identical.
I don't know how to get an md5sum on windows but on unix (Solaris and Linux, MacOS and I imagine others too) its just
md5sum /your/path/to/your/files.wav
it will output a line like
b59238874de4924838be0d2801c4cf0f /your/path/to/your/files.wav
Rip your file with which ever ripper you use in which ever drive you want, then get the md5sum of the file. this will provide a check sum. Then rip the file again with the same drive and system, and compare the md5sum. Then try the second system and get the md5sum, repeat the process and get the md5sum. I have found ripping the file twice with the same hardware, does not always produce the same md5sum signature. I don't have a Blueray disk drive, but have found that DVD drives rip CD's do not hang or fail when ripping scratched as they did in the CDROM I used earlier.
md5sum is designed to make a UNIQUE signature for each file, but it is not possible to get from the signature back to the file. If you have different signatures who knows which CD rip was better? Especially if the CD was scratched.
Have fun
MD5 or any of the well known security hashes are really not suitable at all for checking if two music files are identical. Yes, if the MD5's match, they are identical. But if all the music samples match and the number of idle samples at the beginning or end of the track differs, MD5 will not match. This happens all the time when you rip CD's with different drives and different ripping software. And we would still call the ripped files bit identical, even if they differ by a few idle samples.
Therefore, you need to check the music samples only and ignore the idle samples for the comparison. There are several programs which can do this. One that comes to mind is CRC32 from Cyberdyne Software. This is somewhat old, but I'm sure you can find newer ones via Google.
Kurt
But that's the whole point of the read offset correction of EAC and dbPoweramp, combined with AccurateRip. If the read offset correction is set correctly for the drive, it doesn't matter whether you use EAC or dbPoweramp, or what drive you use. You'll get bit-for-bit identical copies, right down to the number of samples of silence at the beginning and end of each track. The CRC code used by AccurateRip does not neglect the samples of silence at the beginning and end of each track, so these must match exactly for AccurateRip to give the track being tested a clean bill of health.
Last edited:
I think TerryO has the right idea...
Two rippers which produce the same binary data have no inherent technical advantage. There are factors that can alter this... as mentioned previously, CD audio discs do not share the same level of built-in error correction that CD-ROM (discs) enjoy. So, EAC for example probes the drive for C2 statistics. This tells EAC when there's a chance that a sector was not read properly. C2 isn't foolproof. You can have reported errors on a correct read, and you can have unreported errors on a flawed read.
If a disc is in pristine condition, and the optical drive is of high quality, a max-speed rip and a slow C2-checked rip can produce identical results. But the C2 rip will have a higher probability of finding problems, and re-reading those sectors to attempt a perfect read.
Now, any time there's a C2 error, there will most likely be an error during each read (possibly not if the drive slows down to read more carefully, but probably even then still.) So, successive passes only serve to play "best 2 out of 3", or whatever threshold you've told EAC to use. The statistically most popular read wins. If all reads are different, and none of them come back C2-clean, the sector is "irrecoverable" and you get what you get.
Incidentally, AccurateRip is much of the same. The CRCs used to provide the confidence level are user-submitted. It's possible every user ripped with the same errors, and the original studio master is different. But it's unlikely. A confidence of 5 means nothing, really. A confidence of 120 is a pretty safe bet.
Moving on. There are NO fine details that won't be detected by a binary comparison of two rips. Sorry, this is not close-mindedness. This is fact. It's as certain as death and taxes. You have to understand that .WAV files have potential metadata which has no effect on the audio and can throw off a binary comparison, so you need a tool that will read the audio samples themselves. Not including the offset is cheating... that's part of being bit-perfect. Though, admittedly, it's a minor flaw that only affects the head and tail of a rip, so feel free to not care.
That said, while absolutely identical acquisition is trivial with digital media (including SSD vs. HDD vs. thumb drive vs. streamed-over-WiFi or 3G cell for all it matters...), identical presentation of digital data is NOT. This is where I believe TerryO has some credibility with his playback tests.
Does sample A, ripped on a CD-ROM and played from a magnetic HDD sound different than sample B, ripped on a BD-ROM and played from a SSD disk? Yeah, sure. Play sample B again and I'm sure it will sound different yet again. I would like to think that all digital transports (HDD, controller, memory, CPU, OS, optical link, DAC innards) are flawless, but that's sadly utopian. I would expect the difference up to the DAC itself to be so few and far between (0.000000000....0001%) as to be forgiven, (after all, bit errors in binary data are inexcusable for software -- but have you ever seen software crash?) but once that digital signal goes through the conversion to analog, every little thing matters. It matters along the digital path, too, but unless something is horribly wrong, it will almost certainly make it through, still intelligible. If not, get a new cable/DAC/memory stick, because yours is busted.
Two rippers which produce the same binary data have no inherent technical advantage. There are factors that can alter this... as mentioned previously, CD audio discs do not share the same level of built-in error correction that CD-ROM (discs) enjoy. So, EAC for example probes the drive for C2 statistics. This tells EAC when there's a chance that a sector was not read properly. C2 isn't foolproof. You can have reported errors on a correct read, and you can have unreported errors on a flawed read.
If a disc is in pristine condition, and the optical drive is of high quality, a max-speed rip and a slow C2-checked rip can produce identical results. But the C2 rip will have a higher probability of finding problems, and re-reading those sectors to attempt a perfect read.
Now, any time there's a C2 error, there will most likely be an error during each read (possibly not if the drive slows down to read more carefully, but probably even then still.) So, successive passes only serve to play "best 2 out of 3", or whatever threshold you've told EAC to use. The statistically most popular read wins. If all reads are different, and none of them come back C2-clean, the sector is "irrecoverable" and you get what you get.
Incidentally, AccurateRip is much of the same. The CRCs used to provide the confidence level are user-submitted. It's possible every user ripped with the same errors, and the original studio master is different. But it's unlikely. A confidence of 5 means nothing, really. A confidence of 120 is a pretty safe bet.
Moving on. There are NO fine details that won't be detected by a binary comparison of two rips. Sorry, this is not close-mindedness. This is fact. It's as certain as death and taxes. You have to understand that .WAV files have potential metadata which has no effect on the audio and can throw off a binary comparison, so you need a tool that will read the audio samples themselves. Not including the offset is cheating... that's part of being bit-perfect. Though, admittedly, it's a minor flaw that only affects the head and tail of a rip, so feel free to not care.
That said, while absolutely identical acquisition is trivial with digital media (including SSD vs. HDD vs. thumb drive vs. streamed-over-WiFi or 3G cell for all it matters...), identical presentation of digital data is NOT. This is where I believe TerryO has some credibility with his playback tests.
Does sample A, ripped on a CD-ROM and played from a magnetic HDD sound different than sample B, ripped on a BD-ROM and played from a SSD disk? Yeah, sure. Play sample B again and I'm sure it will sound different yet again. I would like to think that all digital transports (HDD, controller, memory, CPU, OS, optical link, DAC innards) are flawless, but that's sadly utopian. I would expect the difference up to the DAC itself to be so few and far between (0.000000000....0001%) as to be forgiven, (after all, bit errors in binary data are inexcusable for software -- but have you ever seen software crash?) but once that digital signal goes through the conversion to analog, every little thing matters. It matters along the digital path, too, but unless something is horribly wrong, it will almost certainly make it through, still intelligible. If not, get a new cable/DAC/memory stick, because yours is busted.
I do often wonder just how "perfectly" software gets copied to the HDD. Would a few bit's and bytes here and there really cause most software to not function? The way a number of the programs I use work, they may not be very good copies at all.
Still, I've been pleasantly surprised by the good rippers. With a decent drive, they seem to do a perfect job with almost all discs. And they let you know when there are problems. My turntables and tape recorders never did that!
Just a slight OT note. I used Plextor drives for years, because they are supposed to be the best. Phooey! Cranky, unreliable, and over priced. I'll take a Lite-On drive any day.
Still, I've been pleasantly surprised by the good rippers. With a decent drive, they seem to do a perfect job with almost all discs. And they let you know when there are problems. My turntables and tape recorders never did that!
Just a slight OT note. I used Plextor drives for years, because they are supposed to be the best. Phooey! Cranky, unreliable, and over priced. I'll take a Lite-On drive any day.
Yes, a single incorrect bit could crash your PC. Data transfer in the PC is assumed to be bit-perfect. If the HW starts failing (i.e. the bit-perfection is not always the case), people experience application and eventually system crashes (BSDs).
Back on the original topic of which Ripper is best, I think a few discussion points have been missed.
Assuming one agrees with both of those answers, Dbpoweramp wins hands down. The basic reason is Dbpoweramp can be set up with some much greater logic which can save you a lot of time along with wear and tear on your drive(s).
The best way I've found to set up Dbpoweramp is as follows:
Generally speaking that process will work flawlessly on the first pass for the majority of tracks. A slightly dirty CD may slip to the two pass mode for the occasional track, but will often still be successfully ripped without any special user intervention. Doing this saves a LOT of time in the long run, and you don't need to do anything special except for really dirty or scratched CDs.
EAC on the other hand works like this:
The way EAC works you're going to be spending a LOT of time looking at log files, and you're going to spend a LOT of time waiting for it to do it's secure ripping features. The secure ripping techniques it uses are also really hard on a CD drive, and will shorten the drive's lifespan.
Now, when it comes to handling a really damaged CD, EAC's brute force techniques are more successful than Dbpoweramp's secure mode. There were several really messed up cd's in my collection that I couldn't get an AccurateRip match with in Dbpoweramp, but EAC did successfully get a match.
That said, EAC is free, so it's a no brainer to keep on your hard disk for those scenarios. Dbpoweramp on the otherhand, when you add in it's tagging and utility features, walks all over EAC for day to day use or a big ripping project.
For comparing things ripped without the same offsets you can use binary comparators designed for this. dbpoweramp, foobar, and EAC each have this function, they'll basically scan through all the samples, figure out where they line up, then provide you a report describing how many are the same or different, and where they differ. For different pressings, AccurateRip will of course have each pressing in the database.
Q. How much time to you want to spend ripping
A. As little as possible (I assume)
Q. Would you like to prolong the life of your CD drive
A. Probably not critical, but it would be nice...
Assuming one agrees with both of those answers, Dbpoweramp wins hands down. The basic reason is Dbpoweramp can be set up with some much greater logic which can save you a lot of time along with wear and tear on your drive(s).
The best way I've found to set up Dbpoweramp is as follows:
- Attempt a fastest speed configured one-pass rip with no special error checking or other features (basically what itunes does)
- Check the results of that rip against Accurate Rip
- If the Accurate Rip database matches, go to the next track
- If the database doesn't match, re-rip in two pass secure mode (aggressiveness configured by user)
- If either pass in secure mode matches AccurateRip, you're done
- If secure mode fails, write a report and tell the user where the errors/issues were
- User monitors whether the CD is being ripped successfully by watching the little green/yellow/red icons next to each track which clearly tell you whether things are going well or poorly.
- Write a very informative log file which tells you the exact number of sample errors per track (if any) and where they're located, along with CRC and AccurateRip info
Generally speaking that process will work flawlessly on the first pass for the majority of tracks. A slightly dirty CD may slip to the two pass mode for the occasional track, but will often still be successfully ripped without any special user intervention. Doing this saves a LOT of time in the long run, and you don't need to do anything special except for really dirty or scratched CDs.
EAC on the other hand works like this:
- Choose between a fast ripping mode or some level of hardcore multipass ripping
- If you choose fast ripping, EAC will rip the whole CD quickly, and write the results to it's log file
- Open up the log file, figure out whether everything ripped cleanly
- If there were failures, clean the disk and re-rip (possibly using a more hardcore mode)
- Rinse and repeat
- If you choose the secure/hardcore mode, wait while EAC laboriously rips and compares every sector of two consecutive rips, then writes a log file with AccurateRip data
- Open the log file to see whether all the tracks were successfully ripped/matched
- Clean/polish the cd if neccessary, rinse and repeat
- Final log file only has a track percentage rating of quality along with CRC and AccurateRip info
The way EAC works you're going to be spending a LOT of time looking at log files, and you're going to spend a LOT of time waiting for it to do it's secure ripping features. The secure ripping techniques it uses are also really hard on a CD drive, and will shorten the drive's lifespan.
Now, when it comes to handling a really damaged CD, EAC's brute force techniques are more successful than Dbpoweramp's secure mode. There were several really messed up cd's in my collection that I couldn't get an AccurateRip match with in Dbpoweramp, but EAC did successfully get a match.
That said, EAC is free, so it's a no brainer to keep on your hard disk for those scenarios. Dbpoweramp on the otherhand, when you add in it's tagging and utility features, walks all over EAC for day to day use or a big ripping project.
For comparing things ripped without the same offsets you can use binary comparators designed for this. dbpoweramp, foobar, and EAC each have this function, they'll basically scan through all the samples, figure out where they line up, then provide you a report describing how many are the same or different, and where they differ. For different pressings, AccurateRip will of course have each pressing in the database.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.