Ripped CD via Sofware vs Manual Copy/Paste File Differences

[cjf]

OK,

 

I'm beginning to become concerned at the lack of availability and choices in "Good" CD Ripping applications for the Ubuntu/Linux platforms. The one I've been using and have trusted up until recently have slowly died off with every new release of the Ubuntu OS. My previous favorite was "RubyRipper" but that now refuses to work on my Ubuntu 16.04 LTS box. At one point I thought "K3B" was decent too but I kicked that to the curb once I realized it wasn't consistently making exact rips.

 

So because of the above issue I found myself in need of something new to Rip CD's. After much searching I decided to give "Audex" a try. Being skeptical of its abilities I decided to take one CD I was in need of ripping anyway and decided to make copies of it using two different methods in an attempt to confirm the accuracy of the RIP via AUDEX.

 

Method #1 was just to simply RIP the CD via AUDEX to .WAV to a folder on my local machine

Method #2 was to use a Caveman approach and browse to the mounted CDROM via the Ubuntu Desktop GUI and "CTRL/A ..CTRL/C" the CDROM contents and paste those files into a new folder on my local machine.

 

After the above was completed I took a look at the file sizes of the two copy approaches via the terminal. To my dismay, I saw that the files sizes were not the same. I then proceeded to puke out a "sha1sum" of each file and as I suspected the hashes were different also. When I say different I mean comparing any one given file to its sibling file which was copied via the opposite method.

 

After some additional waffling around I realized that the size difference between the two Copy approaches was off by exactly 70 Bytes  for each and every file. The files having the largest Byte count were those that were obtained NOT using the Ripping software. (..ie browse,copy,paste). I am sure the consistent 70 Byte difference is telling on some level but I'm not sure what to make of it.

 

 

I then proceeded to pull a Spectrogram of one sample file from each copy approach. Visually they appear the same to these old, failing eyes ?
 

AUDEX Rip

 

Manual Copy/Paste

 

So with all that said I suppose I will now need to listen to both versions to see if I hear any differences between them. BUT...while I am doing that, does anyone have any ideas on what may have happened to my 70 Bytes of Data in each file while using the Ripping software and what that Data may consist of?

 

Thanks

[audiventory]

2 hours ago, cjf said:

 

Method #1 was just to simply RIP the CD via AUDEX to .WAV to a folder on my local machine

 

Ripping may be done different ways, at various levels of data access and different ways at each of the levels.

 

Without source code of a ripper, we can't say exactly, that happens there.

 

We can use specially prepared test CD to compare rippers and ways of ripping.

 

Read details:

1. https://samplerateconverter.com/educational/safe-audio-cd-ripping
    
2. https://samplerateconverter.com/educational/best-cd-ripping-software

[cjf]

On 12/8/2018 at 11:23 PM, audiventory said:

 

Ripping may be done different ways, at various levels of data access and different ways at each of the levels.

 

Without source code of a ripper, we can't say exactly, that happens there.

 

We can use specially prepared test CD to compare rippers and ways of ripping.

 

Read details:

1. https://samplerateconverter.com/educational/safe-audio-cd-ripping
    
2. https://samplerateconverter.com/educational/best-cd-ripping-software

Thanks for your thoughts on this. I took a look at your website and it appears to discuss some interesting topics in regards to ripping music. I will revisit it at a later time and perhaps give your product a try as it appears to attempt and address many of my ripping concerns.

 

There is mention in some of your text about using online databases such as (Accurate rip) which is one thing I have always been afraid of using. It may be just my misunderstanding of what this online ripping reference is attempting to do.

 

Say you own a rare 1st pressing or original mastering of a particular CD. You then rip it using software that uses this online DB and the checksums do not line up with what the online DB has. This could be because 90% of people who the crappy remastered version and the average checksums from that crappy version have skewed the expected results of a particular ripped CD.

 

My question is, will the ripping software using this Accurate rip feature proactively try and "correct" the ripped data to match its online DB thus screwing up my rare/proper/original version of said music CD?

[kumakuma]

1 minute ago, cjf said:

Thanks for your thoughts on this. I took a look at your website and it appears to discuss some interesting topics in regards to ripping music. I will revisit it at a later time and perhaps give your product a try as it appears to attempt and address many of my ripping concerns.

 

There is mention in some of your text about using online databases such as (Accurate rip) which is one thing I have always been afraid of doing. It may be just my misunderstanding of what this online ripping reference is attempting to do.

 

Say you own a rare 1st pressing or original mastering of a particular CD. You then rip it using software that uses this online DB and the checksums do not line up with what the online DB has. This could be because 90% of people who the crappy remastered version and the average checksums from that crappy version have skewed the expected results of a particular ripped CD.

 

My question is, will the ripping software using this Accurate rip feature proactively try and "correct" the ripped data to match its online DB thus screwing up my rare/proper/original version of said music CD?

 

There is no risk associated with using software that supports the AccurateRip database.

 

These programs don't try to correct the data in any way. They simply tell you whether or not your rip matches other rips in the database.

 

This is shown in the log file in a format similar to the following:

 

Quote

AccurateRip Summary (DiscID: 000eeee3-00767c81-8a09410a)
    Track 01 : OK (v1+v2, confidence 16/23, with different offset)
    Track 02 : OK (v1+v2, confidence 16/23, with different offset)
    Track 03 : OK (v1+v2, confidence 16/23, with different offset)
    Track 04 : OK (v1+v2, confidence 16/23, with different offset)
    Track 05 : OK (v1+v2, confidence 16/23, with different offset)
    Track 06 : OK (v1+v2, confidence 16/23, with different offset)
    Track 07 : OK (v1+v2, confidence 16/21, with different offset)
    Track 08 : OK (v1+v2, confidence 16/21, with different offset)
    Track 09 : OK (v1+v2, confidence 16/23, with different offset)
    Track 10 : OK (v1+v2, confidence 16/23, with different offset)
        ->All tracks accurately ripped.

Different pressings and different releases are treated as different discs.

[audiventory]

8 hours ago, cjf said:

will the ripping software using this Accurate rip feature proactively try and "correct" the ripped data to match its online DB thus screwing up my rare/proper/original version of said music CD?

 

If safe ripper (after own error detection) in addition try compare total checksum with database (to detect error), it reduce total correct error-detection probability of CD ripping.

 

WARNING: be careful, when define name of probability event.
As example, "correct ripping probability" is not the same "total correct error-detection probability". There is diffrent formulas.

 

"Correct error detection" event isn't used, because the database don't try provide "correct ripping". But database using try provide "correct error detection".

Safe ripper try provide both: "correct ripping" and "correct error-detection". But we can compare same events only.

 

According formula from the article ("Simultaneous using of CD's checksum comparison and low level fault detection" part),

better way is use one way only:

ether

[own error detection of ripper]

or

[error detection ability of AccurateRip]

to decision "error is there ot not".

 

What is better, [own error detection of ripper] or [error detection ability of the database], I don't know. Because it demand serious study.

[diecaster]

23 minutes ago, audiventory said:

What is better, [own error detection of ripper] or [error detection ability of the database], I don't know. Because it demand serious study.

 

Of course the crowd sourced database is better. You keep arguing this point and your are incorrect. 

 

Doing error detection locally and not comparing the result to other rips done independently means you have no idea if your rip is accurate. You only know that your local hardware/software detected no errors. If you compare a checksum of your rip to a database of rips and find that your rip matches a hundred others, it is almost impossible for your rip to be inaccurate. 

[mansr]

Increasing the chance of detecting an error does not in any way increase the chance of there being an error. I don't know what orifice Audiventory is talking out of, since even the average arse should be able to get this right.

[audiventory]

4 hours ago, diecaster said:

Of course the crowd sourced database is better.

 

Not all, that you feel intuitively, is true.

 

Original checksum of files, that was used to pressing CD is unknown.
As example:
* full serie of CDs was manufactured with errors (probably undetectable or with usual error distribution) relative original files.
* or most of used CD-rippers have undetected programming bug, that distort the checksum.
And the serie give same checksums or biased checksums. And these checksums will not be same to original file checksum.

[audiventory]

@mansr If you want to communucate, be polite, please.

 

[tmtomh]

@cjf I can only speculate about the 70-byte difference, but I think I know what is causing it (or at least the general idea behind it). Audio CDs do not have filesystems in the same way a computer drive or CD-ROM disc does. Any drive that reads them has to approximate exactly where the data begins for a track. And different optical drives have different built-in offsets, which changes (usually by just a few samples, but sometimes by 100s of samples) where they start reading a track.

 

So my guess is that in CD-ripping mode, your drive's offset is 35 samples, which would equal 70 bytes.

 

In other words, assuming that there were no actual glitches in the ripping or copying process for all the tracks you ripped and copied from your CD, I would guess that the resulting files you have are indeed identical, and that the 70 byte difference exists in the form of 35 fewer samples at the beginning of each of one of your two sets of tracks.

 

Generally speaking, you are better off using a dedicated ripping app rather than the "caveman" method of cut and paste. The latter will work fine in most cases, but the former method is the only way to ensure an accurate rip (if that's possible - with a damaged CD sometimes it's not) with full error correction.

 

Finally, I would recommend you completely ignore @audiventory on the subject of the AccurateRip database - his math is wrong when he claims that using the database reduces the accuracy/error detection of CD rips, and if you look at what he posts pretty much anywhere in these forums, you'll see that this issue of AccurateRip is almost all he ever posts about, and the argument has been done to death.

[audiventory]

5 minutes ago, tmtomh said:

Finally, I would recommend you completely ignore @audiventory

 

Just do it immediatelly.

 

Here some interesting posts about "wrong" math (read to end of thread by link):

 

[tmtomh]

Agreed - except take "wrong" out of quotation marks, as it was clearly and simply demonstrated in that thread exactly why and how your math was incorrect.

[audiventory]

24 minutes ago, tmtomh said:

Agreed - except take "wrong" out of quotation marks, as it was clearly and simply demonstrated in that thread exactly why and how your math was incorrect.

 

"Incorrect"? So emotional. Non-technically.

 

There is (by link in my previous post) good demonstrated, why I wrote above:

Quote

WARNING: be careful, when define name of probability event.

 

Why you still don't ignore me? Ignore me right now!

[diecaster]

5 hours ago, audiventory said:

 

Not all, that you feel intuitively, is true.

 

Original checksum of files, that was used to pressing CD is unknown.
As example:
* full serie of CDs was manufactured with errors (probably undetectable or with usual error distribution) relative original files.
* or most of used CD-rippers have undetected programming bug, that distort the checksum.
And the serie give same checksums or biased checksums. And these checksums will not be same to original file checksum.

 

Not this sad argument again. 

 

No software, including yours, has access to the original master data so there is never a way to know if the CDs one is dealing with are the same as the original master. All anyone has access to are the CDs release to the general public. 

 

Most CD ripper software has the exact same bug that distort the checksums identically? You sound really desperate now and your credibility is out the window. 

 

Face it, your software, by not using AccurateRip, is second rate compare to other software packages like dBpoweramp and will never get recommended over ripping software that supports AccurateRip. 

[audiventory]

22 minutes ago, diecaster said:

No software, including yours, has access to the original master data so there is never a way to know if the CDs one is dealing with are the same as the original master. All anyone has access to are the CDs release to the general public.

Yes.

 

22 minutes ago, diecaster said:

Most CD ripper software has the exact same bug that distort the checksums identically? You sound really desperate now and your credibility is out the window.

It is just out of our control. Like share of similar rippers in results for same CD. Like programming bugs in rippers. Like similarly altered (by any reasons) series.

 

22 minutes ago, diecaster said:

Face it, your software, by not using AccurateRip, is second rate compare to other software packages like dBpoweramp and will never get recommended over ripping software that supports AccurateRip

 

You can't claim it without professional proper researches.

 

Again:

5 hours ago, audiventory said:

Not all, that you feel intuitively, is true.

 

I understand, that I often says things, that is out of comfort zone.

 

But try to keep open mind to:

• open new hidden details (even if it correct your previous knowledge) and
• get wider knowledge from first hands.

 

[diecaster]

23 minutes ago, audiventory said:

I understand, that I often says things, that is out of comfort zone.

 

You say things that are just plain wrong.

 

There is no better way to get perfect rips than to use software that checks the rips against the AccurateRip database. Since you do not have access to the original master CDs, there is no better method. Period. This method takes into account different masterings of CD titles.

 

The only reason you argue this is that your software does not use AccurateRip.

[audiventory]

31 minutes ago, diecaster said:

You say things that are just plain wrong. 

 

Emotions. Not tech talks.

 

31 minutes ago, diecaster said:

There is no better way to get perfect rips than to use software that checks the rips against the AccurateRip database. Since you do not have access to the original master CDs, there is no better method. Period. This method takes into account different masterings of CD titles.

 

As I understand, you use Accurate Rip, you like it, it is the best for you.

 

But here only need "small unimportant" detail - exact figures.

 

31 minutes ago, diecaster said:

The only reason you argue this is that your software does not use AccurateRip. 

 

• My software under control. I (and you too) can measure correct error detection and right correction probability.
   
• Second source of error detection decrease total correct error detection probability in any second source's probability of correct error detection.
   
• Also my ripping software control errors with 1 byte precision (like other safe rippers). Instead total checksum for all bytes.

[mansr]

20 minutes ago, audiventory said:

Second source of error detection decrease total correct error detection probability in any second source's probability of correct error detection.

Do you really not see how preposterous that idea is?

[diecaster]

6 minutes ago, audiventory said:

 

Emotions. Not tech talks.

 

 

As I understand, you use Accurate Rip, you like it, it is the best for you.

 

But here only need "small unimportant" detail - exact figures.

 

 

No, it's not emotions.

 

Fact: Your software has no way of determining if the CD being ripped is accurate. All it knows is that it encountered no errors during the ripping process. Your software assumes the rip is accurate if there are no errors.

 

Fact: A crowd source checksum based system, such as AccurateRip, is able to checksum each track as it is ripped and compare that checksum to a database of rip checksums. If the CD is in the database, and your rip checksums match dozens of other rip checksums, the probability of there being an error is nil. You cannot argue otherwise. The checksum algorithm is implemented in at least 10 different software packages so the odds of any one package polluting the database with errors and it not being discovered is nil. The crowd sourcing system means that any one bad CD will not become the master that other CDs are compared to.

 

You are the one emotionally compromised here. You are emotionally invested in your software and cannot see the forest for the trees. 

[audiventory]

42 minutes ago, mansr said:

Do you really not see how preposterous that idea is?

 

We have discussed it here:

https://www.computeraudiophile.com/forums/topic/38648-need-audio-cd-ripping-software-recommendations/?do=findComment&comment=825746

[audiventory]

37 minutes ago, diecaster said:

Fact: Your software has no way of determining if the CD being ripped is accurate. All it knows is that it encountered no errors during the ripping process. Your software assumes the rip is accurate if there are no errors.

 

Fact: A crowd source checksum based system, such as AccurateRip, is able to checksum each track as it is ripped and compare that checksum to a database of rip checksums. If the CD is in the database, and your rip checksums match dozens of other rip checksums, the probability of there being an error is nil. You cannot argue otherwise. The checksum algorithm is implemented in at least 10 different software packages so the odds of any one package polluting the database with errors and it not being discovered is nil. The crowd sourcing system means that any one bad CD will not become the master that other CDs are compared to.

 

Fact 1: I (and you) can righ now measure all probabilities for any stand alone ripping system (CD-drive + ripper software).

 

I (and you) can say: I know.

 

Fact 2: I (ans you) can't right now (I'm not ready to say now, how to do it even) measure probabilities ot ripping database, due it is very complex system.

I (and you) can say: I believe.

 

Do you feel difference between "I know" and "I believe"?

[mansr]

47 minutes ago, audiventory said:

We have discussed it here:

https://www.computeraudiophile.com/forums/topic/38648-need-audio-cd-ripping-software-recommendations/?do=findComment&comment=825746

I should have said "do you still not realise?"

[diecaster]

40 minutes ago, audiventory said:

 

Fact 1: I (and you) can righ now measure all probabilities for any stand alone ripping system (CD-drive + ripper software).

 

I (and you) can say: I know.

 

Fact 2: I (ans you) can't right now (I'm not ready to say now, how to do it even) measure probabilities ot ripping database, due it is very complex system.

I (and you) can say: I believe.

 

Do you feel difference between "I know" and "I believe"?

 

Just because you keep presenting the same flawed probability argument over and over does not mean it will magically become correct.

 

You have zero credibility now. None.

[mansr]

7 hours ago, tmtomh said:

So my guess is that in CD-ripping mode, your drive's offset is 35 samples, which would equal 70 bytes.

I don't think that's it. Firstly, it's stereo so one sample is 4 bytes. Secondly, an offset should merely move the point for switching files, not make all of them larger. My guess is that the file headers are different.

[tmtomh]

4 hours ago, mansr said:

I don't think that's it. Firstly, it's stereo so one sample is 4 bytes. Secondly, an offset should merely move the point for switching files, not make all of them larger. My guess is that the file headers are different.

Ah, hadn't thought of that. Makes sense!