search

fongecore / rubyripper

Automatically exported from code.google.com/p/rubyripper
0 stars 0 forks source link

Track which reqired >2 passes but completed 'correctly' produces different result with subsequent rips #152

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Ripping this particular CD, or possibly (probably?) another CD which
does not read perfectly
2. Comparing the results to the rip results from EAC or another rip of the
same CD

What is the expected output?
I expected that when I compared the results of any two rips from a single
disc that took less than the full number of reads (i.e. less than the
giving up number) I would have the same audio data.

What do you see instead?
For a track which required four reads, the result varied from another rip
of the same track, and from a rip made by EAC (copy and tested in EAC).

What version of rubyripper are you using? 
SVN as of 18/01/2007

On what operating system?
Ubuntu gutsy

Are you using the gtk2 or the commandline interface?
GTK2

Please provide any additional information below.
I am using different drives for the EAC and rubyripper rips (one runs
windows, the other linux) so the two drives have different offsets. The
offsets have been corrected - tested with a number of tracks which matched
correctly.

Original issue reported on code.google.com by the.red....@gmail.com on 18 Jan 2008 at 1:11

GoogleCodeExporter commented 8 years ago 
My apologies - I missed the obvious 'require n matches', for which 2 is clearly 
not
enough in this situation.

Original comment by the.red....@gmail.com on 18 Jan 2008 at 1:45

GoogleCodeExporter commented 8 years ago 
If you're trying to rip a disc that you know is somehow damaged, require 3 or 
more 
matches may end in better results. 

But even though rubyripper mentions that errors have been corrected, there is 
always a small chance that cdparanoia shows the identical wrong result multiple 
times. Therefore the location of the corrections are shown in the log file. You 
should check them if they sound right.

In the future you perhaps will have some extra guarantee when Accuraterip 
confirms 
your result. See also issue 112.

Original comment by rubyripp...@gmail.com on 19 Jan 2008 at 10:35