search

caveman-dick / rubyripper

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

Short pregaps should be ignored rather than prepended to track 1 #533

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
I believe that it is better practice to ignore short (non HTOA) pregaps rather 
than prepending to track 1, as this is in line with standard behavior of other 
ripping software (for example EAC).  It's a pretty simple fix (removing the 
last else clause of checkOffsetFirstTrack in scanDiscCdparanoia) but since it's 
a change in functionality, I'm seeking external input before I commit the 
change.

Original issue reported on code.google.com by comradec...@gmail.com on 31 Aug 2012 at 11:51

GoogleCodeExporter commented 8 years ago

Original comment by comradec...@gmail.com on 31 Aug 2012 at 11:55

GoogleCodeExporter commented 8 years ago 
Had to look up on this in order to know the "formal" rules:
http://wiki.hydrogenaudio.org/index.php?title=HTOA

So it seems to be accepted that anything shorter than or equal to 6 seconds 
should be considered a pre-gap. Any longer it should be interpreted as a hidden 
track. This seems to be a reasonable approach to comply with.

However, as far as I can see this only touches on the option "Mark as hidden 
track if longer than <2> seconds." The default should be set to 6 instead. One 
can even argue to remove the option altogether and just use 6 as a fixed length.

Any thoughts on your side?

Original comment by boukewou...@gmail.com on 30 Sep 2012 at 6:20

GoogleCodeExporter commented 8 years ago 
See also commit for the default setting:
http://code.google.com/p/rubyripper/source/detail?r=c8f23f5a58229828198b03926059
4312698aae1e

Original comment by boukewou...@gmail.com on 30 Sep 2012 at 6:21

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I have no problem with a 6 second fix.  I can roll that fix in with the patch 
I'd like to push.  The bigger issue was that these short gaps weren't being 
properly ignored on track-by-track rips (on image rips it is reasonable 
practice to not ignore the pre-gap).

Original comment by comradec...@gmail.com on 7 Oct 2012 at 2:12

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Please refer to the following commit for the "ignore pregap" code.  I am not 
certain it is ideal for longer pregaps.  It may be better to test for the 
"ignore pregap" at that point rather than outright refusing to prepend.  
(Better yet, perhaps non-ignorable pregaps should be placed in their own file?)

http://code.google.com/p/rubyripper/source/detail?r=0d5f683b7bd65164e54b66fa7b84
1fec6bf190fd

Original comment by comradec...@gmail.com on 11 Oct 2012 at 6:30

GoogleCodeExporter commented 8 years ago 
I think the cuesheet spec is in line with your commit:
"When printing the track info for prepend based track ripping, it should use a 
pregap if hidden sectors are >= seconds than preference"

Certainly after I fixed a stupid mistake. I want to finish this spec and then 
make sure the ripping process conforms to it.

Original comment by boukewou...@gmail.com on 11 Oct 2012 at 9:53

GoogleCodeExporter commented 8 years ago

Original comment by boukewou...@gmail.com on 9 Jan 2013 at 10:45