Special handling of cdrom offsets that are bigger than 588 needed

[GoogleCodeExporter]

I've just started fiddling with secure ripping a few days ago,
so some things might be a bit off.

What steps will reproduce the problem?
1.Set cdrom offset to a positive value
2.Rip a CD to wav files
3.Increase cdrom offset by 588 (value+=588)
4.Rip again to a different folder

What is the expected output? What do you see instead?
If the CD is OK, you'll get identical files for both rips,
but different offsets should produce different wav files.
My drive has an offset of +667, so this is a big problem for me.

Please use labels and text to provide additional information.

This is a cdparanoia feature(bug?)
Since one frame consists of 588 samples, cdparanoia converts
anything bigger than 588 to toc offset and uses the remainder
as sample offset.

Here is the specific code from cdparanoia main.c file
(and it also seems that there might be further trouble for
negative offsets no matter the size):
  if(sample_offset){
    toc_offset+=sample_offset/588;
    sample_offset%=588;
    if(sample_offset<0){
      sample_offset+=588;
      toc_offset--;
    }

Now this works OK in cdparanoia batch mode and when using track numbers,
but rubyripper uses absolute positions, as in
[.startsector] - [.length sectors to rip]
so in effect, only the remainder
of sample offset is used. There was a post about this inconsistency a
while ago on cdparanoia mailing list
(http://permalink.gmane.org/gmane.comp.audio.cd-paranoia.devel/176)
but the patch doesn't seem to have been submitted.

A seemingly trivial solution would be to startsector+=sample_offset/588
(taking care of negative offsets too of course). By doing this I was able to
produce same results as cdparanoia batch mode and also EAC.

Attached the patch, but shouldn't be taken seriously as this is my first ruby 
line in my life and I'm not sure about negative number division remainder 
behavior.

Original issue reported on code.google.com by nanik...@gmail.com on 19 Feb 2011 at 10:09

Attachments:

• big_offsets.patch

[GoogleCodeExporter]

This issue appears to still apply to the latest rubyripper versions as well 
from my initial inspection.  I'll be posting a revised patch in the near future 
to fix this issue against the latest git sources, but we may need to do some 
extra legwork to make it an advanced configuration option (in case patches to 
fix it start showing up in other distros; as far as I can tell, no one has 
picked up the patch for this though...)

Original comment by comradec...@gmail.com on 1 Nov 2011 at 5:09

[GoogleCodeExporter]

Here we go; updated for the latest master git branch.

Original comment by comradec...@gmail.com on 2 Nov 2011 at 2:38

Attachments:

• 0001-Update-big-offset-patch-to-work-on-0.7.0-branch.patch

[GoogleCodeExporter]

Also, it is worth noting that Ruby division of negative integers should behave 
as expected (-1/588 = -1); but this does have the disadvantage of possibly 
causing us to read into the lead-in on the first track, which might break with 
cdparanoia...

Original comment by comradec...@gmail.com on 2 Nov 2011 at 2:40

[GoogleCodeExporter]

The patch is merged with the master branch.

Original comment by boukewou...@gmail.com on 6 Nov 2011 at 3:48

• Changed state: Fixed