search

brasslock / rubyripper

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

Disc found in MusicBrainz Picard, but not rubyripper #540

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
1) Please describe the steps to reproduce the situation:
a. Enter a new disc not in the MusicBrainz DB using MusicBrainz Picard and the 
MusicBrainz web forms.
b. Wait for the submissions to be approved.
c. Verify MusicBrainz Picard can identify the disc.
d. Wait at least one month(?) for it to be copied to the MusicBrainz FreeDB 
server.
e. Load disc into rubyripper configured with MuiscBrainz as the FreeDB server 
(http://freedb.musicbrainz.org/~cddb/cddb.cgi).

2) What is the expected output? What do you see instead?
Disc data should be populated in rubyripper, but disc is not found.

3) What version of rubyripper are you using? On what operating system? The
gtk2 of commandline interface?
rubyripper 0.6.2 on AMD 64-bit Ubuntu 12.04, gnome-shell 3.4.1-0ubuntu2, and 
ruby 1.8.7 (default in Ubuntu 12.04)

4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.

5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.
cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    15193 [03:22.43]        0 [00:00.00]    no   no  2
  2.    23887 [05:18.37]    15193 [03:22.43]    no   no  2
  3.    15405 [03:25.30]    39080 [08:41.05]    no   no  2
  4.    14224 [03:09.49]    54485 [12:06.35]    no   no  2
  5.    17400 [03:52.00]    68709 [15:16.09]    no   no  2
  6.    16267 [03:36.67]    86109 [19:08.09]    no   no  2
  7.    13650 [03:02.00]   102376 [22:45.01]    no   no  2
  8.    19281 [04:17.06]   116026 [25:47.01]    no   no  2
  9.    20698 [04:35.73]   135307 [30:04.07]    no   no  2
 10.    18694 [04:09.19]   156005 [34:40.05]    no   no  2
 11.    11191 [02:29.16]   174699 [38:49.24]    no   no  2
 12.    20946 [04:39.21]   185890 [41:18.40]    no   no  2
 13.    22917 [05:05.42]   206836 [45:57.61]    no   no  2
 14.    20842 [04:37.67]   229753 [51:03.28]    no   no  2
 15.    21126 [04:41.51]   250595 [55:41.20]    no   no  2
 16.    13188 [02:55.63]   271721 [60:22.71]    no   no  2
 17.    13478 [02:59.53]   284909 [63:18.59]    no   no  2
 18.    15289 [03:23.64]   298387 [66:18.37]    no   no  2
 19.    17539 [03:53.64]   313676 [69:42.26]    no   no  2
TOTAL  331215 [73:36.15]    (audio only)

6) Please explain why this change is important for you. Also, how many
users would benefit from this change?
Better support for users entering new discs not already in the MusicBrainz DB.

Please provide any additional information below. The more usefull
information provided, the sooner the issue will be fixed.
Optional MusicBrainz support was found by the configure script.
Installed to prefix=/usr/local
I am a relatively new user on MusicBrainz, so perhaps I have misunderstood how 
submissions migrate to their FreeDB server, but the fact MusicBrainz Picard can 
load the track data makes me suspect the problem is in rubyripper.

Note that ruby versions older than 1.9 are no longer supported. You are
advised to upgrade instead.

Original issue reported on code.google.com by publicpa...@gmail.com on 14 Oct 2012 at 5:24

GoogleCodeExporter commented 9 years ago 
This is fixed in current git, since Musicbrainz is now supported.

Original comment by boukewou...@gmail.com on 20 Oct 2012 at 5:48

GoogleCodeExporter commented 9 years ago 
OK, I pulled the latest from git, upgraded my ruby installation to v1.9.1, 
changed my metadata provider preference to Musicbrainz, but the first two 
problem discs I've tried didn't pull any track data.  A disc I've previously 
ripped successfully did not pull any track data either.

I also get the following warnings:
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': iconv will be 
deprecated in the future, use String#encode instead.
/usr/lib/ruby/1.9.1/gettext/runtime/locale_path.rb:20: Use RbConfig instead of 
obsolete and deprecated Config.

Please advise,

Curt

Original comment by publicpa...@gmail.com on 20 Oct 2012 at 9:39

GoogleCodeExporter commented 9 years ago 
Maybe Ian (comradecosmobot) has any ideas? You might need a dependency or 
something. Ian has implemented the musicbrainz support in Rubyripper.

The warnings are not the problem I think, they have nothing to do with 
musicbrainz.

Can you mention which disc you have problems with? Does this happen for all 
discs?

Original comment by boukewou...@gmail.com on 21 Oct 2012 at 7:51

GoogleCodeExporter commented 9 years ago 
Curt,

Please apply the following patch to the latest commit on the master branch and 
let me know if it resolves your issue.

Original comment by comradec...@gmail.com on 22 Oct 2012 at 1:07

Attachments:

GoogleCodeExporter commented 9 years ago 
I applied the patch, but it doesn't get things entirely working.  When I tried 
one of my "problem" discs (Heart's Dreamboat Annie, Legendary Albums Live), I 
didn't get a failure message, but it didn't populate the track list either.  
Here is the shell output:
<code>
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': iconv will be 
deprecated in the future, use String#encode instead.
/usr/lib/ruby/1.9.1/gettext/runtime/locale_path.rb:20: Use RbConfig instead of 
obsolete and deprecated Config.
DEBUG: cdparanoia -d /dev/sr0 -vQ
Error: No disc found at trial 1!
DEBUG: cdparanoia -d /dev/sr0 -vQ
DEBUG: cd-discid /dev/sr0
DEBUG: cdrdao read-toc --device /dev/sr0 "/tmp/sr0.toc"
<code/>

Running these commands manually:
<code>
  [curts@Panther2] ~/incoming/rubyripper 
  cdparanoia -d /dev/sr0 -vQ
cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2
Using paranoia library version: 10.2
Checking /dev/sr0 for cdrom...
    Testing /dev/sr0 for SCSI/MMC interface
        SG_IO device: /dev/sr0

CDROM model sensed sensed: LITE-ON DVDRW SHW-160P6S PS08 

Checking for SCSI emulation...
    Drive is ATAPI (using SG_IO host adaptor emulation)

Checking for MMC style command set...
    Drive is MMC style
    DMA scatter/gather table entries: 1
    table entry size: 524288 bytes
    maximum theoretical transfer: 222 sectors
    Setting default read size to 27 sectors (63504 bytes).

Verifying CDDA command set...
    Expected command set reads OK.

Attempting to set cdrom to full speed... 
    drive returned OK.

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  1.    26285 [05:50.35]        0 [00:00.00]    no   no  2
  2.     6250 [01:23.25]    26285 [05:50.35]    no   no  2
  3.    21220 [04:42.70]    32535 [07:13.60]    no   no  2
  4.    29610 [06:34.60]    53755 [11:56.55]    no   no  2
  5.    12615 [02:48.15]    83365 [18:31.40]    no   no  2
  6.    16352 [03:38.02]    95980 [21:19.55]    no   no  2
  7.    16413 [03:38.63]   112332 [24:57.57]    no   no  2
  8.    19190 [04:15.65]   128745 [28:36.45]    no   no  2
  9.    20382 [04:31.57]   147935 [32:52.35]    no   no  2
 10.    19178 [04:15.53]   168317 [37:24.17]    no   no  2
 11.    37862 [08:24.62]   187495 [41:39.70]    no   no  2
 12.    17563 [03:54.13]   225357 [50:04.57]    no   no  2
 13.    21860 [04:51.35]   242920 [53:58.70]    no   no  2
 14.    22612 [05:01.37]   264780 [58:50.30]    no   no  2
 15.    31075 [06:54.25]   287392 [63:51.67]    no   no  2
TOTAL  318467 [70:46.17]    (audio only)

  [curts@Panther2] ~/incoming/rubyripper 
  cd-discid /dev/sr0
bd10960f 15 150 26435 32685 53905 83515 96130 112482 128895 148085 168467 
187645 225507 243070 264930 287542 4248

  [curts@Panther2] ~/incoming/rubyripper 
  cdrdao read-toc --device /dev/sr0 "/tmp/sr0.toc"
Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de>
/dev/sr0: LITE-ON DVDRW SHW-160P6S  Rev: PS08
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)

Reading toc data...

Track   Mode    Flags  Start                Length
------------------------------------------------------------
 1      AUDIO   0      00:00:00(     0)     05:50:35( 26285)
 2      AUDIO   0      05:50:35( 26285)     01:23:25(  6250)
 3      AUDIO   0      07:13:60( 32535)     04:42:70( 21220)
 4      AUDIO   0      11:56:55( 53755)     06:34:60( 29610)
 5      AUDIO   0      18:31:40( 83365)     02:48:15( 12615)
 6      AUDIO   0      21:19:55( 95980)     03:38:02( 16352)
 7      AUDIO   0      24:57:57(112332)     03:38:63( 16413)
 8      AUDIO   0      28:36:45(128745)     04:15:65( 19190)
 9      AUDIO   0      32:52:35(147935)     04:31:57( 20382)
10      AUDIO   0      37:24:17(168317)     04:15:53( 19178)
11      AUDIO   0      41:39:70(187495)     08:24:62( 37862)
12      AUDIO   0      50:04:57(225357)     03:54:13( 17563)
13      AUDIO   0      53:58:70(242920)     04:51:35( 21860)
14      AUDIO   0      58:50:30(264780)     05:01:37( 22612)
15      AUDIO   0      63:51:67(287392)     06:54:25( 31075)
Leadout AUDIO   0      70:46:17(318467)

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 05:50:35...
^C:47:24
<code/>

Note the 'cdrdao' command didn't stop after the TOC and started analyzing the 
first track, so I issued a <Ctrl-C>.

When I put in a more well known CD (Mike Oldfield's Tubular Bells), I was 
prompted to select from three versions, but the track list was not populated 
after selecting one.

So, I guess we are a step closer.

Original comment by publicpa...@gmail.com on 22 Oct 2012 at 9:03

GoogleCodeExporter commented 9 years ago

Original comment by boukewou...@gmail.com on 28 Nov 2012 at 8:42