cdgrip fails and generates wrong files

Help
2006-11-18
2013-04-15
  • Flip Bertusjes

    Flip Bertusjes - 2006-11-18

    Hello, I've got this karaoke CD from a friend, from a Hyundai system he
    says, asking me if I could 'see' any of the data on it. He knows I'm
    playing a bit with linux and he says he can't 'see' the songs in windows.
    So I tried this CD in my laptop with Fedora C5 and first did:

    ===================================================
    [root@localhost ~]#
    cdrdao read-cd --device /dev/cdrom --read-subchan rw_raw hycd.toc
    Cdrdao version 1.2.1 - (C) Andreas Mueller <andreas@daneb.de>
      SCSI interface library - (C) Joerg Schilling Paranoia
      DAE library - (C) Monty

    Check http://cdrdao.sourceforge.net/drives.html#dt for current driver
    tables.

    Using libscg version 'schily-0.8'

    /dev/cdrom: TOSHIBA DVD-ROM SD-R2212    Rev: 1713 Using driver: Generic
    SCSI-3/MMC - Version 2.0 (options 0x0000)

    Reading toc and track data...

    Track   Mode    Flags  Start                Length
    ------------------------------------------------------------
    1      DATA    4      00:00:00(     0)     25:44:16(115816)
    2      DATA    4      25:44:16(115816)     35:37:27(160302)
    Leadout DATA    4      61:21:43(276118)

    PQ sub-channel reading (data track) is supported, data format is BCD.
    Raw P-W sub-channel reading (data track) is supported.
    Copying data track 1 (MODE2_FORM_MIX): start 00:00:00, length 25:44:16 to "data.bin"... Copying data track 2 (MODE2_FORM_MIX): start 25:44:16, length 35:37:27 to "data.bin"... Reading of toc and track data finished successfully.
    [root@localhost ~]#
    ===================

    So far so good and I had

    =========================
    [user@localhost ~]$ ls -l
    -rw-r--r-- 1 user user 671518976 Nov 18 01:34 data.bin -rw-r--r-- 1 user
    user       238 Nov 18 01:34 hycd.toc =========================

    and then I did

    ================================
    [user@localhost:~/bin/cdgtools]$ python cdgrip.py -v hycd.toc
    -----------------------------------------------------------
    cdgrip 0.3 / Kelvin Lawson 2005
    ----------------------------------------------------------- -> Binfile:
    data.bin
    ----------------------------------------------------------- -> Starting:
    track01
    -> Track start byte = 0, Track Size = 281664512 -> Ripping audio -> Encoding audio to mp3
    -> Ripping CD+G subchannel data
    -> Deinterleaving raw CD+G data
    -> Finished: track01
    ----------------------------------------------------------- -> Starting:
    track02
    -> Track start byte = 281664512, Track Size = 389854464 -> Ripping audio
    -> Encoding audio to mp3
    -> Ripping CD+G subchannel data
    Killed
    [user@localhost ~]$
    ================================

    And I had

    ===================
    [user@localhost ~]$
    -rw-r--r-- 1 ario ario 671518976 Nov 18 01:34 data.bin
    -rw-r--r-- 1 ario ario       238 Nov 18 01:34 hycd.toc
    -rw-r--r-- 1 ario ario 374566080 Nov 18 02:59 temp.pcm
    -rw-r--r-- 1 ario ario  11045568 Nov 18 02:43 track01.cdg
    -rw-r--r-- 1 ario ario  24547577 Nov 18 02:12 track01.mp3
    [user@localhost ~]$
    ===================

    So although cdgrip said it hat completed the mp3 of track02, it was not
    written to the disk (yet). To check what went wrong I did

    ============================
    $ cat /var/log/messages|less

    Nov 18 04:51:58 localhost kernel: eggcups invoked oom-killer:
    gfp_mask=0x201d2, order=0, oomkilladj=0 Nov 18 04:51:58 localhost kernel:
    [<c0403f10>] dump_trace+0x69/0x1af Nov 18 04:51:58 localhost kernel:
    [<c040406e>] show_trace_log_lvl+0x18/0x2c Nov 18 04:51:58 localhost
    kernel:  [<c04045e9>] show_trace+0xf/0x11 Nov 18 04:51:58 localhost
    kernel:  [<c0404673>] dump_stack+0x15/0x17 Nov 18 04:51:58 localhost
    kernel:  [<c0449337>] out_of_memory+0x49/0x182 Nov 18 04:51:58 localhost
    kernel:  [<c044a70e>] __alloc_pages+0x212/0x29c Nov 18 04:51:58 localhost
    kernel:  [<c044b99e>] __do_page_cache_readahead+0xa7/0x1a9 Nov 18 04:51:59
    localhost kernel:  [<c0448904>] filemap_nopage+0x126/0x2f6 Nov 18 04:51:59
    localhost kernel:  [<c0450dd0>] __handle_mm_fault+0x269/0x85a Nov 18
    04:51:59 localhost kernel:  [<c05fcac5>] do_page_fault+0x213/0x4db Nov 18
    04:51:59 localhost kernel:  [<c04038a1>] error_code+0x39/0x40 Nov 18
    04:51:59 localhost kernel: DWARF2 unwinder stuck at error_code+0x39/0x40
    Nov 18 04:51:59 localhost kernel: Leftover inexact backtrace: Nov 18
    04:51:59 localhost kernel:  ======================= Nov 18 04:51:59
    localhost kernel: Mem-info: Nov 18 04:51:59 localhost kernel: DMA per-cpu:
    Nov 18 04:51:59 localhost kernel: cpu 0 hot: high 0, batch 1 used:0 Nov 18
    04:52:00 localhost kernel: cpu 0 cold: high 0, batch 1 used:0 Nov 18
    04:52:00 localhost kernel: DMA32 per-cpu: empty Nov 18 04:52:00 localhost
    kernel: Normal per-cpu: Nov 18 04:52:00 localhost kernel: cpu 0 hot: high
    90, batch 15 used:44 Nov 18 04:52:00 localhost kernel: cpu 0 cold: high
    30, batch 7 used:1 Nov 18 04:52:00 localhost kernel: HighMem per-cpu:
    empty Nov 18 04:52:00 localhost kernel: Free pages:        2840kB (0kB
    HighMem) Nov 18 04:52:00 localhost kernel: Active:22930 inactive:31619
    dirty:0 writeback:0 unstable:0 free:710 slab:2200 mapped:852
    pagetables:1319 Nov 18 04:52:00 localhost kernel: DMA free:1024kB
    min:132kB low:164kB high:196kB active:5312kB inactive:5372kB
    present:16384kB pages_scanned:16805 all_unreclaimable? yes Nov 18 04:52:01
    localhost kernel: lowmem_reserve[]: 0 0 223 223 Nov 18 04:52:01 localhost
    kernel: DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB
    present:0kB pages_scanned:0 all_unreclaimable? no Nov 18 04:52:01
    localhost kernel: lowmem_reserve[]: 0 0 223 223 Nov 18 04:52:01 localhost
    kernel: Normal free:1816kB min:1844kB low:2304kB high:2764kB
    active:86408kB inactive:121104kB present:229356kB pages_scanned:408568
    all_unreclaimable? yes Nov 18 04:52:01 localhost kernel: lowmem_reserve[]:
    0 0 0 0 Nov 18 04:52:01 localhost kernel: HighMem free:0kB min:128kB
    low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0
    all_unreclaimable? no Nov 18 04:52:01 localhost kernel: lowmem_reserve[]:
    0 0 0 0 Nov 18 04:52:01 localhost kernel: DMA: 0*4kB 2*8kB 1*16kB 1*32kB
    1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1024kB Nov 18
    04:52:01 localhost kernel: DMA32: empty Nov 18 04:52:01 localhost kernel:
    Normal: 0*4kB 5*8kB 1*16kB 5*32kB 1*64kB 0*128kB 2*256kB 0*512kB 1*1024kB
    0*2048kB 0*4096kB = 1816kB Nov 18 04:52:02 localhost kernel: HighMem:
    empty Nov 18 04:52:02 localhost kernel: Swap cache: add 2110092, delete
    2109840, find 428491/637654, race 9+188 Nov 18 04:52:02 localhost kernel:
    Free swap  = 0kB Nov 18 04:52:02 localhost kernel: Total swap = 1076344kB
    Nov 18 04:52:02 localhost kernel: Free swap:            0kB Nov 18
    04:52:02 localhost kernel: 61435 pages of RAM Nov 18 04:52:02 localhost
    kernel: 0 pages of HIGHMEM Nov 18 04:52:02 localhost kernel: 1564 reserved
    pages Nov 18 04:52:02 localhost kernel: 12424 pages shared Nov 18 04:52:02
    localhost kernel: 252 pages swap cached Nov 18 04:52:03 localhost kernel:
    0 pages dirty Nov 18 04:52:03 localhost kernel: 0 pages writeback Nov 18
    04:52:03 localhost kernel: 852 pages mapped Nov 18 04:52:03 localhost
    kernel: 2200 pages slab Nov 18 04:52:03 localhost kernel: 1319 pages
    pagetables Nov 18 04:52:03 localhost kernel: Out of memory: Killed process
    3058 (python). ============================

    and basically it went out of (swap) memory. 1 GB seemed not enough
    although the track02 to operate on is 'only' 389854464 bytes (about 370
    MB) big. If I try to play the one mp3 it created, I only hear some
    noise...

    So, what's wrong here?
    I'd be glad if someone could help me with this one,

    thanks,
    ario_

     
    • Kelvin Lawson

      Kelvin Lawson - 2006-11-23

      Well as you've seen cdgtools keeps an in-memory copy of both the CDG and audio data at the same time, so with very large files like this 35 minute track that could be problematic. I'll bear this in mind for future versions, and only work on fixed size blocks at a time. Meanwhile you might get some mileage out of an alternative ripper written by a regular on the PyKaraoke/cdgtools mailing lists:

      http://dcdgrip.passthejager.org/

      Would be interested to hear how you get on.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks