whipper
whipper copied to clipboard
whipper-team
AssertionError: full table's id fe12a712 differs from toc id ed114111
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
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
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 <[email protected]> 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.
@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)?
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.
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.
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?
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
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
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
I have same error:
Traceback (most recent call last):
File "/usr/lib/python-exec/python2.7/whipper", line 9, in
whipper v0.4.2
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.
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.
I'm on MATSHITA DVD-RAM UJ-861H. Most of my discs have the issue when I try to rip it.
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.
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.
This seems like something important enough to at least be looked into for the 1.0 milestone.
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?
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 <[email protected]>
/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
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
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.