search

caveman-dick / 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 
I just checked the latest revision, but I'm in doubt if RR actually does proper
pregap detection.
If it doesn't, the audio data will be appended to the previous track by defauly,
because rubyripper doesn't even know they exist.

Rubyripper gets the CD-information by using the -Q switch, which is not enough. 
The
cdrdao-utility does seem to be able to detect the gaps:

PQ sub-channel reading (audio track) is supported, data format is BCD.
Raw P-W sub-channel reading (audio track) is supported.
Cooked R-W sub-channel reading (audio track) is supported.
Analyzing track 01 (AUDIO): start 00:00:00, length 02:07:23...
Found 3 Q sub-channels with CRC errors.
Found ISRC code.
Control nibbles of track match CD-TOC settings.
Analyzing track 02 (AUDIO): start 02:07:23, length 03:01:31...
Found 1 Q sub-channels with CRC errors.
Found ISRC code.
Control nibbles of track match CD-TOC settings.
Analyzing track 03 (AUDIO): start 05:08:54, length 04:11:15...
Found ISRC code.
Control nibbles of track match CD-TOC settings.
Analyzing track 04 (AUDIO): start 09:19:69, length 03:36:62...
Found pre-gap: 00:00:27

I'm suggesting using that third-party utility to do the detection of the 
CD-layout
for us.

Original comment by jwca...@gmail.com on 2 Jul 2008 at 8:46

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
This is interesting.  The 'cdparanoia -Q' information that says "pre no" isn't
reliable?  Maybe it means PRE_EMPHASIS and not pre-gap?

jwcapel, comment #2 has START statements on more tracks than 4 and 14.  Do all 
the
tracks with a START statement have pre-gaps?

I'd really like to know if rubyripper has been appending, prepending, or 
dropping
pre-gaps in the CDs I've ripped so far.  The info in this thread conflicts with 
the
info here:

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

Do you know which it is?

Original comment by emailgr...@gmail.com on 9 Jul 2008 at 2:40

GoogleCodeExporter commented 8 years ago 
I'm fairly certain the pregaps have been appended, since the information from 
issue
#123 is based on the assumption that cdparanoica performs an accurate
pregap-detection. I'm not 100% certain though.
And yes, all those tracks with START statements have pre-gaps. The "cdparanoia 
-Q"
information seems to be coming from the CD TOC, which doesn't contain the 
pre-gap
information, I think (I guess that's why EAC and cdrdao have to analyze the 
tracks?).

Original comment by jwca...@gmail.com on 9 Jul 2008 at 11:39

GoogleCodeExporter commented 8 years ago 
I can do some tests to see what is happening with the pre-gaps as soon as I get
cdrdao to output pre-gap info.  What command do you use?

Is the "pre" info in 'cdparanoia -Q' supposed to be pre-emphasis if it isn't 
pre-gap?

Original comment by emailgr...@gmail.com on 10 Jul 2008 at 2:22

GoogleCodeExporter commented 8 years ago 
I have done some tests with CDs containing pregaps. It seems that the only 
pregap
which is prepended is the one before track 1. This is normally a hidden track 
and it
should be written to an extra file.
All other pregaps are appended to the tracks because "cdparanoia -Q" doesn't do
correct pregap detection.
I think that in its current state the pregap feature isn't very useful. There 
should
be at least an option to disable it so that track 0 and 1 aren't ripped in the 
same file.

Original comment by pizzap...@gmail.com on 26 Jul 2008 at 11:16

GoogleCodeExporter commented 8 years ago 
I've confirmed that 'cdparanoia -Q' outputs PRE_EMPHASIS info and not pre-gaps. 
 Very
misleading.

Original comment by emailgr...@gmail.com on 28 Jul 2008 at 2:18

GoogleCodeExporter commented 8 years ago 
Thanks for all your research. Seems to me there is much work to do then :) This 
one
will get my attention as soon as I've fixed the most important or obvious 
issues.

Current logic is based on what cdparanoia reports. So only PRE_EMPHASIS info is 
being
accounted to. I agree that some configuration on how to handle pregaps will be
welcome.

Original comment by rubyripp...@gmail.com on 4 Aug 2008 at 10:57

GoogleCodeExporter commented 8 years ago 
cdrdao read-toc --device /dev/cdrom output.toc does indeed what we want. 
However, it
is quite slow to detect the real toc. It takes about 10 seconds. So we should 
make
this optional.

Original comment by rubyripp...@gmail.com on 5 Aug 2008 at 9:18

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I'd like to add that the cdrdao command you reference above is dependent on the
capabilities of the CD drive when it comes to pre-gap detection.  My laptop's 
drive
can only detect a pre-gap for track #1, and my desktop drive detects the 
pre-gap on
any track.

Original comment by emailgr...@gmail.com on 7 Aug 2008 at 12:50

GoogleCodeExporter commented 8 years ago 
Couldn't be that easy ofcourse ;)

Well, if you find ripping that important I suppose you're willing to buy a 
decent
cdrom player. Not detecting the pregap will at least not result in a crash or 
even
something like that.

Original comment by rubyripp...@gmail.com on 7 Aug 2008 at 6:43

GoogleCodeExporter commented 8 years ago 
Please contribute to the wiki page created for this and comparable problems:
AnalyzingDisc_Research.

Original comment by rubyripp...@gmail.com on 6 Apr 2009 at 9:22

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I like to build a solution with cdrdao's toc detection. Perhaps we want the toc 
file
to be saved as well in the output dir?

Can all please contribute at the wiki page AnalyzingDisc_Research about the
advantages of different options that are needed? If you need access, just make 
a comment.

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 9:04

GoogleCodeExporter commented 8 years ago 
Issue 230 has been merged into this issue.

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 9:44

GoogleCodeExporter commented 8 years ago 
Issue 287 has been merged into this issue.

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 9:45

GoogleCodeExporter commented 8 years ago 
Issue 141 has been merged into this issue.

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 9:47

GoogleCodeExporter commented 8 years ago 
Please provide the output.toc file of cdrdao (as an attachment) for discs that 
have:

* pregaps
* silence
* pre-emphasis

The command should be:
cdrdao read-toc --device /dev/cdrom output.toc

Also keep those discs apart to test if rubyripper handles them correctly later 
;)

Original comment by rubyripp...@gmail.com on 12 Jul 2009 at 11:54

GoogleCodeExporter commented 8 years ago 
My output.toc from http://code.google.com/p/rubyripper/issues/detail?id=141 
should
also apply to PREGAPS and SILENCE.

Original comment by fergof...@gmail.com on 12 Jul 2009 at 12:01

Attachments:

GoogleCodeExporter commented 8 years ago 
Another interesting TOC, this time with CD-Text. Notice that this is the 
commercial
disc, not burned or anything. It also has some pre-gaps.

Original comment by rubyripp...@gmail.com on 12 Jul 2009 at 12:19

Attachments:

GoogleCodeExporter commented 8 years ago 
It's pretty clear cdrado is the solution, however the time it takes the tool to 
scan
the CD is an issue.

Just FYI Toxicity is by System of a Down.

Original comment by fergof...@gmail.com on 12 Jul 2009 at 12:23

GoogleCodeExporter commented 8 years ago 
Ofcourse it is :D I was just reading a toc of Rammstein. Must have confused 
that one.

Original comment by rubyripp...@gmail.com on 12 Jul 2009 at 12:36

GoogleCodeExporter commented 8 years ago 
See issue 287 for a toc with pre-emphasis.

Original comment by rubyripp...@gmail.com on 12 Jul 2009 at 12:42

GoogleCodeExporter commented 8 years ago 
This is from the cd "Wake Up, O Sleeper" by the band "Cool Hand Luke."  It 
contains
at least a pre-gap.

My biggest concern in all of this, is that the original cd can be properly 
reproduced
on another physical cd, in it's entirety.  Currently, with RubyRipper, that's 
not
possible on a cd like this one.  K3b, on the other hand, has the ability to do 
so,
but obviously is not a secure ripper, not to mention the fact that it is HUGE 
and has
a boat-load of dependencies.  

I would love it if this was fixed!  Thanks for taking a look.

Original comment by wrk...@gmail.com on 12 Jul 2009 at 1:00

Attachments:

GoogleCodeExporter commented 8 years ago 
@wrkerr: Thanks for providing some more input :) Is there a hidden audio track 
at the
start of the disc? Or is it non-audio?

And yes, the goal is to reproduce the original disc in the end.

Original comment by rubyripp...@gmail.com on 12 Jul 2009 at 1:12

GoogleCodeExporter commented 8 years ago 
Yes, it's a hidden audio track.

Original comment by wrk...@gmail.com on 13 Jul 2009 at 1:22

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
In latest git there now is advancedToc analysis with the help of cdrdao. Please 
check
if Rubyripper properly detects all pregaps, silences and pre-emphasis. They 
will be
shown at the main ripping window (or in the console if you use the cli). Note 
that
cdrdao marks a hidden track also as silence.

For your check you should compare the info in the toc file of cdrdao (see the 
temp
ripping dir) with the info that is put into the screen. If you've scanned the 
disc
once than cdrdao gets it from cache next time.

Original comment by rubyripp...@gmail.com on 13 Jul 2009 at 6:35

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I see now, the toc doesn't record anything the cuesheet doesn't.  I must keep 
in mind
what a program outputs to the screen doesn't always end up in the file ;)

Original comment by mordbr...@gmail.com on 13 Jul 2009 at 9:10

GoogleCodeExporter commented 8 years ago 
The TOC-file remains a nice tool to check if rubyripper handles correctly when
testing of course. But once established this is save, I see no reason to keep 
the
logs around anymore.

Anyway, when you abort a rip, the toc can be found in the temporary dir.

Original comment by rubyripp...@gmail.com on 13 Jul 2009 at 10:04

GoogleCodeExporter commented 8 years ago 
For single file rips latest git should build correct cuesheets. Well at least, 
the
pregaps can be found in the cuesheet.

Original comment by rubyripp...@gmail.com on 2 Aug 2009 at 8:59

GoogleCodeExporter commented 8 years ago 
See for an example next attachments:

Can anyone verify the cuefile is build correctly?

Original comment by rubyripp...@gmail.com on 2 Aug 2009 at 9:20

Attachments:

GoogleCodeExporter commented 8 years ago 
The cue is incorrect. The issue is in the first track. Unless there is 330ms of 
audio
(which I doubt) the first track should have PREGAP 00:00:33 then INDEX 01 
00:00:00,
then following on everything should have 330ms subtracted from it. Otherwise 
for a
single file rip it is perfect. (attached is the corrected)

Original comment by fergof...@gmail.com on 3 Aug 2009 at 7:44

Attachments:

GoogleCodeExporter commented 8 years ago 
It is more likely a pregap than a hidden track, I fully agree. The length of it 
is
only 33/75 second (as in 75 sectors / second). You incorrectly stated this as 
330 ms
I guess.

In the wiki page on this I currently have the rule set up that if a hidden 
audio part
for track 1 is less than 2 seconds (150 sectors), it should be handled as a 
pregap
instead of a hidden track. There is no other easy way to determine if the 
hidden part
actually has usefull audio.

The implications of having a pregap have yet to be determined, but if I follow 
you
correctly:
* the pregap sectors of track 1 never have to be ripped
* instead it should be added as PREGAP <length> in the cue file.
* all tracks should then determine their start position as if track 1 started at
00:00:00.

Is this correct?

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

GoogleCodeExporter commented 8 years ago 
My bad. I thought the (XX:YY:MM ) MM part were milliseconds.

Yes, from what I understand the non-audio pregap doesn't have to be ripped, it 
is
PREGAP <length> in the cue and the tracks start from track 1 starting at 
00:00:00.
The only time INDEX 00 is used in the cue sheet is when writing a hidden track 
to the
CD, IE something like:
INDEX 00 00:00:00
INDEX 01 03:21:87

Original comment by fergof...@gmail.com on 3 Aug 2009 at 9:21

GoogleCodeExporter commented 8 years ago 
Hmm I think I've been mislead, and therefore mislead you. From typing out the 
options
for multiple files I feel this reason applies to single files too. I read 
through my
research some arguments against the use of the PREGAP command in Cue sheets, 
and this
argument states that even though it is quite probably silence, these very small
pregaps can occasionally contain small sections of audio, and therefore a 1:1 
copy is
not maintained by using the PREGAP command. It also argued that even though it 
is
silence it is silence created at mastering and not by the cd burning program (I 
don't
know that there would be any difference, but it was another interesting point).

So I don't know, I assume to be able to argue that you are making a 1:1 copy of 
a
disk the pregap of sector 1 should always be ripped and the PREGAP command 
shouldn't
ever be used, therefore making my previous two posts very bad ones, if creating 
a 1:1
copy is the goal.

Original comment by fergof...@gmail.com on 4 Aug 2009 at 7:02

GoogleCodeExporter commented 8 years ago 
CUE sheets display the time in MSF (minutes:seconds:frames), for example 
00:00:33
(one frame is 1/75 second).

http://wiki.hydrogenaudio.org/index.php?title=Cuesheet
http://en.wikipedia.org/wiki/Cue_sheet_%28computing%29
http://users.fulladsl.be/spb2267/gapscue/gapscue.htm

Original comment by jos.van....@gmail.com on 4 Aug 2009 at 7:19

GoogleCodeExporter commented 8 years ago 
We need the following pregap options for track 1:

* mark audio before track 1 as hidden track when equal or bigger than <config>
seconds. 0 means that audio before track 1 is always treated as a hidden track. 
A
hidden track is always ripped as a seperate file. If the audio is less than 
<config>
seconds the audio is treated as a pregap instead. Default value should be 2 
seconds.

choice
1) don't rip pregaps for track 1, but instead mark it as PREGAP in the cuesheet.
(This implies that the audio is lost)
2) do rip pregaps for track 1 and prepend them to the first track

Any opinions please?

Original comment by rubyripp...@gmail.com on 4 Aug 2009 at 4:01

GoogleCodeExporter commented 8 years ago 
Can anyone please give their opinion about current configuration setup of the 
TOC?
See also the screenshot of current gui.

Original comment by rubyripp...@gmail.com on 4 Aug 2009 at 7:10

Attachments:

GoogleCodeExporter commented 8 years ago 
Please ignore me if I'm totally mistaken...

If the eventual goal is compatibility with AccurateRip DB, shouldn't it just 
follow
what EAC and their kind do?

Original comment by mordbr...@gmail.com on 4 Aug 2009 at 7:19

GoogleCodeExporter commented 8 years ago 
Good point. Does anyone have more information of what the AccurateRip DB 
expects when
it comes to handling gaps and hidden audio sectors? If so, please add it to the
wikipage for AccurateRip.

Original comment by rubyripp...@gmail.com on 4 Aug 2009 at 7:26

GoogleCodeExporter commented 8 years ago 
I also like to mention that just duplicating EAC isn't the goal. I found 
configuring
EAC not exactly a pleasant user experience. You need a whole guide to set is
correctly if you're not already an expert user.

Original comment by rubyripp...@gmail.com on 4 Aug 2009 at 8:33