AssertionError: full table's id fe12a712 differs from toc id ed114111

[Voidi]

Using whipper with this 8fdb452aa6f3181eca9b575b52ae7f11ebd252e2 commit, on Ubuntu 16.04 i tried to rip a cd from this release https://musicbrainz.org/release/3f39e946-7a14-3f0f-ba5e-8d040ac2772e The only thing i bcame was this error log https://gist.github.com/Voidi/7c72dc9f84943118a331bd76acd0e181

[JoeLametta]

Thanks for the bug report. This one seems to be a bug affecting cdrdao and it isn't new:

• https://github.com/thomasvs/morituri/issues/99
• Trac Ticket #22 (assertion failed after getting CD TOC)

The Trac ticket contains some interesting information.

To better understand what's happening, please run the following commands against the same CD. Then post the content of files cdrdao_*.toc

# Whipper's ReadTOCTask uses --fast-toc
read-toc --fast-toc --device /dev/sr0 cdrdao_fast.toc
# Full report useful to better understand what cdrdao sees
read-toc --device /dev/sr0 cdrdao_slow.toc

[Voidi]

Assuming you mean cdrdao read-toc --fast-toc --device /dev/sr0 cdrdao_fast.toc, this gaves the following output: Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de> ERROR: Unable to open SCSI device /dev/sr0: Device or resource busy. ERROR: Please use option '--device {[proto:]bus,id,lun}|device', e.g. --device 0,6,0, --device ATA:0,0,0 or --device /dev/cdrom ERROR: Cannot setup device /dev/sr0.

[JoeLametta]

@Voidi

Assuming you mean cdrdao read-toc --fast-toc --device /dev/sr0 cdrdao_fast.toc

Yes.

this gaves the following output:

Strange. Was the device in use by other programs while running that command (as cdrdao reports)?

[Voidi]

lsof gave me this: gvfsd-cdd 5282 tobias 8r BLK 11,0 0t0 369 /dev/sr0 gmain 5282 5288 tobias 0r CHR 1,3 0t0 6 /dev/null gmain 5282 5288 tobias 8r BLK 11,0 0t0 369 /dev/sr0 gdbus 5282 5289 tobias 0r CHR 1,3 0t0 6 /dev/null gdbus 5282 5289 tobias 8r BLK 11,0 0t0 369 /dev/sr0

But even after killing nautilus and gvfsd-cdd (which is some virtual filessystem for cds, i think), the result is the same.

[Voidi]

Some more Information: I previously upgraded from the original morituri, which worked fine, after that i tried ripping this CD.

And this CD seems to have some kind of advanced copy protection (have this logo on the backcover https://en.wikipedia.org/wiki/Copy_Control)

To other Albums i ripped after that worked fine.

[JoeLametta]

I previously upgraded from the original morituri, which worked fine, after that i tried ripping this CD.

So, if I get it right, you're saying the migration from morituri to whipper worked fine but you've got issues ripping that CD (in particular). Do you know if morituri managed to rip it without issues?

And this CD seems to have some kind of advanced copy protection (have this logo on the backcover https://en.wikipedia.org/wiki/Copy_Control)

All right, that CD is seemingly not compliant with the Red Book specifications.

even after killing nautilus and gvfsd-cdd (which is some virtual filessystem for cds, i think), the result is the same.

Does cdrdao work if you umount /dev/sr0 first before executing it?

[Voidi]

Do you know if morituri managed to rip it without issues? I don't know. I never ripped this CD before and trying to reinstall morituri fails.

Does cdrdao work if you umount /dev/sr0 first before executing it? Ah this seems to work

cdrdao_fast-toc cdrdao_slow-toc

[JoeLametta]

Can you post the output of cdrdao disk-info --device /dev/sr0? That command should include information about the number of sessions available on the disc (probably 2).

Then you can also run the following commands (and post the content of the generated files):

cdrdao read-toc --session 1 --device /dev/sr0 cdrdao_slow_session1.toc
cdrdao read-toc --session 2 --device /dev/sr0 cdrdao_slow_session2.toc

Thanks

[Voidi]

cdrdao disk-info cdrdao_slow_session1.toc cdrdao_slow_session2-toc

[JoeLametta]

Yeah: 2 sessions and the latest track, no. 18, is a data track...

Could you try ripping that CD again using latest whipper release and posting a debug logfile?

Thanks

[alexminder]

I have same error: Traceback (most recent call last): File "/usr/lib/python-exec/python2.7/whipper", line 9, in load_entry_point('whipper==0.4.2', 'console_scripts', 'whipper')() File "/usr/lib64/python2.7/site-packages/morituri/command/main.py", line 31, in main ret = cmd.do() File "/usr/lib64/python2.7/site-packages/morituri/command/basecommand.py", line 123, in do return self.cmd.do() File "/usr/lib64/python2.7/site-packages/morituri/command/basecommand.py", line 123, in do return self.cmd.do() File "/usr/lib64/python2.7/site-packages/morituri/command/cd.py", line 164, in do self.itable.getCDDBDiscId(), self.ittoc.getCDDBDiscId()) AssertionError: full table's id 8a12730b differs from toc id 8b0a9d0b

whipper v0.4.2

[alexminder]

whipper.log.txt

[Voidi]

Ripped the CD again with fresh cloned &compiled source (commit 4dc7a3c) whipper.log.gz

[rubdos]

I've got the same issue with some disks; if you need more debugging aid, let me know. I'm on the copr repo on Fedora 25, whipper 0.4.2.

[rubdos]

Is it me, or does it just look like we're all on MATSHITA DVD-RAM drives? I'm on a MATSHITA DVD-RAM UJ-852.

[alexminder]

I'm on MATSHITA DVD-RAM UJ-861H. Most of my discs have the issue when I try to rip it.

[alexminder]

MATSHITA DVD-RAM UJ-861H.

It works fine with Windows based cd rippers.

[rubdos]

It works fine with Windows based cd rippers.

Can confirm; most of my discs have the issue too, but not on EAC, even through Wine.

[Voidi]

Any News on this topic?

[JoeLametta]

Any News on this topic?

Unfortunately not: I've been very busy and couldn't work on whipper.

As soon as I have something worth reporting/asking, I'll write it here.

[Freso]

This seems like something important enough to at least be looked into for the 1.0 milestone.

[ghost]

same error here, also on a MATSHITA DVD-R UJ-898

Traceback (most recent call last): File "/usr/bin/whipper", line 11, in <module> load_entry_point('whipper==0.5.1', 'console_scripts', 'whipper')() File "/usr/lib/python2.7/site-packages/morituri/command/main.py", line 31, in main ret = cmd.do() File "/usr/lib/python2.7/site-packages/morituri/command/basecommand.py", line 123, in do return self.cmd.do() File "/usr/lib/python2.7/site-packages/morituri/command/basecommand.py", line 123, in do return self.cmd.do() File "/usr/lib/python2.7/site-packages/morituri/command/cd.py", line 164, in do self.itable.getCDDBDiscId(), self.ittoc.getCDDBDiscId()) AssertionError: full table's id 7b0d4a0a differs from toc id 7b077d0a

is there anything to do to help solving his issue?

[bb010g]

Error on Rick Astley's 50 CD with my LG DVDRAM GU90N on master:

Traceback (most recent call last):
  File "/usr/bin/whipper", line 11, in <module>
    load_entry_point('whipper==0.5.1', 'console_scripts', 'whipper')()
  File "/usr/lib/python2.7/site-packages/whipper/command/main.py", line 32, in main
    ret = cmd.do()
  File "/usr/lib/python2.7/site-packages/whipper/command/basecommand.py", line 124, in do
    return self.cmd.do()
  File "/usr/lib/python2.7/site-packages/whipper/command/basecommand.py", line 124, in do
    return self.cmd.do()
  File "/usr/lib/python2.7/site-packages/whipper/command/cd.py", line 171, in do
    self.itable.getCDDBDiscId(), self.ittoc.getCDDBDiscId())
AssertionError: full table's id 9b11720c differs from toc id 940a740c

disc-info:

Cdrdao version 1.2.3 - (C) Andreas Mueller <andreas@daneb.de>
/dev/sr0: HL-DT-ST DVDRAM GU90N Rev: LC00
Using driver: Generic SCSI-3/MMC - Version 2.0 (options 0x0000)

That data below may not reflect the real status of the inserted medium
if a simulation run was performed before. Reload the medium in this case.

CD-RW                : no
Total Capacity       : n/a
CD-R medium          : n/a
Recording Speed      : n/a
CD-R empty           : no
Toc Type             : CD-DA or CD-ROM
Sessions             : 1
Last Track           : 12
Appendable           : no

dwdiff from a normal cdrdao read-toc to a read-toc --fast-toc:

CD_DA

CATALOG "4050538203813"

// Track 1
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"800000000000"-] {+"DELV41600253"+}
FILE "data.wav" 0 03:58:36

// Track 2
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"000000000000"-] {+"DELV41600242"+}
FILE "data.wav" 03:58:36 03:35:52

// Track 3
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"400000000000"-] {+"DELV41600243"+}
FILE "data.wav" 07:34:13 03:27:16

// Track 4
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"P00000000000"-] {+"DELV41600244"+}
FILE "data.wav" 11:01:29 04:30:60

// Track 5
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"T00000000000"-] {+"DELV41600245"+}
FILE "data.wav" 15:32:14 03:58:23

// Track 6
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"T00000000000"-] {+"DELV41600246"+}
FILE "data.wav" 19:30:37 03:15:10

// Track 7
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"P00000000000"-] {+"DELV41600247"+}
FILE "data.wav" 22:45:47 03:40:74

// Track 8
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"L00000000000"-] {+"DELV41600248"+}
FILE "data.wav" 26:26:46 03:22:00

// Track 9
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"L00000000000"-] {+"DELV41600249"+}
FILE "data.wav" 29:48:46 [-00:00:00-] {+03:52:08+}

// Track 10
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"400000000000"-] {+"DELV41600250"+}
FILE "data.wav" [-0 37:22:00
START 33:42:54-] {+33:40:54 03:39:21+}

// Track 11
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"D00000000000"-] {+"DELV41600251"+}
FILE "data.wav" 37:20:00 03:28:01

// Track 12
TRACK AUDIO
NO COPY
NO PRE_EMPHASIS
TWO_CHANNEL_AUDIO
ISRC [-"L00000000000"-] {+"DELV41600252"+}
FILE "data.wav" 40:48:01 03:48:13

[wilbert-vb]

Same problem on two different DVD drives:

cdrdao_fast-toc cdrdao_slow-toc

[mtdcr]

I applied the patch below to cdrdao in order to avoid this problem with one of my drives.

When I run cdrdao read-toc -v3 toc.txt, the failing drive reports:

Checking for raw P-W sub-channel reading support (audio track)...
Raw P-W sub-channel reading (audio track) is not supported.

My previously working drives all do support raw sub-channel reads.

diff --git a/dao/GenericMMC.cc b/dao/GenericMMC.cc
index bf6a6a9..e4cda65 100644
--- a/dao/GenericMMC.cc
+++ b/dao/GenericMMC.cc
@@ -1697,6 +1697,7 @@ int GenericMMC::analyzeTrack(TrackData::Mode mode, int trackNr, long startLba,
   }

   if (noScan || (options_ & OPT_MMC_READ_ISRC) != 0 ||
+      (readCapabilities_ & CDR_READ_CAP_AUDIO_PW_RAW) == 0 ||
       (readCapabilities_ & CDR_READ_CAP_AUDIO_PQ_HEX) != 0) {
     // The ISRC code is usually not usable if the PQ channel data is
     // converted to hex numbers by the drive. Read them with the

[mtdcr]

The patch above only fixed invalid ISRC values. In the meantime I found another drive with the same problems, and even with ISRC values fixed, cdrdao still produces broken tables like this:

$ diff -u slow-toc fast-toc 
--- slow-toc    2018-04-21 17:16:29.249761767 +0200
+++ fast-toc    2018-04-21 16:58:30.570439833 +0200
@@ -82,7 +82,7 @@
 NO PRE_EMPHASIS
 TWO_CHANNEL_AUDIO
 ISRC "DEF057631202"
-FILE "data.wav" 40:00:00 00:00:00
+FILE "data.wav" 40:00:00 03:29:00

 // Track 10
@@ -91,8 +91,7 @@
 NO PRE_EMPHASIS
 TWO_CHANNEL_AUDIO
 ISRC "DEF057730119"
-FILE "data.wav" 0 48:29:33
-START 43:31:33
+FILE "data.wav" 43:29:00 04:58:00

 // Track 11

I'm therefore going to submit a pull request to remove the useless slow TOC read.