You can subscribe to this list here.
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(3) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2015 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(23) |
Nov
(5) |
Dec
(6) |
2016 |
Jan
(22) |
Feb
(20) |
Mar
|
Apr
|
May
(4) |
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
2017 |
Jan
|
Feb
|
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2021 |
Jan
(6) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Mark K. <mar...@gm...> - 2017-03-13 18:31:49
|
Hello, I have a number of mp4 files that someone asked me to copy and mail to them. I could just do each file on a separate DVD but if possible I'd like to get them on a single DVD, and if possible, have the disc be playable on a DVD player that supports mp4 playback. I tried the simplistic, intuitive option and just tried to write them using a command like cdrecord file1.mp4 file2.mp4 but that failed with the message cdrecord: Virtual track 1 is not a multiple of secsize. Where do I need to look/read/study about how to do this properly? Thanks in advance, Mark |
From: marcos k. <Mar...@po...> - 2017-03-09 14:50:32
|
Hi to all, I did split the discusion into two threads, as advised by Jörg S. On Wednesday, 8 March 2017 22:21:09 CET marcos k. wrote: > Hallo an die Liste cdrtools-support, > > first I want to thank Jörg Schilling for the CDRTools, that I'm using for so > many years now. > > Trying to copy one of my audio CDs I got into trouble. Writing an audio CD > gives a not correct functioning result (Problem 1). It > is related to the cdrecord version and/or the DVD/CD writer model. > > > Problem 1: > Writing the audio CD of Problem 0 with cdrecord on an Windows 10 computer > gives an not properly working result with cdrecord-3.02a06. It is not > possible to directly select track number 3-n. Selecting track 1 and 2 is > possible. Track 3 has a pregapsize of 0, which is maybe related to the > problem. > > Writing the same image and same cue sheet on the same computer with > cdrecord-2.01.01a61 produces a full functioning audio CD. Writing the same > image and same cue sheet on another Windows 10 computer with another CD > writing device produces a full functioning audio CD too. > > cdrecord VersionS: > Cdrecord-ProDVD-ProBD-Clone 3.02a06 (i686-pc-cygwin) Copyright (C) 1995-2016 > Joerg Schilling > AND > Cdrecord-ProDVD-ProBD-Clone 2.01.01a61 (i686-pc-cygwin) Copyright (C) > 1995-2009 Jörg Schilling > > program start: > cdrecord.exe gracetime=5 dev=0,1,0 driveropts=burnfree -v -pad -text -dao > cuefile=/cygdrive/C/Users/.../foo.cue > > OS: > Windows 10 > > Hardware: > Intel i5 > hp DVDRW DU8A6SH DH61 > I will add some information of my discusion with Oliver Valencia of the 'cdrtfe' program. It seems to be related to cdrecord in combination with some CD writers. Also the cdrtools MinGW port did produce the same problem, it is only possible to select tracks one and two directly, but it is not possible to select the tracks three+n (n=0,last). I found something in the cdrecord output, that might be interesting. cdrtfe cdrecord win10: Sending CUE sheet... SAO startsec: -11745 cdrecord linux x64: Sending CUE sheet... cdrecord: CUE sheet not accepted. Retrying with minimum pregapsize = 1. SAO startsec: -11745 Using the Optiarc BD RW BD-5750H on GNU/Linux, it looks like 'cdrecord' changes the pregapsize. I tested on another "Win10" computer. Cdrtfe 1.5.6.0 with cdrecord 3.02a06 generated a full functioning audio CD on another "Win10" computer with another CD writer. Could it be, that the older cdrecord 2.01.01a61 version always uses a minimum pregapsize, and the newer cdrecord versions try to be correct but some CD writers are not able to handle zero pregapsizes correctly? Grüße, m. k. |
From: Joerg S. <Joe...@fo...> - 2017-03-09 11:24:13
|
marcos k. <Mar...@po...> wrote: > Hallo an die Liste cdrtools-support, > > Trying to copy one of my audio CDs I got into trouble. Writing an audio CD > fails (Problem 0) or gives a not correct functioning result (Problem 1). It is > related to the cdrecord version and/or the DVD/CD writer model. > > Problem 0: > Writing an audio CD with cdrecord gives an error message: > Track 03: 0 of 33 MB written.cdrecord: Input/output error. write_g1: scsi > sendcmd: no error > Track 3 has a pregapsize of 0, which is maybe related to the problem. Please let us discuss this in two different threads as there are two different reasons. Track 03: 0 of 33 MB written.cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 84 FD 00 00 0D 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 00 00 00 00 0E 00 00 00 00 08 01 00 00 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x08 Qual 0x01 (logical unit communication time-out) Fru 0x0 Sense flags: Blk 0 (not valid) The problem here is that you are on Linux and that Linux still has problems in it's SCSI implementation - the error message may not be correct. Given that there is: status: 0x2 (CHECK CONDITION) there is a useful probability that the error message in general is correct. If we assume a correct error message, this refers to an internal problem in the drive. INFODISC is a low quality CD manufacturer. Your problem could be a result of that fact. In such cases, I recommend to use Verbatim media. Note that cheaper (larger quantities) of media with Verbatim logo may refer to "higher quality" from cheap manufacturers like "Moser Baer India Limited". If you buy smaller quantities from Verbatim, you usually get original Verbatim media that is known to be of high quality. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/' |
From: Michelle K. <lin...@gm...> - 2017-03-09 08:53:21
|
Hello Marcos, you should upload your GPG Key to a public server because currently your key can not verified. On 2017-03-08 22:21:09 marcos k. hacked into the keyboard: > Hallo an die Liste cdrtools-support, > > first I want to thank Jörg Schilling for the CDRTools, that I'm using for so > many years now. However, I agree with you. -- Thanks to Jörg Schilling and anyone who helped hil to get/keep this tool running Currently I have problems compiling it under Debian Wheeze because there is something missing. Have a nice day -- Michelle Konzack Miila ITSystems @ TDnet GNU/Linux Developer 00372-54541400 |
From: marcos k. <Mar...@po...> - 2017-03-08 21:21:36
|
Hallo an die Liste cdrtools-support, first I want to thank Jörg Schilling for the CDRTools, that I'm using for so many years now. Trying to copy one of my audio CDs I got into trouble. Writing an audio CD fails (Problem 0) or gives a not correct functioning result (Problem 1). It is related to the cdrecord version and/or the DVD/CD writer model. Problem 0: Writing an audio CD with cdrecord gives an error message: Track 03: 0 of 33 MB written.cdrecord: Input/output error. write_g1: scsi sendcmd: no error Track 3 has a pregapsize of 0, which is maybe related to the problem. cdrecord VersionS: Cdrecord-ProDVD-ProBD-Clone 3.01 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2015 Joerg Schilling AND Cdrecord-ProDVD-ProBD-Clone 3.02a07 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2016 Joerg Schilling (installed suid root) program start: ( cdda2wav -v all --cddb=0 --speed=4 --paranoia --paraopts=proof -B ) cdrecord -v --dev=4,0,0 --driveropts=burnfree --dao --useinfo --text --audio *.wav AND ( Exact Audio Copy, create immage and cue sheet) cdrecord -v --driveropts=burnfree --dao --audio --pad --cuefile=foo.cue OS: GNU/Linux fooserver 4.4.49-16-default #1 SMP x86_64 glibc 2.24-2.3 Hardware: Model name Intel(R) Core(TM) i5-4670 CPU @ 3.40GHz PIONEER BD-RW BDR-209D 1.34 CD: Differnent CD-Rs and CD-RWs show the same behaviour! E.g. Mounted media type: CD-RW Disk id: 0x384818 Outputs: Cdrecord output and cue sheet as attachment. Comment: Writing the same audio data (identical data and cue sheet) to the identical CD-RW works without a problem on another computer with another DVD writer (Optiarc BD RW BD-5750H 1.00). Same OS and cdrecord on both computers. Problem 1: Writing the audio CD of Problem 0 with cdrecord on an Windows 10 computer gives an not properly working result with cdrecord-3.02a06. It is not possible to directly select track number 3-n. Selecting track 1 and 2 is possible. Track 3 has a pregapsize of 0, which is maybe related to the problem. Writing the same image and same cue sheet on the same computer with cdrecord-2.01.01a61 produces a full functioning audio CD. Writing the same image and same cue sheet on another Windows 10 computer with another CD writing device produces a full functioning audio CD. cdrecord VersionS: Cdrecord-ProDVD-ProBD-Clone 3.02a06 (i686-pc-cygwin) Copyright (C) 1995-2016 Joerg Schilling AND Cdrecord-ProDVD-ProBD-Clone 2.01.01a61 (i686-pc-cygwin) Copyright (C) 1995-2009 Jörg Schilling program start: cdrecord.exe gracetime=5 dev=0,1,0 driveropts=burnfree -v -pad -text -dao cuefile=/cygdrive/C/Users/.../foo.cue OS: Windows 10 Hardware: Intel i5 hp DVDRW DU8A6SH DH61 CD: As in Problem 0. I tried to give so much information as needed, but I am willing to provide any output and information that will be asked for. Viele Grüße, m. k. |
From: David L. <mai...@gm...> - 2016-12-16 02:51:29
|
Hello, I tried some unofficial 64-bit cdrecord binaries but they didn't work. FYI here are the links: (cygwin) http://www.paehl.com/open_source/?CDRTOOLS_with_DVD_Support (mingw) http://opensourcepack.blogspot.hk/p/cdrtools.html Seeing they are unofficial, I tried to 'DIY' by downloading the source (3.01) and compiling myself. The resulting binaries didn't work either. What didn't work: the 64-bit cdrecord couldn't detect my DVD recorder as a recorder, it said my CDROM was a generic CDROM device and wasn't supported. 32-bit cdrecord worked fine. I don' want to trouble you with the details of how I built the 64-bit binaries (yet). Here is my first question: Is 64-bit compilation of cdrtools on Windows (cygwin or mingw) tested and supported? It might be issue of my computer. However, seeing the unoffcial binaries didn't work, DIY build didn't work but 32-bit cdrecord *did* work, I think this is the right question to ask first. Thanks. David Lee. |
From: Joerg S. <Joe...@fo...> - 2016-11-14 10:57:14
|
Andrea Petrucci <pet...@vi...> wrote: > Hello, thanks for the program cdda2wav. > This is the version I am using: cdda2wav 3.02a06 (i386-pc-solaris2.11). > This is the OS: SunOS openindiana 5.11 illumos-0cfd5ff i86pc i386 i86pc. > Cdda2wav works fine (checked with windows program cuetools) except for the option c2check. When c2check is activated cdda2wav reports bad rips (skips) as if the drive cannot read the disc properly (also the duration of job is anomal, as if the program keeps on retrying until it gives up). > Deactivating c2check makes cdda2wav work again. > My drive is: TSSTcorp' 'CDDVDW SE-208GB ' 'TS00' Removable CD-ROM (usb 2.0 external drive). > Not reletad to this small issue but is it possible to integrate cuetools-database-check (http://cue.tools/wiki/CTDB) functionality? Also the -eject option of cdrecord would be useful. If you like to use this option, I recommend you to get a drive that supports this feature. In the default case, with paraopts=proof, it should first check whether the option is supported by the drive and only use it in that case. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Andrea P. <pet...@vi...> - 2016-11-12 10:05:37
|
Hello, thanks for the program cdda2wav. This is the version I am using: cdda2wav 3.02a06 (i386-pc-solaris2.11). This is the OS: SunOS openindiana 5.11 illumos-0cfd5ff i86pc i386 i86pc. Cdda2wav works fine (checked with windows program cuetools) except for the option c2check. When c2check is activated cdda2wav reports bad rips (skips) as if the drive cannot read the disc properly (also the duration of job is anomal, as if the program keeps on retrying until it gives up). Deactivating c2check makes cdda2wav work again. My drive is: TSSTcorp' 'CDDVDW SE-208GB ' 'TS00' Removable CD-ROM (usb 2.0 external drive). Not reletad to this small issue but is it possible to integrate cuetools-database-check (http://cue.tools/wiki/CTDB) functionality? Also the -eject option of cdrecord would be useful. |
From: Joerg S. <Joe...@fo...> - 2016-09-01 09:20:17
|
Steve Newcomb <sr...@co...> wrote: > Aha! This worked, and the resulting disk verified OK. Thank you! > > FYI, here's the uname -a: > > Linux basil 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 > x86_64 x86_64 x86_64 GNU/Linux Thank you for your feedback While trying to accept your non-member mail for the mailing list, I received a message to remove my mail address from the list instead of the forward. It seems that that the mailing list admin software is broken. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Steve N. <sr...@co...> - 2016-08-31 18:18:38
|
Aha! This worked, and the resulting disk verified OK. Thank you! FYI, here's the uname -a: Linux basil 4.4.0-34-generic #53-Ubuntu SMP Wed Jul 27 16:06:39 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux On 08/31/2016 11:38 AM, Joerg Schilling wrote: > Sorry for the last misformatted mail, here is the same in readable: > > Joerg Schilling <Joe...@fo...> wrote: > >> Your problem is not a problem with cderecord but either caused by your usage or >> caused by another (hostile) program on Linux. > > Hi sorry, I just disvovered this: > > Reducing transfer size from 64512 to 32768 bytes. > resid: 60 > resid: 28 > > This may be related to a Linux kernel (driver) bug that has been reported in > January. > > Please try to call > > cdrecord scgopts=ignore-resid ... > > to ignore this false error message from the kernel. > > Jörg > |
From: Joerg S. <Joe...@fo...> - 2016-08-31 15:38:35
|
Sorry for the last misformatted mail, here is the same in readable: Joerg Schilling <Joe...@fo...> wrote: > Your problem is not a problem with cderecord but either caused by your usage or > caused by another (hostile) program on Linux. Hi sorry, I just disvovered this: Reducing transfer size from 64512 to 32768 bytes. resid: 60 resid: 28 This may be related to a Linux kernel (driver) bug that has been reported in January. Please try to call cdrecord scgopts=ignore-resid ... to ignore this false error message from the kernel. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Joerg S. <Joe...@fo...> - 2016-08-31 15:27:51
|
Joerg Schilling <Joe...@fo...> wrote: > The error message is either caused by non-working DMA or by a hostile program > that disregards the rules for accessing CD-ROM drives that may be written to. Hi sorry, I just disvovered this: Reducing transfer size from 64512 to 32768 bytes. resid: 60 resid: 28 This may be related to a Linux kernel (driver) bug that has been reported in January. Please try to call cdrecord scgopts=ignore-resid ... to ignore this false error message from the kernel. OCODODOAOAOB~A |
From: Steve N. <sr...@co...> - 2016-08-31 13:57:35
|
BTW, AFAIK there is no HAL daemon -- thankfully, HAL disappeared from our hosts some years ago, now, and, yes, it was very obnoxious. Lsof is unaware of anybody lurking around /dev/sr0, but of course lsof has no access to the contents of any .gvfs. I have not mastered Gnome, I guess because I have a love/hate relationship with it, as do many others. I maintain 17 hosts that run Ubuntu server 16.04.01 with XFCE. I'm grateful for all your many contributions to our operating environment here, and I'm glad to find an opportunity to share information with you that you evidently don't already have. I've never had any before now. On 08/31/2016 07:37 AM, Joerg Schilling wrote: > Steve Newcomb <sr...@co...> wrote: > >> Dear Schily, >> >> I just bought a Yokkao USB-3 DVD drive from Amazon/China >> <https://www.amazon.com/gp/product/B01EMXQBLM>. It failed to burn a >> DVD+R with cdrecord 3.01 -- a version I have used countless times with >> other DVD drives. It also failed with 3.02. >> >> However, the hardware worked perfectly with the xfburn tool that >> evidently comes with Xubuntu 16.04, and I verified the resulting DVD; >> it really did work. >> >> Obviously, I would prefer to use cdrecord rather than xfburn. I'm >> attaching the output of the cdrecord 3.02 session FYI. > Your problem is not a problem with cderecord but either caused by your usage or > caused by another (hostile) program on Linux. > > Because Linux comes with competing drivers for CD-ROMs that partially do not > implement working or useful DMA, it is a really bad idea to force cdrecord to > use the unsupported dev=/dev/* syntax. Either fully remove the dev= parameter > (in case you have only one CD-ROM drive in the system) or use the SCSI CAM > standard conforming dev=b,t,l syntax. This allows libscg to select the best > driver which is usually /dev/sg*, so make sure that your system has /dev/sg* > available. > > The error message is either caused by non-working DMA or by a hostile program > that disregards the rules for accessing CD-ROM drives that may be written to. > > The first hostile program that was known to interrupt CD-ROM writing is "hald" > but later the same defective code has been moved to "udev" or to "systemd". > > If using the officially supported dev=b,t,l syntax does not help, you need to > kill the program that incorporates the defective and hostile code. > > As you might not use "hald", you would need to get help from other people to > learn which program you need to kill. > > http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily |
From: Steve N. <sr...@co...> - 2016-08-31 13:41:58
|
Dear Schily -- Many thanks for your kind response. I also tried it with a CAM device argument, and that failed, too. Session attached herewith. Steve On 08/31/2016 07:37 AM, Joerg Schilling wrote: > Steve Newcomb <sr...@co...> wrote: > >> Dear Schily, >> >> I just bought a Yokkao USB-3 DVD drive from Amazon/China >> <https://www.amazon.com/gp/product/B01EMXQBLM>. It failed to burn a >> DVD+R with cdrecord 3.01 -- a version I have used countless times with >> other DVD drives. It also failed with 3.02. >> >> However, the hardware worked perfectly with the xfburn tool that >> evidently comes with Xubuntu 16.04, and I verified the resulting DVD; >> it really did work. >> >> Obviously, I would prefer to use cdrecord rather than xfburn. I'm >> attaching the output of the cdrecord 3.02 session FYI. > Your problem is not a problem with cderecord but either caused by your usage or > caused by another (hostile) program on Linux. > > Because Linux comes with competing drivers for CD-ROMs that partially do not > implement working or useful DMA, it is a really bad idea to force cdrecord to > use the unsupported dev=/dev/* syntax. Either fully remove the dev= parameter > (in case you have only one CD-ROM drive in the system) or use the SCSI CAM > standard conforming dev=b,t,l syntax. This allows libscg to select the best > driver which is usually /dev/sg*, so make sure that your system has /dev/sg* > available. > > The error message is either caused by non-working DMA or by a hostile program > that disregards the rules for accessing CD-ROM drives that may be written to. > > The first hostile program that was known to interrupt CD-ROM writing is "hald" > but later the same defective code has been moved to "udev" or to "systemd". > > If using the officially supported dev=b,t,l syntax does not help, you need to > kill the program that incorporates the defective and hostile code. > > As you might not use "hald", you would need to get help from other people to > learn which program you need to kill. > > http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily |
From: Joerg S. <Joe...@fo...> - 2016-08-31 11:38:03
|
Steve Newcomb <sr...@co...> wrote: > Dear Schily, > > I just bought a Yokkao USB-3 DVD drive from Amazon/China > <https://www.amazon.com/gp/product/B01EMXQBLM>. It failed to burn a > DVD+R with cdrecord 3.01 -- a version I have used countless times with > other DVD drives. It also failed with 3.02. > > However, the hardware worked perfectly with the xfburn tool that > evidently comes with Xubuntu 16.04, and I verified the resulting DVD; > it really did work. > > Obviously, I would prefer to use cdrecord rather than xfburn. I'm > attaching the output of the cdrecord 3.02 session FYI. Your problem is not a problem with cderecord but either caused by your usage or caused by another (hostile) program on Linux. Because Linux comes with competing drivers for CD-ROMs that partially do not implement working or useful DMA, it is a really bad idea to force cdrecord to use the unsupported dev=/dev/* syntax. Either fully remove the dev= parameter (in case you have only one CD-ROM drive in the system) or use the SCSI CAM standard conforming dev=b,t,l syntax. This allows libscg to select the best driver which is usually /dev/sg*, so make sure that your system has /dev/sg* available. The error message is either caused by non-working DMA or by a hostile program that disregards the rules for accessing CD-ROM drives that may be written to. The first hostile program that was known to interrupt CD-ROM writing is "hald" but later the same defective code has been moved to "udev" or to "systemd". If using the officially supported dev=b,t,l syntax does not help, you need to kill the program that incorporates the defective and hostile code. As you might not use "hald", you would need to get help from other people to learn which program you need to kill. http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily |
From: Steve N. <sr...@co...> - 2016-08-30 20:24:10
|
# cdrecord dev=/dev/sr0 -v /nobackup/ub[?5h[?5luntu-16.04.1-server-amd64.iso cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.02a06 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2016 Joerg Schilling TOC Type: 1 = CD-ROM scsidev: '/dev/sr0' devname: '/dev/sr0' scsibus: -2 target: -2 lun: -2 Warning: Open by 'devname' is unintentional and not supported. Linux sg driver version: 3.5.27 Using libscg version 'schily-0.9'. SCSI buffer size: 64512 atapi: 1 Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'TSSTcorp' Identifikation : 'DVD+-RW TS-L633C' Revision : 'DW20' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: DVD+R Profile: DVD-R/DL sequential recording Profile: DVD+R/DL Profile: DVD+R (current) Profile: DVD+RW Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-ROM Profile: CD-RW Profile: CD-R Profile: CD-ROM Profile: Removable Disk Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr). Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE Supported modes: PACKET SAO Drive buf size : 1439744 = 1406 KB cdrecord: Warning: Cannot read drive buffer. cdrecord: Warning: The DMA speed test has been skipped. FIFO size : 4194304 = 4096 KB Track 01: data 667 MB Total size: 667 MB = 341504 sectors Current Secsize: 2048 Blocks total: 2295104 Blocks current: 2295104 Blocks remaining: 1953600 Reducing transfer size from 64512 to 32768 bytes. resid: 60 resid: 28 Starting to write CD/DVD/BD at speed 8 in real SAO mode for single session. Last chance to quit, starting real write in 9 seconds. 8 seconds. 7 seconds. 6 seconds. 5 seconds. 4 seconds. 3 seconds. 2 seconds. 1 seconds. 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. resid: 60 Starting new track at sector: 0 Track 01: 0 of 667 MB written.cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 00 00 00 00 10 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 02 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0 Sense flags: Blk 0 (not valid) resid: 32768 cmd finished after 2.275s timeout 200s write track data: error after 0 bytes cdrecord: The current problem looks like a buffer underrun. cdrecord: Try to use 'driveropts=burnfree'. cdrecord: Make sure that you are root, enable DMA and check your HW/OS set up. Writing time: 36.632s (00:00:36.632) Average write speed 13.8x. Fixating... operation 0% done ^Ccdrecord: Caught interrupt. cdrecord: fifo had 129 puts and 2 gets. cdrecord: fifo was 0 times empty and 1 times full, min fill was 99%. |
From: Joerg S. <Joe...@fo...> - 2016-06-22 11:47:43
|
Leszek Prochniak <pro...@sl...> wrote: > Dear Joerg, > Thank you again. I think that possible change in MC (if really needed is > not a problem) but I still can see some difference between isoinfo versions > 3.01 and 3.02 (below). Maybe MC uses options "-R -J". > Regards > Leszek > > File ADRIANE-KNOPPIX_V7.2.0gCD-2013-07-28-EN.iso > > ver 3.01 options -l -J > Directory listing of / > d--------- 0 0 0 2048 Jul 29 2013 [ 43 02] KNOPPIX > ---------- 0 0 0 54 Jun 17 2001 [ 3649 00] autorun.bat > > ver 3.01 options -l -R > 3649 -r-xr-xr-x 1 0 0 54 Jun 17 2001 [ 3649 00] autorun.bat > 35 dr-xr-xr-x 3 0 0 4096 Jul 29 2013 [ 35 02] KNOPPIX > > ver 3.01 options -l -R -J > d--------- 0 0 0 2048 Jul 29 2013 [ 43 02] KNOPPIX > ---------- 0 0 0 54 Jun 17 2001 [ 3649 00] autorun.bat > > > > ver 3.02 options -l -J > 43 dr-xr-xr-x 1 0 0 2048 Jul 29 2013 [ 43 02] KNOPPIX > 3649 -r-xr-xr-x 1 0 0 54 Jun 17 2001 [ 3649 00] autorun.bat > > ver 3.02 options -l -R > 3649 -r-xr-xr-x 1 0 0 54 Jun 17 2001 [ 3649 00] autorun.bat > 35 dr-xr-xr-x 3 0 0 4096 Jul 29 2013 [ 35 02] KNOPPIX > > ver 3.02 options -l -R -J > 43 dr-xr-xr-x 1 0 0 2048 Jul 29 2013 [ 43 02] KNOPPIX > 3649 -r-xr-xr-x 1 0 0 54 Jun 17 2001 [ 3649 00] autorun.bat Between 3.01 and 3.02, there have been mainly bug fixes and support for multi extent files was added. In November 2015, the struct stat in isoinfo was filled with useful defaults for the permissions (when no RR is present) and with the inode number, wenn it is flagged to be available by mkisofs in the "MKI" block if the filesystem. So the output did change a bit. The code to understand that MKI flags a filesystem where the block numbers from ISO-9660 may be used a inode numbers is in mkisofs since Autumn 2006 and since the same time, there is support for that feature in the Solaris iso-9660 kernel filesystem implementation. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Joerg S. <Joe...@fo...> - 2016-06-22 08:42:09
|
Leszek Prochniak <pro...@sl...> wrote: > Dear Joerg, > Thank you for explanation. I came upon this problem when using Midnight > Commander file manager to inspect contents of iso files (without a need to > mount them). After upgrading cdrtools to 3.02a2 version MC stopped to > work with some files while others are still OK. The change is based on the change in mkisofs that introduced reliable inode numbers even with plain ISO-9660 that happened with cdrtools 2.01.01a18 in October 2006 and a change in isoinfo in the same release. This is nearly 10 years ago and nobody ever complained about this change. > Is there any option (or maybe you plan to add such) to get the isoinfo > output similar to ver 3.01 (ie. without first column) or the > appropriate change should be done rather on the MC side? 3.01 behaves the same as the current version. If MC uses isoinfo, it should have complained long ago or added support for the change. In any case, adding a new option would not make MC work again. > Another minor point. I have an iso file made from a source with broken > symlinks. The output of isoinfo gives > 18446744073709551598 -r-xr-xr-x 1 0 0 0 Mar 9 1971 [ -18 00] FLASHPLA > Is this OK? The new inode algorithm that allows hard links with ISO-9660 is based on the starting sector number os a file and in case of files with no content, it uses speudo "negative" numbers. This seems to be the 18th file on the medium that does not have a data section. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Joerg S. <Joe...@fo...> - 2016-06-21 12:28:46
|
Leszek Prochniak <pro...@sl...> wrote: > I have a question about an output of the "isoinfo -l" command. I am using > isoinfo ver. 3.02a02 on Slackware64-current. Below are partial outputs > for two exemplary iso files. > > 1. isoinfo -l -i gparted-live-0.24.0-2-amd64.iso > > Directory listing of / > dr-xr-xr-x 1 0 0 2048 Oct 28 2015 [ 331 02] . > dr-xr-xr-x 1 0 0 2048 Oct 28 2015 [ 331 02] .. > dr-xr-xr-x 1 0 0 2048 Oct 28 2015 [ 334 02] EFI > -r-xr-xr-x 1 0 0 712 Oct 28 2015 [ 357 00] GPARTED_LIVE_VERSION.;1 > -r-xr-xr-x 1 0 0 18092 Aug 12 2012 [ 358 00] GPL.;1 > > 2. isoinfo -l -i ADRIANE-KNOPPIX_V7.2.0gCD-2013-07-28-EN.iso > > Directory listing of / > 29 dr-xr-xr-x 1 0 0 2048 Jun 15 2013 [ 29 02] . > 29 dr-xr-xr-x 1 0 0 2048 Jun 15 2013 [ 29 02] .. > 3649 -r-xr-xr-x 1 0 0 54 Jun 17 2001 [ 3649 00] AUTORUN.BAT;1 > 3650 -r-xr-xr-x 1 0 0 45 Feb 23 2003 [ 3650 00] AUTORUN.INF;1 > 3651 -r-xr-xr-x 1 0 0 967 May 1 2004 [ 3651 00] AUTORUN.PIF;1 > > The manpage says we should expect the output similar to "ls -lR" so the > second form is rather unexpected. Moreover, entries in the first column are > identical to those in square brackets. > Is there any reason for the second type of output which appears also > for several other iso files? The second form appears when the iso image contains inode numbers. This happens when there is either Rock Ridge and you tell isoinfo to list RR or when the iso image has been created by a mkisofs version from Autumn 2006 or later. So in this case, the listing is similar to ls -lRi BTW: if you like a listing that is identical to the listing from ls, use isoinfo -i file.iso -find -ls Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Leszek P. <pro...@sl...> - 2016-06-20 22:17:53
|
I have a question about an output of the "isoinfo -l" command. I am using isoinfo ver. 3.02a02 on Slackware64-current. Below are partial outputs for two exemplary iso files. 1. isoinfo -l -i gparted-live-0.24.0-2-amd64.iso Directory listing of / dr-xr-xr-x 1 0 0 2048 Oct 28 2015 [ 331 02] . dr-xr-xr-x 1 0 0 2048 Oct 28 2015 [ 331 02] .. dr-xr-xr-x 1 0 0 2048 Oct 28 2015 [ 334 02] EFI -r-xr-xr-x 1 0 0 712 Oct 28 2015 [ 357 00] GPARTED_LIVE_VERSION.;1 -r-xr-xr-x 1 0 0 18092 Aug 12 2012 [ 358 00] GPL.;1 2. isoinfo -l -i ADRIANE-KNOPPIX_V7.2.0gCD-2013-07-28-EN.iso Directory listing of / 29 dr-xr-xr-x 1 0 0 2048 Jun 15 2013 [ 29 02] . 29 dr-xr-xr-x 1 0 0 2048 Jun 15 2013 [ 29 02] .. 3649 -r-xr-xr-x 1 0 0 54 Jun 17 2001 [ 3649 00] AUTORUN.BAT;1 3650 -r-xr-xr-x 1 0 0 45 Feb 23 2003 [ 3650 00] AUTORUN.INF;1 3651 -r-xr-xr-x 1 0 0 967 May 1 2004 [ 3651 00] AUTORUN.PIF;1 The manpage says we should expect the output similar to "ls -lR" so the second form is rather unexpected. Moreover, entries in the first column are identical to those in square brackets. Is there any reason for the second type of output which appears also for several other iso files? Regards Leszek |
From: Joerg S. <Joe...@fo...> - 2016-05-03 10:33:14
|
Christian Lohmaier <loh...@go...> wrote: > > Who blacklists this extension? > > sourceforge's server > ### > Technical details of permanent failure: > Google tried to deliver your message, but it was rejected by the > server for the recipient domain lists.sourceforge.net by > mx.sourceforge.net. [216.34.181.68]. > > The error that the other server returned was: > 550 Blacklisted file extension detected > ### Well, they do not seem to explain way :-( > > Why do you believe that there is a problem in the inf files? > > Just because without -useinfo the result is playable in the CD player > in the car as well as on the HiFi system.. And since some early CDs > made use of pregap and similar to hide bonus tracks, and having > everthing play back as track 2 was kind of similar to me... Well, this CD uses "no pregap"s - in other words: it does not include a "index 0" area for the tracks and this area is intended to be able to locate the beginning of the next track from the standard. A standard compliant CD is not allowed to be formatted this way. It may be that this is a bug in the player. What happens when you try to play the original disk in the same player? > > A typical known reason for the problem you describe is that you are using a > > CD-writer that was made by Lite-ON. > > Samsung SE-506CB (externes Laufwerk, > http://www.samsung.com/fr/consumer/memory-storage/odd/external-dvd-writers/SE-506CB/RSBD > ) > Of course that might still have similar bug IIRC, Samsung did never create own writers, so they may have bought it somewhere... > > BTW: the documented best way to extract the CD is to call: > > > > cdda2wav paraopts=proof -vall cddb=0 -B > > Oh, did that change? (and documented where btw, Couldn't find it in > readmes) - changelog indicates it has been there since 2010 - must > have slept under a rock :-) It is in the cdrecord man page since a while. paraopts=proof has been introduced in January 2010. Since October 2015 "c2check" is included again in the "proof" macro and turned on in case the drive supports c2check. Note that currently c2check is only used to prevent libparanoia to believe everything was OK when a high quality drive always delivers the same data for a completely unreadable disk, so it helps to give better statistics for each track. The other parts of the macro define a better ninimal overlapping and permit more retries in libparanoia. Note that during the past years, there have been many fixes to libpparanoia that are specific to cdrtools and that help to detect read problems and that increase the quality of the results. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Christian L. <loh...@go...> - 2016-05-03 10:10:14
|
Hi Jörg, On Tue, May 3, 2016 at 11:44 AM, Joerg Schilling <Joe...@fo...> wrote: > Christian Lohmaier <loh...@go...> wrote: > […] > Who blacklists this extension? sourceforge's server ### Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the server for the recipient domain lists.sourceforge.net by mx.sourceforge.net. [216.34.181.68]. The error that the other server returned was: 550 Blacklisted file extension detected ### >> Are the .inf files bogus/anything I can do to help pin down the problem? > > Why do you believe that there is a problem in the inf files? Just because without -useinfo the result is playable in the CD player in the car as well as on the HiFi system.. And since some early CDs made use of pregap and similar to hide bonus tracks, and having everthing play back as track 2 was kind of similar to me... > A typical known reason for the problem you describe is that you are using a > CD-writer that was made by Lite-ON. Samsung SE-506CB (externes Laufwerk, http://www.samsung.com/fr/consumer/memory-storage/odd/external-dvd-writers/SE-506CB/RSBD ) Of course that might still have similar bug > The firmware partially creates a > decrementing real time in the sub-channels when writing in session at one mode. > > A workaround is to write the CD in RAW mode by specifying "-raw96r" as write > mode to cdrecord. I'll try that. > BTW: the documented best way to extract the CD is to call: > > cdda2wav paraopts=proof -vall cddb=0 -B Oh, did that change? (and documented where btw, Couldn't find it in readmes) - changelog indicates it has been there since 2010 - must have slept under a rock :-) Thanks for the info ciao Christian |
From: Joerg S. <Joe...@fo...> - 2016-05-03 09:57:18
|
Christian Lohmaier <loh...@go...> wrote: > Hi *, > > when trying to copy the CD that was extracted with > /opt/schily/bin/cdda2wav -v all -B -paranoia > without reporting any errors, adding title/album info to the inf files > and then burning with > > /opt/schily/bin/cdrecord -v -dao -text -useinfo *wav > > the result is a broken audio-cd. The first track plays OK, but the > CD-Player in the car chokes on the second track. It plays first > seconds, then jumps/skips a little, then cycles through the tracks in > silence until it starts playing back track 1. > The desk in the home stereo can play back track 2, but also plays the > remaining tracks while still displaying track 2. > Not using -useinfo results in CD that can be played back, but of > course without CDT ext information. > > I'll attach the first 5 track's inf files for reference (hope to stay > within the mailsize limit with those). Renamed to *.info, as inf is a > blacklisted file extension :-( Who blacklists this extension? > Are the .inf files bogus/anything I can do to help pin down the problem? Why do you believe that there is a problem in the inf files? A typical known reason for the problem you describe is that you are using a CD-writer that was made by Lite-ON. The firmware partially creates a decrementing real time in the sub-channels when writing in session at one mode. A workaround is to write the CD in RAW mode by specifying "-raw96r" as write mode to cdrecord. BTW: the documented best way to extract the CD is to call: cdda2wav paraopts=proof -vall cddb=0 -B You may use cddb=1 in case you expect multiple cddb resulty and like to manually select the right one. Jörg -- EMail:jo...@sc... (home) Jörg Schilling D-13353 Berlin joe...@fo... (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' |
From: Christian L. <loh...@go...> - 2016-05-03 09:21:23
|
Hi *, when trying to copy the CD that was extracted with /opt/schily/bin/cdda2wav -v all -B -paranoia without reporting any errors, adding title/album info to the inf files and then burning with /opt/schily/bin/cdrecord -v -dao -text -useinfo *wav the result is a broken audio-cd. The first track plays OK, but the CD-Player in the car chokes on the second track. It plays first seconds, then jumps/skips a little, then cycles through the tracks in silence until it starts playing back track 1. The desk in the home stereo can play back track 2, but also plays the remaining tracks while still displaying track 2. Not using -useinfo results in CD that can be played back, but of course without CDT ext information. I'll attach the first 5 track's inf files for reference (hope to stay within the mailsize limit with those). Renamed to *.info, as inf is a blacklisted file extension :-( Are the .inf files bogus/anything I can do to help pin down the problem? ciao Christian |
From: grarpamp <gra...@gm...> - 2016-02-27 04:58:00
|
Has anyone done a recent (as to current featuresets / performance / architecture) comparison of these? Is EAC expected to release source? |