Problem with mixed mode CDs

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Get a mixed-mode CD containing a data track #1 and at least two audio
tracks.
2. Try to rip "track 2" in RubyRipper
3. Get the real track 2, which is the audio track one

What is the expected output? What do you see instead?
Getting track 3 ripped.

What version of rubyripper are you using? On what operating system? Are you
using the gtk2 or the commandline interface?
0.50, Ubuntu 8.04 32-bit, gtk2

Please provide any additional information below.

Original issue reported on code.google.com by steven.k...@gmx.net on 11 Jun 2008 at 8:28

[GoogleCodeExporter]

-.-°
Sorry, I am used to get an error if the summary is not filled in 8[
Should be "Problems with mixed mode CDs".

Original comment by steven.k...@gmx.net on 11 Jun 2008 at 8:29

[GoogleCodeExporter]

This is strange, what does cdparanoia -Q show you (when the disc in inserted)?

Original comment by rubyripp...@gmail.com on 14 Jun 2008 at 4:50

• Changed title: Problem with mixed mode CDs

[GoogleCodeExporter]

track        length               begin        copy pre ch
===========================================================
  2.    31553 [07:00.53]   180329 [40:04.29]    no   no  2
  3.    13500 [03:00.00]   211882 [47:05.07]    no   no  2
TOTAL   45053 [10:00.53]    (audio only)

Original comment by steven.k...@gmx.net on 14 Jun 2008 at 5:42

[GoogleCodeExporter]

That's weird. The data track is apparantly on the start of the disc. I've never 
seen this 
before. But it seems to be valid bug report then.

Original comment by rubyripp...@gmail.com on 14 Jun 2008 at 6:05

• Changed state: Accepted

[GoogleCodeExporter]

It's a CD of a computer game, if that helps ;)
And I find it quite common to have the data track as the first track of a disc 
(for
games, that is).

Thanks for accepting the bug report :)

Original comment by steven.k...@gmx.net on 14 Jun 2008 at 7:14

[GoogleCodeExporter]

There is another detail not yet covered in this report.
It is true, that the first track listed and ripped by rr is not (only) the 
second
track on the disc (the first audio track), but rr rips starting at the second 
track
and ripping until "second-track-beginning + third-track-beginning".
Having an overall track length of:
length(track#1)(data)+length(track#2)(audio)

Example:
Quake - (the computer game, first track is the game, the other ones audio 
tracks)
(quite popular to rip, because Trent Reznor (Nine Inch Nails) wrote the music)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  2.    23145 [05:08.45]    40532 [09:00.32]    no   no  2
  3.    10950 [02:26.00]    63677 [14:09.02]    no   no  2
  4.    37518 [08:20.18]    74627 [16:35.02]    no   no  2
  5.    27403 [06:05.28]   112145 [24:55.20]    no   no  2
  6.    33343 [07:24.43]   139548 [31:00.48]    no   no  2
  7.    38866 [08:38.16]   172891 [38:25.16]    no   no  2
  8.    25193 [05:35.68]   211757 [47:03.32]    no   no  2
  9.    29168 [06:28.68]   236950 [52:39.25]    no   no  2
 10.    15941 [03:32.41]   266118 [59:08.18]    no   no  2
 11.    23504 [05:13.29]   282059 [62:40.59]    no   no  2
TOTAL  265031 [58:53.56]    (audio only)

So when ripping the first track in rr
the CD gets ripped from 9:00.32 (start of track 2) to 23:08.72 (in the middle of
track 4!). So the ripped track has a length of 14:09.02 (start of track 3)

This is of course very bad and far worse than the problem mentioned first. None 
of
the following tracks will correspond to a track on the CD because it starts and 
ends
somewhere in the middle of some track.
Additionally, you won't notice this straight away, because most of these 
data/audio
CDs contain ambient/instrumental music.

A side effect is, that you get an error ripping the last tracks, because you 
try to
access positions not really on the CD.

(I am using 0.5.5)

Original comment by goo...@JonnyJD.net on 24 May 2009 at 4:03

[GoogleCodeExporter]

Can you please test if latest git fixes your problems?

Original comment by rubyripp...@gmail.com on 11 Jul 2009 at 8:39

[GoogleCodeExporter]

Notice by the way that rubyripper always will consider the first audiotrack as 
track
number 1.

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

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

Sorry, this is not completely fixed. There is still some reference to the first 
file.

I am trying the above mentioned disc again (with the git version)
There are 10 tracks listed.

If I try ripping starting at the first audio track (which really is the 2nd 
track)
then I get this:
Ripping progress (0 %)
Ripping track 1
Expected filesize for track 1 is 54437084.
(this is 2352 * 23145 (#sectors first track on disc, see cdparanoia -Q output 
above))

When I start with the second track:
Ripping track 2
Expected filesize for track 2 is 25754444.
(this is 2352 * 10950 (#sectors first track on disc))

So rr probably tries to rip the correct track, but there is still a filesize 
check
using the wrong track for the sector number.

I think this error comes from line 1263 in rr_lib.rb and the problem goes up to 
line
569. It should be $lengthSector[track+1] for mixed mode discs?

Original comment by goo...@JonnyJD.net on 12 Jul 2009 at 1:06

[GoogleCodeExporter]

I meant "reference to the first track" in the first line..

And I forgot: rr exits silently after the output of "Expected filesize".

Maybe line 1263 is not the real problem. I don't understand what exactly happens
afterwards and makes rr exit without further debug output.

Original comment by goo...@JonnyJD.net on 12 Jul 2009 at 1:16

[GoogleCodeExporter]

That indeed is a bug.

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

• Changed state: Accepted

[GoogleCodeExporter]

With the information from issue 334 I changed my settings to maxThreads=0.
Now rr starts ripping.

The expected filesize ist still the same (of course), but this didn't keep rr 
from
ripping 7 tracks.
However, starting to rip track 8 (track 9 on disc) gives:
Ripping track 8
Expected filesize for track 8 is 68603180 bytes.
Free disk space is 32880172 MB
Rippen des Tracks 8 gestartet, Versuch #1
cdparanoia [.236950]-[.29167] -d /dev/cdrom -O 6 "/data/music/in/mp3/Trent
Reznor/temp_sr0/track8_1.wav" 2>&1
Cdparanoia gibt keine wav Dateien aus.
Bitte Einstellungen überprüfen.

(that german stuff is telling, that cdparanoia does not return wav data)

I attach the (debug) log. I was hoping it works now, so I forgot to put 
LC_ALL=C. I
hope you can guess what these german lines in between try to tell. If not: ask 
me.

I also tried to re-check the cdparanoia lines given in the debug output.
The first track is ripped with:
cdparanoia [.40532]-[.23144] -d /dev/cdrom -O 6 "test1.wav"

Doing this manually on the commandline gives:
cdparanoia III release 10.2 (September 11, 2008)
Ripping from sector   81064 (track  4 [1:25.62])
          to sector  104208 (track  4 [6:34.31])

And I really don't understand why cdparanoia does this (maybe only music 
sectors are
counted ?), but this might be the core problem.

I did another test which seems to support my theory of "music only sectors":
$ cdparanoia [.0]-[.23144] -d /dev/cdrom -O 6 "test2.wav"
cdparanoia III release 10.2 (September 11, 2008)
Ripping from sector   40532 (track  2 [0:00.00])
          to sector   63676 (track  2 [5:08.44])

I hope this helps. I can do more testing with this data track cd if you need 
something.

Original comment by goo...@JonnyJD.net on 29 Jul 2009 at 1:29

Attachments:

• debug.log

[GoogleCodeExporter]

Thanks for your research, it really was helpfull. I suppose latest commit fixes 
it:
http://github.com/rubyripperdev/rubyripper/commit/46597f1c6679504c64ca8cd8c0b20c
ae8efe0088

Please report...

Original comment by rubyripp...@gmail.com on 30 Jul 2009 at 6:37

• Changed state: Started

[GoogleCodeExporter]

Works like a charm now. It rips the whole disc and all the tracks are correct 
afterwards.

I was using
http://github.com/rubyripperdev/rubyripper/commit/d1fb43b7fde4546fac5502e30abc5c
a356b7da35

Original comment by goo...@JonnyJD.net on 30 Jul 2009 at 9:52

[GoogleCodeExporter]

Then I suppose this bugreport can be closed :)

Original comment by rubyripp...@gmail.com on 31 Jul 2009 at 6:11

• Changed state: Fixed

[GoogleCodeExporter]

I'm using the latest rubyripper-0.5.7. I have no idea which git version this
corresponds to, but I see the following in the change log implying that this has
already been fixed:

4. CHANGELOG ---------0.5.7 RELEASE------ * a fix for discs that start with a 
data track

The problem I am encountering is that tracks on the disc seem shifted by 
exactly the
length of the data track at the beginning of the disc. Examples:

$ cdcd tracks
(SNIP)
Total tracks:   14      Disc length:    46:07
Track   Length      Title
-------------------------------------------------------------------------------
 1:   > [ 1:43.69]  Data Track (data)
 2:     [ 5:51.42]  Adagio for Strings (by Dei, Angus) 
 3:     [ 3:07.26]  Mission 1 / Kharak System 
 4:     [ 2:40.02]  Mission 2 / Great Wastelands 
(SNIP)

Indeed, exactly between 1:44 and 1:43 of the end of my Track 2 (which rubyripper
numbers track 1), I hear the start of Track 3 (which rubyripper numbers track 
2).

This is true for one other data+music mixed CD as well (Warcraft II).

I am attaching the ripping.log. It doesn't say too much, but you can see it had 
a lot
of trouble with the last track, probably because it was shifted in this way--it 
was
consistently the wrong size.

Original comment by patrick.horn on 13 Jan 2010 at 6:29

Attachments:

• ripping.log

[GoogleCodeExporter]

Please excuse the last post. I just pulled from your git repository and this 
issue is
indeed fixed.

Release 0.5.7 is from June or something so it's way out of date.

Would it be possible to remove that download link from the front of your Google 
Code
page (by making it not "featured")? I would appreciate a notice saying to use 
the git
version instead of the tar.gz.

Original comment by patrick.horn on 13 Jan 2010 at 7:07