search

pccasto / rubyripper

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

Detecting pregaps correctly + configuration options for pregap handling #207

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
According to this:

http://code.google.com/p/rubyripper/issues/detail?id=123#c28

rubyripper now prepends pregaps to tracks.  It's somewhat standard to
append them instead, but I'm not sure I want the pregap added to any track.
Can this be made optional?

Original issue reported on code.google.com by emailgr...@gmail.com on 27 Jun 2008 at 6:59

GoogleCodeExporter commented 8 years ago 
No, I certainly don't think it should duplicate EAC at all.  In fact, while I 
usually
hate Gnome HIG simplicity (because while sometimes you can tweak settings 
through the
program or gconf, it is not always an option) I think sane defaults and minimal
tweaking best for rr.  The goal is duplicate a CD (whether track by track or as 
a
single image) as faithfully as possible.  The way it rips, by default, should 
mean
the tracks can be verified with AccurateRip DB (although the possibility always
exists that EAC / AccurateRip are not 100% faithful with pregaps and hidden 
tracks,
it is still the gold standard).  That's my thinking.

Original comment by mordbr...@gmail.com on 4 Aug 2009 at 8:59

GoogleCodeExporter commented 8 years ago 
@ferfofrog:
I suppose the cuesheet from comment 41 is correct after all then when ripping 
hidden
audio sectors before track 1 is enabled.

When ripping hidden audio sectors is disabled (and the track is not marked as 
hidden
due to it's length) your pregap solution should do the trick.

Can you confirm this logic please?

Original comment by rubyripp...@gmail.com on 8 Aug 2009 at 9:44

GoogleCodeExporter commented 8 years ago 
The cuesheet from comment 40 is correct for hidden tracks. Because the hidden 
track
goes in INDEX 00 of track 1 and then track 1 goes in INDEX 01. I think that if
ripping hidden audio sectors is enabled no matter what the length is; pregap 
should
be ripped and THEN depending on the length it is either prepended to track 1 or 
given
it's own track.

But when ripping hidden audio sectors is disabled then I suppose the person 
doesn't
want a 1:1 rip, so, yes my PREGAP on track 1 is correct (comment 41).

Original comment by fergof...@gmail.com on 8 Aug 2009 at 10:06

GoogleCodeExporter commented 8 years ago 
Please all confirm that you agree on the functionality based on the 
descriptions in
the wiki page [Manual].

Original comment by rubyripp...@gmail.com on 11 Aug 2009 at 8:00

GoogleCodeExporter commented 8 years ago 
I've changed the description in the [Manual] wiki. Can you please re-evaluate 
it?

Original comment by rubyripp...@gmail.com on 13 Aug 2009 at 3:48

GoogleCodeExporter commented 8 years ago 
  "Pre-emphasis is a flag that tells the better cd-player to de-emphasise the audio
to correct the recording..." 

it merely tells that the track has been recorded with pre-emphasis.

De-emphasis is not controlled by the TOC, but by the pre-emphasis bit in the
Q-channel subcode data.

Original comment by jos.van....@gmail.com on 13 Aug 2009 at 6:15

GoogleCodeExporter commented 8 years ago 
Looks good rrdev. Much clearer.

jos.van.dyck both of you are correct, pre-emphasis is a bit in the 'Q-channel 
subcode
data', however when a CD player meets this bit (or flag) it de-emphasises the 
song to
ensure it sounds good and doesn't screech at you.

Original comment by fergof...@gmail.com on 13 Aug 2009 at 9:44

GoogleCodeExporter commented 8 years ago 
The Disc class is updated to reflect all new options. This means cdparanoia 
should be
ripping the right sectors now according to your chosen options. If you check the
debug option, you'll see the start position and length position printed. See 
also
commits:

http://github.com/rubyripperdev/rubyripper/commit/c68761a86d505f9c72551b7ff03a10
c2f4c4853e

http://github.com/rubyripperdev/rubyripper/commit/8bc8927fe340651a8c63ebdf246d2c
8bf14efe62

http://github.com/rubyripperdev/rubyripper/commit/46b60cf49c575ac4aeb93e91945e32
b2694cbd79

Not yet supported is the preEmphasis thing. I am not sure yet if the Disc class 
needs
to do anything with it. I am thinking to move the code needed to the SecureRip 
class
(where the track is corrected etcetera). It should only be a few lines by the 
way,
can't be that hard.

Also the Cuesheet class needs still be updated.

Original comment by rubyripp...@gmail.com on 15 Aug 2009 at 9:43

GoogleCodeExporter commented 8 years ago 
Question: How should Rubyripper create a cuesheet with a data track (either at 
the
start or at the end) ? For now I'm ignoring the data part and just write the 
info for
the audio tracks. But the goal of an exact copy is not realised now. Any ideas?

Original comment by rubyripp...@gmail.com on 15 Aug 2009 at 12:15

GoogleCodeExporter commented 8 years ago 
The appending / prepending / cuesheet part can now be tested in latest git. I 
think I
fixed the obvious mistakes. Please test if it works as expected.

Left to do is the pre-emphasis support.

Original comment by rubyripp...@gmail.com on 15 Aug 2009 at 2:55

GoogleCodeExporter commented 8 years ago 
Example of a sheet with gaps appended:

Original comment by rubyripp...@gmail.com on 15 Aug 2009 at 2:58

Attachments:

GoogleCodeExporter commented 8 years ago 
Example of same sheet with gaps prepended:

Original comment by rubyripp...@gmail.com on 15 Aug 2009 at 3:00

Attachments:

GoogleCodeExporter commented 8 years ago 
This issue is fixed. 

Testing is ofcourse much appreciated! For any bugs regarding the solution, I 
prefer
to have a new issue.

Original comment by rubyripp...@gmail.com on 15 Aug 2009 at 7:44