Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Playing or Ripping UDF CD's Under jessie
121 views
Skip to first unread message
Martin McCormick
Jan 27, 2018, 10:10:05 AM1/27/18
to
I started to play an audio CD which is part of a book and ran in
to an interesting problem. The CD is recorded using the UDF file
system and it does play perfectly on a DVD player.
When trying to mount the CD with
mount -t udf /dev/sr1 /media/cdrom
I got a spew of errors relating to low-level disk issues such as
sector numbers, etc and it finally gave up and never mounted.
The disks aren't bad and all the tested disks gave the same spew
be for giving up.
The fstab file has lines like:
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
so it should mount either udf or iso9660 and it does mount
iso9660 with no problem.
I am thinking that this might be some sort of copy
protection scheme which dedicated disk players can handle but
computer CDROM drives can't.
Is this the case or am I not mounting it right?
One CDRW drive simply reports no media when you insert
the disk and a Sony drive does try to mount it with the error
spew. Another slightly newer P.C. running jessie also spews and
dies.
Thanks for any ideas.
Martin mcCormick
to an interesting problem. The CD is recorded using the UDF file
system and it does play perfectly on a DVD player.
When trying to mount the CD with
mount -t udf /dev/sr1 /media/cdrom
I got a spew of errors relating to low-level disk issues such as
sector numbers, etc and it finally gave up and never mounted.
The disks aren't bad and all the tested disks gave the same spew
be for giving up.
The fstab file has lines like:
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
so it should mount either udf or iso9660 and it does mount
iso9660 with no problem.
I am thinking that this might be some sort of copy
protection scheme which dedicated disk players can handle but
computer CDROM drives can't.
Is this the case or am I not mounting it right?
One CDRW drive simply reports no media when you insert
the disk and a Sony drive does try to mount it with the error
spew. Another slightly newer P.C. running jessie also spews and
dies.
Thanks for any ideas.
Martin mcCormick
Thomas Schmitt
Jan 27, 2018, 11:00:05 AM1/27/18
to
Hi,
Martin McCormick wrote:
> I started to play an audio CD which is part of a book and ran in
> to an interesting problem. The CD is recorded using the UDF file
> system and it does play perfectly on a DVD player.
First issue will be to clarify the true nature of this CD medium.
Audio CDs (CD-DA) are recorded without any filesystem. There are "tracks"
which usually each contain one piece of music. Tracks may be grouped
by sessions. But that's rare with commercially mastered CDs.
There are hybrid formats somewhere between CD-DA and CD-ROM which usually
has ISO 9660 and/or UDF filesystems. The first track might contain the
filesystem and further tracks contain audio or video streams.
Please run one of
wodim -v dev=/dev/sr0 -toc
cdrskin -v dev=/dev/sr0 -toc
A commercial audio CD-DA will show some tracks like:
first: 1 last 10
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: 0
track: 2 lba: 23260 ( 93040) 05:12:10 adr: 1 control: 0 mode: 0
track: 3 lba: 45067 ( 180268) 10:02:67 adr: 1 control: 0 mode: 0
track: 4 lba: 61932 ( 247728) 13:47:57 adr: 1 control: 0 mode: 0
track: 5 lba: 81697 ( 326788) 18:11:22 adr: 1 control: 0 mode: 0
track: 6 lba: 101667 ( 406668) 22:37:42 adr: 1 control: 0 mode: 0
track: 7 lba: 125462 ( 501848) 27:54:62 adr: 1 control: 0 mode: 0
track: 8 lba: 143957 ( 575828) 32:01:32 adr: 1 control: 0 mode: 0
track: 9 lba: 164232 ( 656928) 36:31:57 adr: 1 control: 0 mode: 0
track: 10 lba: 185992 ( 743968) 41:21:67 adr: 1 control: 0 mode: 0
track:lout lba: 202362 ( 809448) 45:00:12 adr: 1 control: 0 mode: -1
A CD-ROM with several data tracks and sessions:
first: 1 last 4
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1
track: 2 lba: 75614 ( 302456) 16:50:14 adr: 1 control: 4 mode: 1
track: 3 lba: 102249 ( 408996) 22:45:24 adr: 1 control: 4 mode: 1
track:lout lba: 121984 ( 487936) 27:08:34 adr: 1 control: 4 mode: -1
track: 4 lba: 128884 ( 515536) 28:40:34 adr: 1 control: 4 mode: 1
track:lout lba: 132116 ( 528464) 29:23:41 adr: 1 control: 4 mode: -1
Whether a track is in CD-DA or CD-ROM format does not depend on the CD medium
type CD-R, CD-RW, readily pressed CD.
> I got a spew of errors relating to low-level disk issues such as
> sector numbers, etc and it finally gave up and never mounted.
Mind to share a few examples of such messages ?
> One CDRW drive simply reports no media when you insert
> the disk and a Sony drive does try to mount it with the error
> spew. Another slightly newer P.C. running jessie also spews and
> dies.
I hope it's only the mount attempt which dies.
Well, you see the reactions of operating system drivers and other software.
The drives' statements can be watched by the SCSI logging modes of above
burn programs. Those modes are quite verbous. So one would catch their
output in files in the /tmp directory:
wodim -v -V dev=/dev/sr0 -toc 2>&1 | tee -i /tmp/wodim.log
cdrskin -v -V dev=/dev/sr0 -toc 2>&1 | tee -i /tmp/cdrskin.log
This might become interesting if the normal Table-Of-Content runs above
yield surprising results.
But for now, let's just see what the drive tells when properly asked.
Have a nice day :)
Thomas
Martin McCormick wrote:
> I started to play an audio CD which is part of a book and ran in
> to an interesting problem. The CD is recorded using the UDF file
> system and it does play perfectly on a DVD player.
Audio CDs (CD-DA) are recorded without any filesystem. There are "tracks"
which usually each contain one piece of music. Tracks may be grouped
by sessions. But that's rare with commercially mastered CDs.
There are hybrid formats somewhere between CD-DA and CD-ROM which usually
has ISO 9660 and/or UDF filesystems. The first track might contain the
filesystem and further tracks contain audio or video streams.
Please run one of
wodim -v dev=/dev/sr0 -toc
cdrskin -v dev=/dev/sr0 -toc
A commercial audio CD-DA will show some tracks like:
first: 1 last 10
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: 0
track: 2 lba: 23260 ( 93040) 05:12:10 adr: 1 control: 0 mode: 0
track: 3 lba: 45067 ( 180268) 10:02:67 adr: 1 control: 0 mode: 0
track: 4 lba: 61932 ( 247728) 13:47:57 adr: 1 control: 0 mode: 0
track: 5 lba: 81697 ( 326788) 18:11:22 adr: 1 control: 0 mode: 0
track: 6 lba: 101667 ( 406668) 22:37:42 adr: 1 control: 0 mode: 0
track: 7 lba: 125462 ( 501848) 27:54:62 adr: 1 control: 0 mode: 0
track: 8 lba: 143957 ( 575828) 32:01:32 adr: 1 control: 0 mode: 0
track: 9 lba: 164232 ( 656928) 36:31:57 adr: 1 control: 0 mode: 0
track: 10 lba: 185992 ( 743968) 41:21:67 adr: 1 control: 0 mode: 0
track:lout lba: 202362 ( 809448) 45:00:12 adr: 1 control: 0 mode: -1
A CD-ROM with several data tracks and sessions:
first: 1 last 4
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 4 mode: 1
track: 2 lba: 75614 ( 302456) 16:50:14 adr: 1 control: 4 mode: 1
track: 3 lba: 102249 ( 408996) 22:45:24 adr: 1 control: 4 mode: 1
track:lout lba: 121984 ( 487936) 27:08:34 adr: 1 control: 4 mode: -1
track: 4 lba: 128884 ( 515536) 28:40:34 adr: 1 control: 4 mode: 1
track:lout lba: 132116 ( 528464) 29:23:41 adr: 1 control: 4 mode: -1
Whether a track is in CD-DA or CD-ROM format does not depend on the CD medium
type CD-R, CD-RW, readily pressed CD.
> I got a spew of errors relating to low-level disk issues such as
> sector numbers, etc and it finally gave up and never mounted.
> One CDRW drive simply reports no media when you insert
> the disk and a Sony drive does try to mount it with the error
> spew. Another slightly newer P.C. running jessie also spews and
> dies.
Well, you see the reactions of operating system drivers and other software.
The drives' statements can be watched by the SCSI logging modes of above
burn programs. Those modes are quite verbous. So one would catch their
output in files in the /tmp directory:
wodim -v -V dev=/dev/sr0 -toc 2>&1 | tee -i /tmp/wodim.log
cdrskin -v -V dev=/dev/sr0 -toc 2>&1 | tee -i /tmp/cdrskin.log
This might become interesting if the normal Table-Of-Content runs above
yield surprising results.
But for now, let's just see what the drive tells when properly asked.
Have a nice day :)
Thomas
Bernd Gruber
Jan 27, 2018, 12:20:04 PM1/27/18
to
Martin McCormick wrote:
> When trying to mount the CD with
>
> mount -t udf /dev/sr1 /media/cdrom
>
> I got a spew of errors relating to low-level disk issues such as
> sector numbers, etc and it finally gave up and never mounted.
>
I'm not sure, but isn't there a certain package / library that's needed for
> When trying to mount the CD with
>
> mount -t udf /dev/sr1 /media/cdrom
>
> I got a spew of errors relating to low-level disk issues such as
> sector numbers, etc and it finally gave up and never mounted.
>
udf-support?
Bernd
Thomas Schmitt
Jan 27, 2018, 12:50:04 PM1/27/18
to
Hi,
Bernd Gruber wrote:
> I'm not sure, but isn't there a certain package / library that's needed for
> udf-support?
Jessie's kernel 3.16 should have full UDF support by the code in:
https://github.com/torvalds/linux/tree/64aa90f26c06e1cb2aacfb98a7d0eccfbd6c1a91/fs/udf
fs/udf/Kconfig points to Documentation/filesystems/udf.txt which says
"Write support requires a block driver which supports writing. Currently
dvd+rw drives and media support true random sector writes, and so a udf
filesystem on such devices can be directly mounted read/write."
man 8 mount mentions some "Mount options for udf".
A few weeks ago i was able to mount a Nero-made pure UDF image.
Bernd Gruber wrote:
> I'm not sure, but isn't there a certain package / library that's needed for
> udf-support?
https://github.com/torvalds/linux/tree/64aa90f26c06e1cb2aacfb98a7d0eccfbd6c1a91/fs/udf
fs/udf/Kconfig points to Documentation/filesystems/udf.txt which says
"Write support requires a block driver which supports writing. Currently
dvd+rw drives and media support true random sector writes, and so a udf
filesystem on such devices can be directly mounted read/write."
man 8 mount mentions some "Mount options for udf".
A few weeks ago i was able to mount a Nero-made pure UDF image.
Martin McCormick
Jan 27, 2018, 5:00:05 PM1/27/18
to
functioning CD player since 1983 and the mystery format CD . Here is the output from a normal music CD.
scsidev: '/dev/sr1'
devname: '/dev/sr1'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.11
SCSI buffer size: 64512
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
TOC Type: 1 = CD-ROM
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'SONY '
Identification : 'CD-RW CRX140E '
Revision : '1.0n'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-2 SWABAUDIO
Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R
Drive buf size : 4183808 = 4085 KB
Drive DMA Speed: 21942 kB/s 124x CD 15x DVD
Current Secsize: 2048
first: 1 last 17
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: 0
track: 2 lba: 19142 ( 76568) 04:17:17 adr: 1 control: 0 mode: 0
all the way up to
track: 17 lba: 351017 ( 1404068) 78:02:17 adr: 1 control: 4 mode: 1
track:lout lba: 351785 ( 1407140) 78:12:35 adr: 1 control: 4 mode: -1
This is the output on the same drive from the mystery CD.
scsidev: '/dev/sr1'
devname: '/dev/sr1'
scsibus: -2 target: -2 lun: -2
Linux sg driver version: 3.5.27
Wodim version: 1.1.11
SCSI buffer size: 64512
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
TOC Type: 1 = CD-ROM
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'SONY '
Identification : 'CD-RW CRX140E '
Revision : '1.0n'
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-2 SWABAUDIO
Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R
Drive buf size : 4183808 = 4085 KB
Drive DMA Speed: 21504 kB/s 122x CD 15x DVD
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 5
Is not unrestricted
Is not erasable
Disk sub type: Medium Type A, high Beta category (A+) (3)
ATIP start of lead in: -11634 (97:26/66)
ATIP start of lead out: 359846 (79:59/71)
Disk type: Short strategy type (Phthalocyanine or similar)
Manuf. index: 3
Manufacturer: CMC Magnetics Corporation
first: 1 last 20
track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: 0
track: 2 lba: 17271 ( 69084) 03:52:21 adr: 1 control: 0 mode: 0
all the way up to
track: 19 lba: 280452 ( 1121808) 62:21:27 adr: 1 control: 0 mode: 0
track: 20 lba: 293350 ( 1173400) 65:13:25 adr: 1 control: 0 mode: 0
track:lout lba: 306751 ( 1227004) 68:12:01 adr: 1 control: 0 mode: -1
>
> > I got a spew of errors relating to low-level disk issues such as
> > sector numbers, etc and it finally gave up and never mounted.
>
> Mind to share a few examples of such messages ?
Not a bit. Here are 7 lines minus all the uninteresting stuff like pid number, etc:
> > I got a spew of errors relating to low-level disk issues such as
> > sector numbers, etc and it finally gave up and never mounted.
>
> Mind to share a few examples of such messages ?
sr 1:0:1:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sr 1:0:1:0: [sr1] Sense Key : Illegal Request [current]
Info fld=0x506a2
sr 1:0:1:0: [sr1] <<vendor>> ASC=0xc6 ASCQ=0x2ASC=0xc6 ASCQ=0x2
sr 1:0:1:0: [sr1] CDB: Read(10): 28 00 00 05 06 a2 00 00 02 00
end_request: I/O error, dev sr1, sector 1317512
Buffer I/O error on device sr1, logical block 164689
It looks like it probably can read normally if one skips some of the control sectors.
Thanks. This is interesting.
deloptes
Jan 27, 2018, 6:10:05 PM1/27/18
to
Martin McCormick wrote:
> sr 1:0:1:0: [sr1] <<vendor>> ASC=0xc6 ASCQ=0x2ASC=0xc6 ASCQ=0x2
> sr 1:0:1:0: [sr1] CDB: Read(10): 28 00 00 05 06 a2 00 00 02 00
> end_request: I/O error, dev sr1, sector 1317512
> Buffer I/O error on device sr1, logical block 164689
>
> It looks like it probably can read normally if one skips some of the
> control sectors.
>
> Thanks. This is interesting.
IMO read error means CD is bad, dirty scratched whatever
> sr 1:0:1:0: [sr1] <<vendor>> ASC=0xc6 ASCQ=0x2ASC=0xc6 ASCQ=0x2
> sr 1:0:1:0: [sr1] CDB: Read(10): 28 00 00 05 06 a2 00 00 02 00
> end_request: I/O error, dev sr1, sector 1317512
> Buffer I/O error on device sr1, logical block 164689
>
> It looks like it probably can read normally if one skips some of the
> control sectors.
>
> Thanks. This is interesting.
regards
Thomas Schmitt
Jan 27, 2018, 6:30:05 PM1/27/18
to
Hi,
Martin McCormick wrote:
> Here is the output from a normal music CD.
> track: 17 lba: 351017 ( 1404068) 78:02:17 adr: 1 control: 4 mode: 1
> track:lout lba: 351785 ( 1407140) 78:12:35 adr: 1 control: 4 mode: -1
Number 17 is a data track. Not overly normal for music CDs but not uncommon
either.
If it contains an ISO 9660 filesystem it should be mountable by
mount -t iso9660 -o sbsector=351017 /dev/sr1 /your/mount/directory
It is just 1.5 MB large. So there cannot be much file content in it.
> This is the output on the same drive from the mystery CD.
as filesystems.
Google finds me for "Linux play audio CD" this Mplayer page:
https://www.cyberciti.biz/faq/linux-unix-mplayer-playing-audio-dvd-cd-using-bash-shell/
Its advise is to do with not mounted /dev/sr1 :
mplayer -cdrom-device /dev/sr1 cdda:// -cache 5000
> all the way up to
It would be interesting to see whether there are other track types.
I see that wodim does not display session end marks, as cdrskin does.
With cdrskin there is an option with better readable output
cdrskin -v dev=/dev/sr1 -minfo
(Not to be confused with option -msinfo.)
It will display session numbers and track numbers like:
Track Sess Type Start Addr End Addr Size
==============================================
1 1 Audio 0 23259 23260
2 1 Audio 23260 45066 21807
3 1 Audio 45067 61931 16865
4 1 Audio 61932 81696 19765
5 1 Audio 81697 101666 19970
6 1 Audio 101667 125461 23795
7 1 Audio 125462 143956 18495
8 1 Audio 143957 164231 20275
9 1 Audio 164232 185991 21760
10 1 Audio 185992 202361 16370
or
Track Sess Type Start Addr End Addr Size
==============================================
1 1 Data 0 64211 64212
2 2 Data 75614 95346 19733
3 3 Data 102249 121981 19733
4 4 Data 128884 132113 3230
Please post full lists without "all the way up".
> sr 1:0:1:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> sr 1:0:1:0: [sr1] Sense Key : Illegal Request [current] Info fld=0x506a2
> sr 1:0:1:0: [sr1] <<vendor>> ASC=0xc6 ASCQ=0x2ASC=0xc6 ASCQ=0x2
> sr 1:0:1:0: [sr1] CDB: Read(10): 28 00 00 05 06 a2 00 00 02 00 end_request: I/O error, dev sr1, sector 1317512
> Buffer I/O error on device sr1, logical block 164689
The failed SCSI command tried to read two blocks starting at block
0x506a2 = 329378.
The error message formatters multiply this number by 4 to get 1317512,
and divide it by 2 to get 164689. (We laugh, so we don't have to cry.)
The error code indicates that the drive refused to perform this command.
Righteously, because the address 329378 is far behind the last track end
at block 306750.
It is not clear to me which part of Linux or systemd came to the idea
of reading that block. It was futile and not very smart.
Unless there is a data track among the skipped ones in your track list,
none of the blocks of the mystery CD would be readable by SCSI command
READ(10). Only commands READ CD or READ CD MSF will do.
> It looks like it probably can read normally if one skips some of the
> control sectors.
The words "control" and "mode" stem from SCSI specs. They apply to the
whole track. MMC-5, table 17 says:
"CONTROL
The Control Field has 4 bits that define the type of information in
the frame:
00x0b = 2 audio channels without pre-emphasis
00x1b = 2 audio channels with pre-emphasis of 50/15 μs
10x0b = 4 audio channels without pre-emphasis
10x1b = 4 audio channels with pre-emphasis of 50/15 μs
01x0b = Data track, recorded uninterrupted
01x1b = Data track, recorded increment
11xxb = reserved
xx0xb = digital copy prohibited
xx1xb = digital copy permitted
The bits of the control field (except for the copy bit) may change
during a pause (X=00) of at least 2 seconds and during the Lead-in
area only."
You showed tracks with these control values:
0 = 0000b = 2 audio channels without pre-emphasis
and without copy permission (which nobody cares about)
4 = 0100b = Data track, recorded uninterrupted, no copy permission
Martin McCormick wrote:
> Here is the output from a normal music CD.
> track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: 0
> track: 2 lba: 19142 ( 76568) 04:17:17 adr: 1 control: 0 mode: 0
These are audio tracks. No filesystem. Neither ISO 9660 nor UDF.
> track: 2 lba: 19142 ( 76568) 04:17:17 adr: 1 control: 0 mode: 0
> track: 17 lba: 351017 ( 1404068) 78:02:17 adr: 1 control: 4 mode: 1
> track:lout lba: 351785 ( 1407140) 78:12:35 adr: 1 control: 4 mode: -1
either.
If it contains an ISO 9660 filesystem it should be mountable by
mount -t iso9660 -o sbsector=351017 /dev/sr1 /your/mount/directory
It is just 1.5 MB large. So there cannot be much file content in it.
> This is the output on the same drive from the mystery CD.
> first: 1 last 20
> track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: 0
> track: 2 lba: 17271 ( 69084) 03:52:21 adr: 1 control: 0 mode: 0
> all the way up to
> track: 19 lba: 280452 ( 1121808) 62:21:27 adr: 1 control: 0 mode: 0
> track: 20 lba: 293350 ( 1173400) 65:13:25 adr: 1 control: 0 mode: 0
These are all non-data tracks. Probably audio. They are not mountable
> track: 1 lba: 0 ( 0) 00:02:00 adr: 1 control: 0 mode: 0
> track: 2 lba: 17271 ( 69084) 03:52:21 adr: 1 control: 0 mode: 0
> all the way up to
> track: 19 lba: 280452 ( 1121808) 62:21:27 adr: 1 control: 0 mode: 0
> track: 20 lba: 293350 ( 1173400) 65:13:25 adr: 1 control: 0 mode: 0
as filesystems.
Google finds me for "Linux play audio CD" this Mplayer page:
https://www.cyberciti.biz/faq/linux-unix-mplayer-playing-audio-dvd-cd-using-bash-shell/
Its advise is to do with not mounted /dev/sr1 :
mplayer -cdrom-device /dev/sr1 cdda:// -cache 5000
> all the way up to
I see that wodim does not display session end marks, as cdrskin does.
With cdrskin there is an option with better readable output
cdrskin -v dev=/dev/sr1 -minfo
(Not to be confused with option -msinfo.)
It will display session numbers and track numbers like:
Track Sess Type Start Addr End Addr Size
==============================================
1 1 Audio 0 23259 23260
2 1 Audio 23260 45066 21807
3 1 Audio 45067 61931 16865
4 1 Audio 61932 81696 19765
5 1 Audio 81697 101666 19970
6 1 Audio 101667 125461 23795
7 1 Audio 125462 143956 18495
8 1 Audio 143957 164231 20275
9 1 Audio 164232 185991 21760
10 1 Audio 185992 202361 16370
or
Track Sess Type Start Addr End Addr Size
==============================================
1 1 Data 0 64211 64212
2 2 Data 75614 95346 19733
3 3 Data 102249 121981 19733
4 4 Data 128884 132113 3230
Please post full lists without "all the way up".
> sr 1:0:1:0: [sr1] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> sr 1:0:1:0: [sr1] Sense Key : Illegal Request [current] Info fld=0x506a2
> sr 1:0:1:0: [sr1] <<vendor>> ASC=0xc6 ASCQ=0x2ASC=0xc6 ASCQ=0x2
> sr 1:0:1:0: [sr1] CDB: Read(10): 28 00 00 05 06 a2 00 00 02 00 end_request: I/O error, dev sr1, sector 1317512
> Buffer I/O error on device sr1, logical block 164689
0x506a2 = 329378.
The error message formatters multiply this number by 4 to get 1317512,
and divide it by 2 to get 164689. (We laugh, so we don't have to cry.)
The error code indicates that the drive refused to perform this command.
Righteously, because the address 329378 is far behind the last track end
at block 306750.
It is not clear to me which part of Linux or systemd came to the idea
of reading that block. It was futile and not very smart.
Unless there is a data track among the skipped ones in your track list,
none of the blocks of the mystery CD would be readable by SCSI command
READ(10). Only commands READ CD or READ CD MSF will do.
> It looks like it probably can read normally if one skips some of the
> control sectors.
whole track. MMC-5, table 17 says:
"CONTROL
The Control Field has 4 bits that define the type of information in
the frame:
00x0b = 2 audio channels without pre-emphasis
00x1b = 2 audio channels with pre-emphasis of 50/15 μs
10x0b = 4 audio channels without pre-emphasis
10x1b = 4 audio channels with pre-emphasis of 50/15 μs
01x0b = Data track, recorded uninterrupted
01x1b = Data track, recorded increment
11xxb = reserved
xx0xb = digital copy prohibited
xx1xb = digital copy permitted
The bits of the control field (except for the copy bit) may change
during a pause (X=00) of at least 2 seconds and during the Lead-in
area only."
You showed tracks with these control values:
0 = 0000b = 2 audio channels without pre-emphasis
and without copy permission (which nobody cares about)
4 = 0100b = Data track, recorded uninterrupted, no copy permission
Martin McCormick
Jan 27, 2018, 6:30:05 PM1/27/18
to
deloptes <delo...@gmail.com> writes:
> IMO read error means CD is bad, dirty scratched whatever
>
> regards
Thank you but I think it is confused as the disk is brand new,
> IMO read error means CD is bad, dirty scratched whatever
>
> regards
part of a set and all of them spew errors when placed in a drive.
They also play flawlessly in a DVD player which is one of those
multimedia types that will play anything from ISO9660 CD's to
DVD's.
I think there is a deliberate protocol violation in the
control data that is there to discourage copying as there are
just too many brand new disks (6 all together) for them all to be
duds. I do agree that damaged disks do normally throw these
errors but it also looks like one is not supposed to mount them
as file systems. In that way, they are exactly like iso9660
disks.
Martin
deloptes
Jan 27, 2018, 7:30:04 PM1/27/18
to
Martin McCormick wrote:
> I think there is a deliberate protocol violation in the
> control data that is there to discourage copying as there are
> just too many brand new disks (6 all together) for them all to be
> duds. I do agree that damaged disks do normally throw these
> errors but it also looks like one is not supposed to mount them
> as file systems. In that way, they are exactly like iso9660
> disks.
if disks are new and drive is also ok, could be indeed some nasty magic put
> I think there is a deliberate protocol violation in the
> control data that is there to discourage copying as there are
> just too many brand new disks (6 all together) for them all to be
> duds. I do agree that damaged disks do normally throw these
> errors but it also looks like one is not supposed to mount them
> as file systems. In that way, they are exactly like iso9660
> disks.
in place to prevent copying, or something new that is not implemented in
the software you have (on jessie)
in any case no one can take the power of dd away :D
regards
Martin McCormick
Jan 27, 2018, 9:20:05 PM1/27/18
to
something new to report.
I want to be able to play the audio files through mplayer which can allow one to speed up the playback
tempo without changing the pitch of the voice which was why I started this project in the first place.
I looked at a CD containing a file system made with mkisofs which is mountable and it is drastically
different in that there is 1 disk-sized data track and no LBA tracks at all.
being able to play the tracks using time compression.
Martin McCormick
Martin McCormick
Jan 27, 2018, 11:40:04 PM1/27/18
to
"Thomas Schmitt" <scdb...@gmx.net> writes:
> I see that wodim does not display session end marks, as cdrskin does.
cdrskin to the rescue.
> I see that wodim does not display session end marks, as cdrskin does.
> With cdrskin there is an option with better readable output
>
> cdrskin -v dev=/dev/sr1 -minfo
>
> (Not to be confused with option -msinfo.)
> It will display session numbers and track numbers like:
>
> Track Sess Type Start Addr End Addr Size
> ==============================================
> 1 1 Audio 0 23259 23260
> 2 1 Audio 23260 45066 21807
> 3 1 Audio 45067 61931 16865
> 4 1 Audio 61932 81696 19765
> 5 1 Audio 81697 101666 19970
> 6 1 Audio 101667 125461 23795
> 7 1 Audio 125462 143956 18495
> 8 1 Audio 143957 164231 20275
> 9 1 Audio 164232 185991 21760
> 10 1 Audio 185992 202361 16370
>
> or
>
> Track Sess Type Start Addr End Addr Size
> ==============================================
> 1 1 Data 0 64211 64212
> 2 2 Data 75614 95346 19733
> 3 3 Data 102249 121981 19733
> 4 4 Data 128884 132113 3230
>
> Please post full lists without "all the way up".
I ran cdrskin on one of the disks from /dev/sr1
ATIP start of lead in: -11634 (97:26/66)
ATIP start of lead out: 359846 (79:59/71)
Producer: CMC Magnetics Corporation
Manufacturer: CMC Magnetics Corporation
Mounted media class: CD
Mounted media type: CD-ROM
Disk Is not erasable
disk status: complete
session status: complete
first track: 1
number of sessions: 1
first track in last sess: 1
last track in last sess: 20
Disk Is not unrestricted
Disk type: CD-DA or CD-ROM
Track Sess Type Start Addr End Addr Size
==============================================
2 1 Audio 17271 33862 16592
3 1 Audio 33863 49554 15692
4 1 Audio 49555 64594 15040
5 1 Audio 64595 81015 16421
6 1 Audio 81016 94659 13644
7 1 Audio 94660 108516 13857
8 1 Audio 108517 123667 15151
9 1 Audio 123668 136320 12653
10 1 Audio 136321 148048 11728
11 1 Audio 148049 163696 15648
12 1 Audio 163697 182745 19049
13 1 Audio 182746 200379 17634
14 1 Audio 200380 217756 17377
15 1 Audio 217757 234016 16260
16 1 Audio 234017 249782 15766
17 1 Audio 249783 266826 17044
18 1 Audio 266827 280451 13625
19 1 Audio 280452 293349 12898
20 1 Audio 293350 306750 13401
Last session start address: 0
Last session leadout start address: 306751
Read capacity: 306751
The very first track
1 1 Audio 0 17270 17271
is what drives computers mad. It would correspond to
track0.cdda.wav and appears to contain information that looks
like a bad disk or otherwise pours sugar in to the fuel tank of a
normal ripping process.
So, what would happen if I ripped from track 1 instead of 0 using cdparanoia?
#!/bin/sh
drivespec=/dev/cdrom3
cdparanoia -d $drivespec "1-"
-rw-r--r-- 1 martin martin 721478396 Jan 27 21:52 cdda.wav
It plays but you lose the individual track boundaries as
you see in the listing above. I noticed that it occasionally
repeated what amounts to one revolution of the disk so a word or
2 might stutter but after track0, it's red-blooded orange book.
How about that as a meta fore? Or is it the red book for audio CD's?
I thought it was udf because one of the two systems I
tried it on spewed out a reference to udffs in one of the myriad
error messages it flung when I tried to mount it originally.
I might be able to restore the individual tracks by
feeding the output of cdrskin in to a perl program if cdparanoia
can't be persuaded to extract them any other way.
This is fun isn't it?
By the way, mplayer, set to do tempo compression worked
fine speeding up the audio.
Thanks to all who helped.
Martin
Glenn English
Jan 28, 2018, 2:00:05 AM1/28/18
to
May I suggest cdparanoia? I'm calling it with Python, and it's a
lovely piece of software. Makes wavs of everything I've thrown at it,
with good info on the screen and all the tracks are on my HDD, with
no silliness.
--
Glenn English
lovely piece of software. Makes wavs of everything I've thrown at it,
with good info on the screen and all the tracks are on my HDD, with
no silliness.
--
Glenn English
Thomas Schmitt
Jan 28, 2018, 4:10:05 AM1/28/18
to
Hi,
so the problem CD is just a pure audio CD with no filesystem to mount.
Entertainment CD pliayers should have no problem with it. Operating systems
and system demons should be able to recognize its state, and thus avoid
the futile mount attempts.
Martin McCormick wrote:
> cdparanoia [...] plays but you lose the individual track boundaries as
cdparanoia -d $drivespec "1-1" track_1.wav
cdparanoia -d $drivespec "2-2" track_2.wav
and so on up to number 20.
cdrskin has an option "extract_audio_to=" which gets the path of a directory
after the "=". It will copy all tracks as separate files trackNN.wav into
the given directory, which already must exist:
cdrskin -v dev=/dev/sr1 extract_audio_to="$HOME"/my_cd
Maybe entertainment CD players show text on their display.
If so, you can extract this info in human readable form by adding cdrskin
option
cdtext_to_v07t="$HOME"/my_cd/cdtext.v07t
to the extraction run (or run cdrskin separately with that option).
"v07t" refers to "Sony Input Sheet Version 0.7T" which is the format
for submitting CD-TEXT to a CD pressing factory.
> I thought it was udf because one of the two systems I
> tried it on spewed out a reference to udffs
They saw a CD and tried UDF. Cluelessly and in vain.
> This is fun isn't it?
I like ISO 9660 better than CD-DA. But it is always a good feeling when
the riddles get less and the insight grows.
so the problem CD is just a pure audio CD with no filesystem to mount.
Entertainment CD pliayers should have no problem with it. Operating systems
and system demons should be able to recognize its state, and thus avoid
the futile mount attempts.
Martin McCormick wrote:
> cdparanoia [...] plays but you lose the individual track boundaries as
> you see in the listing above.
I guess you'd need to read the tracks one by one, like
cdparanoia -d $drivespec "1-1" track_1.wav
cdparanoia -d $drivespec "2-2" track_2.wav
and so on up to number 20.
cdrskin has an option "extract_audio_to=" which gets the path of a directory
after the "=". It will copy all tracks as separate files trackNN.wav into
the given directory, which already must exist:
cdrskin -v dev=/dev/sr1 extract_audio_to="$HOME"/my_cd
Maybe entertainment CD players show text on their display.
If so, you can extract this info in human readable form by adding cdrskin
option
cdtext_to_v07t="$HOME"/my_cd/cdtext.v07t
to the extraction run (or run cdrskin separately with that option).
"v07t" refers to "Sony Input Sheet Version 0.7T" which is the format
for submitting CD-TEXT to a CD pressing factory.
> I thought it was udf because one of the two systems I
> tried it on spewed out a reference to udffs
> This is fun isn't it?
the riddles get less and the insight grows.
Charlie Gibbs
Jan 28, 2018, 1:00:05 PM1/28/18
to
On 28/01/18 01:04 AM, Thomas Schmitt wrote:
> Martin McCormick wrote:
>
>> cdparanoia [...] plays but you lose the individual track boundaries as
>> you see in the listing above.
>
> I guess you'd need to read the tracks one by one, like
> cdparanoia -d $drivespec "1-1" track_1.wav
> cdparanoia -d $drivespec "2-2" track_2.wav
> and so on up to number 20.
Not at all. The -B (batch) option will automatically generate one file
> Martin McCormick wrote:
>
>> cdparanoia [...] plays but you lose the individual track boundaries as
>> you see in the listing above.
>
> I guess you'd need to read the tracks one by one, like
> cdparanoia -d $drivespec "1-1" track_1.wav
> cdparanoia -d $drivespec "2-2" track_2.wav
> and so on up to number 20.
per track.
Lately I've started using icedax, a spinoff of cdda2wav which has
replaced it in Stretch. To rip an entire disk:
icedax -D /dev/sr0 -x -B -O wav
> I like ISO 9660 better than CD-DA. But it is always a good feeling when
> the riddles get less and the insight grows.
actually. :-)
--
cgi...@surfnaked.ca (Charlie Gibbs)
Thomas Schmitt
Jan 28, 2018, 1:40:05 PM1/28/18
to
Hi,
Charlie Gibbs wrote:
> My CD player, however, likes CD-DA much better. Insists on it, actually.
This illustrates the general decay of moral and good manners.
CD drives should be seen but not heard.
Charlie Gibbs wrote:
> My CD player, however, likes CD-DA much better. Insists on it, actually.
CD drives should be seen but not heard.
Jonathan Dowland
Jan 29, 2018, 5:00:04 AM1/29/18
to
On Sun, Jan 28, 2018 at 10:04:22AM +0100, Thomas Schmitt wrote:
>Martin McCormick wrote:
>Martin McCormick wrote:
>> I thought it was udf because one of the two systems I
>> tried it on spewed out a reference to udffs
>
>They saw a CD and tried UDF. Cluelessly and in vain.
They did that because of the fstab line which specified udf, and the
>> tried it on spewed out a reference to udffs
>
>They saw a CD and tried UDF. Cluelessly and in vain.
presence of a data track on the CD.
I've never seen the use of "iso9660,udf" in that column of fstab before.
(would "auto" do the same thing?) You learn something new every day!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
Jonathan Dowland
Jan 29, 2018, 5:00:04 AM1/29/18
to
On Sun, Jan 28, 2018 at 01:27:08AM +0100, deloptes wrote:
>in any case no one can take the power of dd away :D
Good luck reading audio track data from CD-ROMs with dd. Or subcode
>in any case no one can take the power of dd away :D
information. Tip: you can't.
Thomas Schmitt
Jan 29, 2018, 6:10:05 AM1/29/18
to
Hi,
i wrote:
> > They saw a CD and tried UDF. Cluelessly and in vain.
that there would be sectors readable by READ(10).
Whatever software tries to mount a filesystem there does not take
into account the sector format of the tracks.
> I've never seen the use of "iso9660,udf" in that column of fstab before.
> (would "auto" do the same thing?) You learn something new every day!
My Debian 8 fstab has such entries for sr0 and sr1, none for sr2 to sr4.
Like:
groping a newly inserted medium. Workaround is to wait until all drive
blinking stops before using the medium for mounting or burning.
I tried manual mounting as superuser with a commercial audio CD:
# mount -t udf,iso9660 /dev/sr4 /mnt/iso
mount: /dev/sr4 is write-protected, mounting read-only
mount: /dev/sr4: can't read superblock
dmesg reports afterwards
[X.698578] sr 44:0:0:0: [sr4]
[X.698580] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[X.698581] sr 44:0:0:0: [sr4]
[X.698582] Sense Key : Illegal Request [current]
[X.698584] sr 44:0:0:0: [sr4]
[X.698586] Add. Sense: Illegal mode for this track
[X.698587] sr 44:0:0:0: [sr4] CDB:
[X.698588] Read(10): 28 00 00 00 00 10 00 00 01 00
[X.698591] end_request: I/O error, dev sr4, sector 64
This is a READ(10) attempt, which a system with a clue should not try
on tracks with CONTROL value 0.
I get a more standards compliant Sense Code from my ASUS BW-16D1HT burner
than Martin McCormick got from his SONY CRX140E, which seems to be quite
aged (CD only, IDE, reviews from year 2000, ...).
Linux has clue of CD media by its ioctl() family CDROM_*, but obviously
this does not fully shine through with filesystems, and probably even
less with userland automounters.
The mount attempts are not done with this first failure:
...
[X.703472] UDF-fs: error (device sr4): udf_read_tagged: read failed, block=256, location=256
... many more failed READ(10) and messages about UDF ...
[X.771416] UDF-fs: warning (device sr4): udf_fill_super: No partition found (1)
...
[X.783391] isofs_fill_super: bread failed, dev=sr4, iso_blknum=16, block=16
...
[X.807885] EXT4-fs (sr4): unable to read superblock
... 2 retries on same address ...
[X.853593] FAT-fs (sr4): unable to read boot sector
... repeating the attempts for EXT4-fs and FAT-fs ...
So it does not look like mount would take the -t list as a restriction
for trying other filesystem formats.
deloptes wrote:
> > in any case no one can take the power of dd away :D
commands to the drive. But as said, this generic SCSI read command works
only with pure data storage devices or with data tracks on CD.
DVD and BD offer no non-data tracks. So CD are the only media i know,
which can offer non-data data.
Reading the subchannel info of CDs is normally only of interest for cloning
identical media or for circumventing weird read protection methods.
Their normal job is to tell an audio player roughly the current read
position, the Media Catalog Number, ISRC, CD-TEXT, ... For all drives it
provides the track's CONTROL value, which tells parts of the sector format.
i wrote:
> > They saw a CD and tried UDF. Cluelessly and in vain.
Jonathan Dowland wrote:
> They did that because of the fstab line which specified udf, and the
> presence of a data track on the CD.
The "problem CD" is pure audio. No indication on Table-Of-Content level
> They did that because of the fstab line which specified udf, and the
> presence of a data track on the CD.
that there would be sectors readable by READ(10).
Whatever software tries to mount a filesystem there does not take
into account the sector format of the tracks.
> I've never seen the use of "iso9660,udf" in that column of fstab before.
> (would "auto" do the same thing?) You learn something new every day!
Like:
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
I have disabled automounting on my system. What i cannot stop is udev
groping a newly inserted medium. Workaround is to wait until all drive
blinking stops before using the medium for mounting or burning.
I tried manual mounting as superuser with a commercial audio CD:
# mount -t udf,iso9660 /dev/sr4 /mnt/iso
mount: /dev/sr4 is write-protected, mounting read-only
mount: /dev/sr4: can't read superblock
dmesg reports afterwards
[X.698578] sr 44:0:0:0: [sr4]
[X.698580] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[X.698581] sr 44:0:0:0: [sr4]
[X.698582] Sense Key : Illegal Request [current]
[X.698584] sr 44:0:0:0: [sr4]
[X.698586] Add. Sense: Illegal mode for this track
[X.698587] sr 44:0:0:0: [sr4] CDB:
[X.698588] Read(10): 28 00 00 00 00 10 00 00 01 00
[X.698591] end_request: I/O error, dev sr4, sector 64
This is a READ(10) attempt, which a system with a clue should not try
on tracks with CONTROL value 0.
I get a more standards compliant Sense Code from my ASUS BW-16D1HT burner
than Martin McCormick got from his SONY CRX140E, which seems to be quite
aged (CD only, IDE, reviews from year 2000, ...).
Linux has clue of CD media by its ioctl() family CDROM_*, but obviously
this does not fully shine through with filesystems, and probably even
less with userland automounters.
The mount attempts are not done with this first failure:
...
[X.703472] UDF-fs: error (device sr4): udf_read_tagged: read failed, block=256, location=256
... many more failed READ(10) and messages about UDF ...
[X.771416] UDF-fs: warning (device sr4): udf_fill_super: No partition found (1)
...
[X.783391] isofs_fill_super: bread failed, dev=sr4, iso_blknum=16, block=16
...
[X.807885] EXT4-fs (sr4): unable to read superblock
... 2 retries on same address ...
[X.853593] FAT-fs (sr4): unable to read boot sector
... repeating the attempts for EXT4-fs and FAT-fs ...
So it does not look like mount would take the -t list as a restriction
for trying other filesystem formats.
deloptes wrote:
> > in any case no one can take the power of dd away :D
Jonathan Dowland wrote:
> Good luck reading audio track data from CD-ROMs with dd. Or subcode
> information. Tip: you can't.
Yep. dd uses POSIX functions like read(2), which in the end emit READ(10)
> Good luck reading audio track data from CD-ROMs with dd. Or subcode
> information. Tip: you can't.
commands to the drive. But as said, this generic SCSI read command works
only with pure data storage devices or with data tracks on CD.
DVD and BD offer no non-data tracks. So CD are the only media i know,
which can offer non-data data.
Reading the subchannel info of CDs is normally only of interest for cloning
identical media or for circumventing weird read protection methods.
Their normal job is to tell an audio player roughly the current read
position, the Media Catalog Number, ISRC, CD-TEXT, ... For all drives it
provides the track's CONTROL value, which tells parts of the sector format.
rhkr...@gmail.com
Jan 29, 2018, 8:30:04 AM1/29/18
to
On Monday, January 29, 2018 04:51:33 AM Jonathan Dowland wrote:
> On Sun, Jan 28, 2018 at 01:27:08AM +0100, deloptes wrote:
> >in any case no one can take the power of dd away :D
>
> Good luck reading audio track data from CD-ROMs with dd. Or subcode
> information. Tip: you can't.
I guess I'll add my $0.02, just because this thread is persisting. K3B (from
> On Sun, Jan 28, 2018 at 01:27:08AM +0100, deloptes wrote:
> >in any case no one can take the power of dd away :D
>
> Good luck reading audio track data from CD-ROMs with dd. Or subcode
> information. Tip: you can't.
KDE) (in Wheezy) works fine for me--after learning how to use it, it's worked
for everything I've tried (including music CDs).
deloptes
Jan 29, 2018, 8:40:03 AM1/29/18
to
Jonathan Dowland wrote:
> Good luck reading audio track data from CD-ROMs with dd. Or subcode
> information. Tip: you can't.
:D you are correct - it is really a pity - as those things are just bits
> Good luck reading audio track data from CD-ROMs with dd. Or subcode
> information. Tip: you can't.
Martin McCormick
Jan 29, 2018, 9:10:04 AM1/29/18
to
Charlie Gibbs <cgi...@surfnaked.ca> writes:
> On 28/01/18 01:04 AM, Thomas Schmitt wrote:
>
>
> Martin McCormick wrote:
>
>
> cdparanoia [...] plays but you lose the individual track
> boundaries as
> you see in the listing above.
>
>
> I guess you'd need to read the tracks one by one, like
> cdparanoia -d $drivespec "1-1" track_1.wav
> cdparanoia -d $drivespec "2-2" track_2.wav
> and so on up to number 20.
>
>
>
> Not at all. The -B (batch) option will automatically generate one file per
> track.
I was just in too big of a hurry to try things out and forgot the -B or
> On 28/01/18 01:04 AM, Thomas Schmitt wrote:
>
>
> Martin McCormick wrote:
>
>
> cdparanoia [...] plays but you lose the individual track
> boundaries as
> you see in the listing above.
>
>
> I guess you'd need to read the tracks one by one, like
> cdparanoia -d $drivespec "1-1" track_1.wav
> cdparanoia -d $drivespec "2-2" track_2.wav
> and so on up to number 20.
>
>
>
> Not at all. The -B (batch) option will automatically generate one file per
> track.
--batch flag. When using that flag, one would never know that
anything else needed to be done to rip the disk. It just worked.
cdparanoia -d $drivespec -B "1-"
Martin McCormick
Thomas Schmitt
Jan 29, 2018, 11:10:06 AM1/29/18
to
Hi,
deloptes wrote:
> it is really a pity - as those things are just bits
Actually its pits and lands.
The bits emerge only after detecting pit-land changes, converting 14
nearly-bits to 8 quite-really-bits and then decoding them from Reed-
Solomon representation to even fewer payload bits.
deloptes wrote:
> it is really a pity - as those things are just bits
The bits emerge only after detecting pit-land changes, converting 14
nearly-bits to 8 quite-really-bits and then decoding them from Reed-
Solomon representation to even fewer payload bits.
Martin McCormick
Jan 29, 2018, 10:50:05 PM1/29/18
to
"Thomas Schmitt" <scdb...@gmx.net> writes:
> This is a READ(10) attempt, which a system with a clue should not try
> on tracks with CONTROL value 0.
> I get a more standards compliant Sense Code from my ASUS BW-16D1HT burner
> than Martin McCormick got from his SONY CRX140E, which seems to be quite
> aged (CD only, IDE, reviews from year 2000, ...).
Yup. I am trying to remember if I bought that drive or if it was
> This is a READ(10) attempt, which a system with a clue should not try
> on tracks with CONTROL value 0.
> I get a more standards compliant Sense Code from my ASUS BW-16D1HT burner
> than Martin McCormick got from his SONY CRX140E, which seems to be quite
> aged (CD only, IDE, reviews from year 2000, ...).
part of the Dell Dimension chassis it is still running on. I was
using it because it didn't seem to know enough to get as confused
as the newer drive which is a PLEXTOR CD-R PX-W1210A, a
CDRW-capable device that hasn't caused any trouble yet in it's
rather long life.
I was able to play the entire book, however thanks to
this discussion. There were 6 CD's in the book and the first 4
all had that spoiler file in track 0 and audio files the rest of
the way to LOUT. For some reason, the last two disks had no
tracks labelled Audio and all 15 or 20 tracks were labelled as
"Control."
I started at Track 1, skipping the short Control track
and ripped all the other "Control" tracks which had lengths that
could be audio.
cdparanoia ripped them all as trackxx.wav and they
worked perfectly that way. The track00 short file probably had
data in it to "tell" a player to handle the rest as audio.
I did try wodim and cdrskin to read the toc using the
newer drive and that also worked fine so I think either one would have
worked properly as long as one didn't read track0.
I am not totally sure what the manufacturers hoped to
achieve since it didn't take any real skill to crack once one
knows how.
It was a good book with a free crash course in CD obfuscation.
Thanks for the knowledge assistance.
Martin McCormick
Thomas Schmitt
Jan 30, 2018, 3:30:06 AM1/30/18
to
Hi,
allthough it quite works now, there remain some riddles to me in your report.
Martin McCormick wrote:
> There were 6 CD's in the book and the first 4
> all had that spoiler file in track 0 and audio files the rest of
> the way to LOUT.
Normally track counting begins by 1. Sometimes at a higher number.
Which program reports about track 0 ? What exactly does it report ?
If it's cdparanoia, then track00 is not from an ordinary track
but from a "pre-gap track". The term is new to me. Google brings me to
https://web.archive.org/web/20130529085310/http://blowfish.be/eac/Rip/rip11-hidden.html
(Only good that i'm not into audio ripping.)
> For some reason, the last two disks had no
> tracks labelled Audio and all 15 or 20 tracks were labelled as
> "Control."
Which program reports this and what does it report exactly ?
> The track00 short file probably had
> data in it to "tell" a player to handle the rest as audio.
I would be interested to see the content of such a file.
Could you please send it to me ? (In private if it is larger than a
few single KB. No need to clog the list.)
> I am not totally sure what the manufacturers hoped to
> achieve since it didn't take any real skill to crack once one
> knows how.
The Table-of-Content of the CD you showed looks quite normal.
No hidden intentions to see.
But as we can see from discussions of hardcore audio rippers, the
situation can become quite interesting if the sub-channels of the
CD bear unusual data.
The SCSI specs (MMC-5) say about CD media:
A block (or sector or Big Frame) consists of 98 "Small Frames" which
each carry 24 payload bytes, 8 bytes error correction info, and
1 byte of sub-channel info. The bit number 6 of each sub-channel byte
belongs to the "Q-sub-channel", which encodes track number, sector
layout of the track (Control), and other meta-info.
So mad sub-channel can well cause mad drive behavior.
allthough it quite works now, there remain some riddles to me in your report.
Martin McCormick wrote:
> There were 6 CD's in the book and the first 4
> all had that spoiler file in track 0 and audio files the rest of
> the way to LOUT.
Which program reports about track 0 ? What exactly does it report ?
If it's cdparanoia, then track00 is not from an ordinary track
but from a "pre-gap track". The term is new to me. Google brings me to
https://web.archive.org/web/20130529085310/http://blowfish.be/eac/Rip/rip11-hidden.html
(Only good that i'm not into audio ripping.)
> For some reason, the last two disks had no
> tracks labelled Audio and all 15 or 20 tracks were labelled as
> "Control."
> The track00 short file probably had
> data in it to "tell" a player to handle the rest as audio.
Could you please send it to me ? (In private if it is larger than a
few single KB. No need to clog the list.)
> I am not totally sure what the manufacturers hoped to
> achieve since it didn't take any real skill to crack once one
> knows how.
No hidden intentions to see.
But as we can see from discussions of hardcore audio rippers, the
situation can become quite interesting if the sub-channels of the
CD bear unusual data.
The SCSI specs (MMC-5) say about CD media:
A block (or sector or Big Frame) consists of 98 "Small Frames" which
each carry 24 payload bytes, 8 bytes error correction info, and
1 byte of sub-channel info. The bit number 6 of each sub-channel byte
belongs to the "Q-sub-channel", which encodes track number, sector
layout of the track (Control), and other meta-info.
So mad sub-channel can well cause mad drive behavior.
Jonathan Dowland
Jan 31, 2018, 6:00:05 AM1/31/18
to
On Mon, Jan 29, 2018 at 12:03:27PM +0100, Thomas Schmitt wrote:
>Hi,
>
>i wrote:
>> > They saw a CD and tried UDF. Cluelessly and in vain.
>
>Jonathan Dowland wrote:
>> They did that because of the fstab line which specified udf, and the
>> presence of a data track on the CD.
>
>The "problem CD" is pure audio. No indication on Table-Of-Content level
>that there would be sectors readable by READ(10).
I thought you'd identified that track 17 (at least) was marked as a data
>Hi,
>
>i wrote:
>> > They saw a CD and tried UDF. Cluelessly and in vain.
>
>Jonathan Dowland wrote:
>> They did that because of the fstab line which specified udf, and the
>> presence of a data track on the CD.
>
>The "problem CD" is pure audio. No indication on Table-Of-Content level
>that there would be sectors readable by READ(10).
track, but I might not have been following the discussion closely
enough.
Thomas Schmitt
Jan 31, 2018, 6:50:05 AM1/31/18
to
Hi,
i wrote:
> > The "problem CD" is pure audio.
https://lists.debian.org/debian-user/2018/01/msg01186.html
which depends on readability by generic SCSI data command READ(10).
Actually the problem CD is the more normal audio CD.
It does not mount with any of its tracks, and this is what one has
to expect with a pure audio CD which can be read only by the SCSI
commands READ CD or READ CD MSF.
Still unclear is what cdparanoia extracts as Track 0 from several
of Martin's CDs.
i wrote:
> > The "problem CD" is pure audio.
Jonathan Dowland wrote:
> I thought you'd identified that track 17 (at least) was marked as a data
> track, but I might not have been following the discussion closely
> enough.
To my memory this was shown as example of a "no problem" CD.
> I thought you'd identified that track 17 (at least) was marked as a data
> track, but I might not have been following the discussion closely
> enough.
https://lists.debian.org/debian-user/2018/01/msg01186.html
"Here is the output from a normal music CD."
Martin's assessment of "problem" and "normal" was based on the mountability
which depends on readability by generic SCSI data command READ(10).
Actually the problem CD is the more normal audio CD.
It does not mount with any of its tracks, and this is what one has
to expect with a pure audio CD which can be read only by the SCSI
commands READ CD or READ CD MSF.
Still unclear is what cdparanoia extracts as Track 0 from several
of Martin's CDs.
David Wright
Jan 31, 2018, 4:30:04 PM1/31/18
to
discs with cdparanoia. Not all music CDs have them but plenty do.
cdparanoia says:
--✄--------
Attempting to set cdrom to full speed...
drive returned OK.
Table of contents (audio tracks only):
track length begin copy pre ch
===========================================================
1. 81225 [18:03.00] 33 [00:00.33] no no 2
2. 42450 [09:26.00] 81258 [18:03.33] no no 2
3. 55425 [12:19.00] 123708 [27:29.33] no no 2
4. 42825 [09:31.00] 179133 [39:48.33] no no 2
TOTAL 221925 [49:19.00] (audio only)
Ripping from sector 0 (track 0 [0:00.00])
to sector 221957 (track 4 [9:30.74])
outputting to track00.cdda.wav
(== PROGRESS == [ | 000032 00 ] == :^D * ==)
outputting to track01.cdda.wav
--✄--------
Attempting to mount it says:
--✄--------
kernel: [29384.711581] sr 2:0:0:0: [sr0]
kernel: [29384.711592] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: [29384.711599] sr 2:0:0:0: [sr0]
kernel: [29384.711603] Sense Key : Illegal Request [current]
kernel: [29384.711612] Info fld=0x10, ILI
kernel: [29384.711618] sr 2:0:0:0: [sr0]
kernel: [29384.711637] Add. Sense: Illegal mode for this track
kernel: [29384.711642] sr 2:0:0:0: [sr0] CDB:
kernel: [29384.711644] Read(10): 28 00 00 00 00 10 00 00 01 00
kernel: [29384.711658] end_request: I/O error, dev sr0, sector 64
kernel: [29384.721457] sr 2:0:0:0: [sr0]
kernel: [29384.721467] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: [29384.721474] sr 2:0:0:0: [sr0]
kernel: [29384.721478] Sense Key : Illegal Request [current]
kernel: [29384.721487] Info fld=0x100, ILI
kernel: [29384.721493] sr 2:0:0:0: [sr0]
kernel: [29384.721511] Add. Sense: Illegal mode for this track
kernel: [29384.721516] sr 2:0:0:0: [sr0] CDB:
kernel: [29384.721519] Read(10): 28 00 00 00 01 00 00 00 01 00
kernel: [29384.721532] end_request: I/O error, dev sr0, sector 1024
kernel: [29384.721559] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=256, location=256
kernel: [29384.723571] sr 2:0:0:0: [sr0]
kernel: [29384.723578] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: [29384.723583] sr 2:0:0:0: [sr0]
kernel: [29384.723587] Sense Key : Illegal Request [current]
kernel: [29384.723594] Info fld=0x36305, ILI
kernel: [29384.723599] sr 2:0:0:0: [sr0]
kernel: [29384.723607] Add. Sense: Illegal mode for this track
kernel: [29384.723613] sr 2:0:0:0: [sr0] CDB:
kernel: [29384.723617] Read(10): 28 00 00 03 63 05 00 00 01 00
kernel: [29384.723643] end_request: I/O error, dev sr0, sector 887828
kernel: [29384.723668] UDF-fs: error (device sr0): udf_read_tagged: read failed, block=221957, location=221957
kernel: [29384.729699] sr 2:0:0:0: [sr0]
kernel: [29384.729707] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
--✄--------
repeated many times, then it looks for isofs, then an ext4 superblock,
a FAT superblock and finally a FAT boot sector. fstab just contains
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto
The contents of the file follow. To save you looking up the CD number,
it's Brahms Piano Con 2, Brendel, Abbado, Sept 1991, Philips.
--✄--------
$ od cd-track00-432975-2/track00.cdda.wav > /tmp/od
0000000 044522 043106 027524 000001 040527 042526 066546 020164
0000020 000020 000000 000001 000002 126104 000000 130420 000002
0000040 000004 000020 060544 060564 027460 000001 000000 000000
0000060 000000 000000 000000 000000 000000 000000 000000 000000
*
0210600 000000 000000 000000 000000 000000 000000 000001 000000
0210620 000000 000000 000000 000000 000000 000000 000000 000000
*
0212120 000000 000000 000000 000000 000000 000000 000001 000000
0212140 000000 000000 000000 000000 000000 000000 000000 000000
*
0212420 000000 000000 000000 000000 000000 000000 000001 000000
0212440 000000 000000 000000 000000 000000 000000 000000 000000
*
0213720 000001 000000 000000 000000 000000 000000 000000 000000
0213740 000000 000000 000000 000000 000000 177777 000000 000000
0213760 000000 000000 000000 000000 000000 000000 000000 000000
*
0214300 000000 000000 000001 000000 000000 000000 000001 000000
0214320 000000 000000 000000 000000 000000 000000 000000 000000
*
0214420 000000 000000 000001 000000 000000 000000 000000 000000
0214440 000000 000000 000000 000000 000001 000000 000000 000000
0214460 000000 000000 000000 000000 000000 000000 000000 000000
*
0214640 000000 000000 000000 000000 000001 000000 000001 000000
0214660 000000 000000 000000 000000 000000 000000 000000 000000
*
0215220 000001 000000 000000 000000 000000 000000 000000 000000
0215240 000000 000000 000000 000000 000000 000000 000000 000000
*
0215600 000000 000000 000000 000000 000000 177777 000000 000000
0215620 000000 000000 000000 000000 000000 000000 000000 000000
*
0215720 000000 000000 000001 000000 000000 000000 000000 000000
0215740 000000 000000 000000 000000 000000 000000 000000 000000
*
0216060 000000 177777 000000 000000 000000 000000 000000 000000
0216100 000000 000000 000000 000000 000000 177777 000000 000000
0216120 000000 000000 000000 000000 000000 000000 000000 000000
*
0216160 000000 177777 000000 000000 000000 000000 000000 000000
0216200 000000 000000 000000 000000 000000 000000 000000 000000
*
0216520 000000 000000 000000 000000 000000 000000 000000 177777
0216540 000000 000000 000000 000000 000000 000000 000000 000000
*
0216760 177777 000000 000000 000000 000000 000000 000000 000000
0217000 000000 000000 000000 000000 000000 000000 000000 000000
*
0220400 000000 000000 000000 000000 000000 000000 000000 177777
0220420 000000 000000 000000 000000 000000 000000 000000 000000
0220440 000000 000000 000000 177777 000000 000000 000000 000000
0220460 000000 000000 000000 000000 000000 000000 000000 000000
0220500 000000 000000 000000 000000 000000 000000 000000 177777
0220520 000000 000000 000000 000000 000000 000000 000000 000000
*
0220760 000000 000000 000000 177777 000000 000000 000000 000000
0221000 000000 000000 000000 000000 000000 000000 000000 000000
*
0221160 000000 000000 177777 000000 000000 000000 000000 000000
0221200 000000 000000 000000 000000 000000 177777 000000 000000
0221220 000000 000000 000000 000000 000000 000000 000000 000000
*
0221260 000000 000000 000000 000000 000000 177777 000000 000000
0221300 000000 000000 000000 000000 000000 000000 000000 000000
*
0221760 000000 000000 000000 000000 000000 000000 177777 000000
0222000 000000 000000 000000 000000 000000 000000 000000 000000
*
0222440 000000 000000 000000 000000 000000 000000 000000 177777
0222460 000000 000000 000000 000000 000000 000000 000000 000000
*
0223040 000000 000000 000000 000000 000000 177777 000000 000000
0223060 000000 000000 000000 000000 000000 000000 000000 000000
*
0223120 000000 000000 000000 177777 000000 000000 000000 000000
0223140 000000 000000 000000 000000 000000 000000 000000 000000
*
0224000 000000 000000 000000 177777 000000 000000 000000 000000
0224020 000000 000000 000000 000000 000000 000000 000000 000000
*
0224300 000000 000000 000000 000000 177777 000000 000000 000000
0224320 000000 000000 000000 000000 000000 000000 177777 000000
0224340 000000 000000 000000 000000 000000 000000 000000 000000
*
0224420 000000 000000 000000 177777 000000 000000 000000 000000
0224440 000000 000000 000000 000000 000000 000000 000000 000000
*
0224520 000000 000000 000000 000000 000000 000000 000000 177777
0224540 000000 000000 000000 000000 000000 000000 000000 000000
*
0225360 000000 000000 000000 000000 000000 000000 000000 177777
0225400 000000 000000 000000 000000 000000 000000 000000 000000
*
0225440 000000 000000 177777 000000 000000 000000 000000 000000
0225460 000000 000000 000000 000000 000000 000000 000000 000000
*
0226120 000000 177777 000000 000000 000000 000000 000000 000000
0226140 000000 000000 000000 000000 000000 000000 000000 000000
*
0226400 000000 000000 000000 000000 000000 177777 000000 000000
0226420 000000 000000 000000 000000 000000 000000 000000 177777
0226440 000000 000000 000000 000000 000000 000000 000000 000000
*
0227040 000000 000000 000000 177777 000000 000000 000000 000000
0227060 000000 000000 000000 000000 000000 000000 000000 000000
*
0227200 000000 000000 000000 177777 000000 000000 000000 000000
0227220 000000 000000 000000 000000 000000 000000 000000 000000
*
0227400 000000 000000 000000 000000 177777 000000 000000 000000
0227420 000000 000000 000000 000000 000000 000000 000000 000000
*
0227460 000000 000000 000000 000000 000000 177777 000000 000000
0227500 000000 000000 000000 000000 000000 000000 000000 000000
0227520 000000 000000 000000 000000 000000 000000
0227534
--✄--------
Cheers,
David.
Thomas Schmitt
Jan 31, 2018, 5:20:04 PM1/31/18
to
Hi,
David Wright wrote:
> $ od cd-track00-432975-2/track00.cdda.wav > /tmp/od
> 0000000 044522 043106 027524 000001 040527 042526 066546 020164
Octal. Argh. gdb and man ascii to the rescue.
R I F F T / \001 \000 W A V E f m t <blank>
Looks like a .wav header:
http://soundfile.sapp.org/doc/WaveFormat/
> 0000060 000000 000000 000000 000000 000000 000000 000000 000000
> *
> 0210600 000000 000000 000000 000000 000000 000000 000001 000000
> ...
> 0227534
But the sound payload looks boring.
> track length begin copy pre ch
> ===========================================================
> 1. 81225 [18:03.00] 33 [00:00.33] no no 2
It might be that cdparanoia copies track 0 if the first official track
does not start at block 0. Here it starts a block 33.
33 blocks * 2352 bytes/block + 44 bytes .wav header = 77660 = 0227534 octal
So this theory matches the size of your track 0 file.
David Wright wrote:
> $ od cd-track00-432975-2/track00.cdda.wav > /tmp/od
> 0000000 044522 043106 027524 000001 040527 042526 066546 020164
R I F F T / \001 \000 W A V E f m t <blank>
Looks like a .wav header:
http://soundfile.sapp.org/doc/WaveFormat/
> 0000060 000000 000000 000000 000000 000000 000000 000000 000000
> *
> 0210600 000000 000000 000000 000000 000000 000000 000001 000000
> 0227534
But the sound payload looks boring.
> track length begin copy pre ch
> ===========================================================
> 1. 81225 [18:03.00] 33 [00:00.33] no no 2
does not start at block 0. Here it starts a block 33.
33 blocks * 2352 bytes/block + 44 bytes .wav header = 77660 = 0227534 octal
So this theory matches the size of your track 0 file.
Thomas Amm
Feb 10, 2018, 11:10:04 PM2/10/18
to
deliberately botched track indices, or in case of UDF, directory entries
as some sort of copy protection. Usually these indices,
written additionally to the valid ones are too complex to be
understood by "dumb" standalone-players and therefore ignored by them.
When read by computers, however, they appeared mostly unreadable.
My money's on some willful violation of the UDF standard, maybe
somewhat more sophisticated as the previous scheme.
VLC, btw used to be quite good reading these disks, sometimes also
lsdvd used to provide at least some info about their content.
Cheers,
Tom
--
"I hate these filthy Neutrals, Kif. With enemies you know where they
stand but with Neutrals, who knows? It sickens me."
-- Zapp Brannigan
0 new messages