Nabble - Cdrecord-support

cdrtools-2.01.01a69 ready

2009-11-30T12:15:52Z

Note that this release contains a work around for new drives developed by
Pioneer sold under the brands: Pioneer, Plextor and TEAC.

NEW features of cdrtools-2.01.01a69:

*******
NOTE: cdrtools is currently in a state of a release candidate for the next
major release.

*******

All:

- Support for 64 Bit compilation was added for IRIX.
Call smake CCOM=cc64 or smake CCOM=gcc64 as usual.

- C++ compilation support fior IRIX was added to the makefile system

- Schily Makefile rules no longer contain Simple Suffix Rules.
All default rules are now based on Pattern Matching Rules.
This speeds up smake.

- Added autoconf test to distinct Linux ACLs from IRIX ACLs

Libschily:

- Removed some GCC warnings from libschily/getargs.c

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

- let libfind deal with the differences between Linux ACLs and IRIX ACLs

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

- Removed some GCC warnings from libscg/scsi-sgi.c

Libscgcmd:

Libmdigest:

Rscsi:

Cdrecord:

- Work around a bug in the firmware from drives
developed by PIONEER in November 2009. This affects
drives labelled "Pioneer", "Plextor" and "TEAC".
Do no longer call cdr_buffer_cap() before the drive
buffer was not at least filled once to avoid that
the the drive throughs away all data.

- Man page reworked

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

- Man page reworked

- Removed some (int) casts before the SNDCTL_DSP_* ioctl()s

Readcd:

- Man page reworked

Scgcheck:

- Man page reworked

Scgskeleton:

Btcflash:

- Man page reworked

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- Various Cstyle changes

HELIOS TODO:

- Add the HELIOS UNICODE mapping code. This needs to be done
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

- Make the Apple extensions work again with "mkisofs -find"

TODO:
- Support correct inode numbers for UDF hardlinks

- Support sockets, pipes, char/blk-dev specials with UDF

- read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

- add libecc/edc for CDI and similar.

The files are located on:

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a68 ready

2009-11-19T07:32:02Z

NEW features of cdrtools-2.01.01a68:

*******
NOTE: cdrtools is currently in a state of a release candidate for the next
major release.

*******

All:

- VMS rules for libraries not create an archive XXX.olb instead of libXXX.a

- schily/utypes.h enhanced to allow to define maxint_t which is
missing on VMS

- Better autoconf test for union wait vs. int for platforms that
define union wait but use int as wait() parameter.

- schily/vfork.h now includes unistd.h as the related definitions
are there on Solaris

- Fixed a configure bug with opendir() inherited from GNU autoconf

- Enhanced the vfork() autoconf test to avoid a hang on VMS

Libschily:

- libschily/spawn.c now uses vfork()

- libschily/fexec.c now supports IO redirection on VMS

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

- Some #define inline definitions removed as "inline" is already
handled by schily/mconfig.h

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

- Fixed a typo in idcache.c

Libfile:

- Some changes for better VMS support

Libhfs_iso:

- Removed a warning from the HP-UX C-compiler about a possible endless loop

Libsiconv:

- Add the VMS C-compiler to the list of exceptions for not fully C99 compliant
compilers to allow compilation.

Libscg:

- changed a include path in libscg/scsi-mac-iokit.c to allow
compilation on "Snow Leopard"

Libscgcmd:

Libmdigest:

Rscsi:

Cdrecord:

- Added a workaround for a firmware oddity with DVD+RW on
'_NEC ' 'DVD_RW ND-3500AG' with media written from other drives.

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

- Added a forgotten modification in ringbuff.c that caused an abort due to
a wrong assert() condition.

Readcd:

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- Fixed a bug (writing to stdout instead of stderr) recently introduced with better
RR recognition support.

- "isoinfo" now supports iconv() based locales for Joliet.

HELIOS TODO:

- Add the HELIOS UNICODE mapping code. This needs to be done
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

- Make the Apple extensions work again with "mkisofs -find"

TODO:
- Support correct inode numbers for UDF hardlinks

- Support sockets, pipes, char/blk-dev specials with UDF

- read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

- add libecc/edc for CDI and similar.

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: -scanbus broken with hardware raid

2009-11-11T06:32:30Z

Am 10.11.2009, 16:40 Uhr, schrieb Joerg Schilling
<Joerg.Schilling@...>:

Rather missing feature or support for Linux interfaces.

Spare the world such useless warnings.
If that were a technical complaint, it might make sense.

>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 (i686-pc-linux-gnu) Copyright (C)
>> 1995-2009 Jörg Schilling
>> Using libscg version 'schily-0.9'.
>> scsibus0:
>> 0,0,0 0) 'Adaptec ' '2200S Legacy ' 'V1.0' Disk
>> 0,1,0 1) 'Adaptec ' 'Media ' 'V1.0' Disk
>> 0,2,0 2) *
>> 0,3,0 3) 'MAXTOR ' 'ATLAS10K5_147WLS' 'GVV0' Disk
>> 0,4,0 4) *
>> 0,5,0 5) 'YAMAHA ' 'CRW-F1S ' '1.0g' Removable
>> CD-ROM
>> 0,6,0 6) *
>> 0,7,0 7) *
>>
>> However, sgdiag (from http://scsirastools.sourceforge.net/) shows the
>> correct
>> output:
>> -- sgdiag v1.60 log started at Fri Nov 6 08:32:13 2009
>> 0 /dev/sg0 [0:0:0:0] Disk Adaptec 2200S Legacy V1.0 [em]
>> 1 /dev/sg1 [0:0:1:0] Disk Adaptec Media V1.0 [em]
>> 2 /dev/sg2 [0:1:0:0] Disk ModusLnk [em]
>> 3 /dev/sg3 [0:1:1:0] Disk ModusLnk MXJ3300SC800600W M108 ML0001 [em]
>> 4 /dev/sg4 [0:1:3:0] Disk MAXTOR ATLAS10K5_147WLS GVV0 D4Y00QYK [em]
>> 5 /dev/sg5 [0:2:5:0] CDRM YAMAHA CRW-F1S 1.0g 16/04/03 [em]

| | | \___ LUN
| | \___ device ID
| \___ channel
\___ bus/host adaptor

...

> Linux drivers make a strange assumptions by calling the different SCSI
> busses
> on a single card "channels" but without implementing a kernel interface
> that
> allows to ask about the number of busses on that card. This makes it
> impossible
> to implement a mapping from the Linux Scheme to what the SCSI standard
> defines
> for the CAM interface.

This is false. How could sgdiag then have obtained the bus:channel:id:lun
information that Joe showed? The truth is that sgdiag uses ioctl()s to
obtain this information. Look at lines 695 - 706 of
<http://scsirastools.svn.sourceforge.net/viewvc/scsirastools/trunk/src/sgcommon.c?revision=22&view=markup>,
695-698, 703-706, 713f in particular.

And IIRC your code iterates over all /dev/sg* nodes anyways, so you get
information about all relevant buses (those with devices attached).

Please don't ask me where the official documentation for these interfaces
resides, I'm too unmotivated to dig that up for you, and it's not my
software that invents (rather than queries the kernel) such IDs...

Even after all those years I fail to see why we conceptually need to map
devices to the bus/ch/id/lun thing only to have cdrecord maps it back
later. That's two needless indirections and *heaps* of code that needs to
be cared for all the time. We should just be using a device node and be
done.

--
Matthias Andree
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: -scanbus broken with hardware raid

2009-11-10T13:06:39Z

Michael Shell <list1@...> wrote:

> On Tue, 10 Nov 2009 16:40:05 +0100
> Joerg.Schilling@... (Joerg Schilling) wrote:
>
> > Linux drivers make a strange assumptions by calling the different SCSI
> > busses on a single card "channels" but without implementing a kernel
> > interface that allows to ask about the number of busses on that card.
> > This makes it impossible to implement a mapping from the Linux Scheme
> > to what the SCSI standard defines for the CAM interface.
>
>
> I assume this is not an issue on Solaris. Just for comparison, how does
> say, FreeBSD, rate in this regard?

FreeBSD implements a CAM standard interface and thus only offers the standard
addressing scheme bus,target,lun.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: -scanbus broken with hardware raid

2009-11-10T10:30:32Z

On Tue, November 10, 2009 07:40, Joerg Schilling wrote:

> Joe Feise <jfeise@...> wrote:
>
>> I have a SCSI hardware RAID system, using an Adaptec 2200S dual channel
>> card.
>> Channel 1 has a RAID 1 and a RAID 0 disk, channel 2 has a CD-ROM drive.
>> cdrecord -scanbus shows this output:
>> Linux sg driver version: 3.5.34
>> cdrecord: Warning Linux Bus mapping botch.
>> cdrecord: Warning Linux Bus mapping botch.
>> cdrecord: Warning Linux Bus mapping botch.
>> cdrecord: Warning Linux Bus mapping botch.
>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 (i686-pc-linux-gnu) Copyright (C)
>> 1995-2009 Jörg Schilling
>> Using libscg version 'schily-0.9'.
>> scsibus0:
>> 0,0,0 0) 'Adaptec ' '2200S Legacy ' 'V1.0' Disk
>> 0,1,0 1) 'Adaptec ' 'Media ' 'V1.0' Disk
>> 0,2,0 2) *
>> 0,3,0 3) 'MAXTOR ' 'ATLAS10K5_147WLS' 'GVV0' Disk
>> 0,4,0 4) *
>> 0,5,0 5) 'YAMAHA ' 'CRW-F1S ' '1.0g' Removable
>> CD-ROM
>> 0,6,0 6) *
>> 0,7,0 7) *
>>
>> However, sgdiag (from http://scsirastools.sourceforge.net/) shows the
>> correct
>> output:
>> -- sgdiag v1.60 log started at Fri Nov 6 08:32:13 2009
>> 0 /dev/sg0 [0:0:0:0] Disk Adaptec 2200S Legacy V1.0 [em]
>> 1 /dev/sg1 [0:0:1:0] Disk Adaptec Media V1.0 [em]
>> 2 /dev/sg2 [0:1:0:0] Disk ModusLnk [em]
>> 3 /dev/sg3 [0:1:1:0] Disk ModusLnk MXJ3300SC800600W M108 ML0001 [em]
>> 4 /dev/sg4 [0:1:3:0] Disk MAXTOR ATLAS10K5_147WLS GVV0 D4Y00QYK [em]
>> 5 /dev/sg5 [0:2:5:0] CDRM YAMAHA CRW-F1S 1.0g 16/04/03 [em]
>>
>> In other words, the RAID disks are listed at channel 0, the physical
>> disks on
>> channel 1 are listed at channel 1, and the cdrom on channel 2 is listed
>> on
>> channel 2, which is the correct layout.
>
> Linux drivers make a strange assumptions by calling the different SCSI
> busses
> on a single card "channels" but without implementing a kernel interface
> that
> allows to ask about the number of busses on that card. This makes it
> impossible
> to implement a mapping from the Linux Scheme to what the SCSI standard
> defines
> for the CAM interface.

Well, it may be that the assumptions are strange, but as the sgdiag output
shows, it is possible to get this information.
Further, /proc/scsi/scsi also shows the correct channel, id, and lun.

-Joe

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: -scanbus broken with hardware raid

2009-11-10T09:46:32Z

On Tue, 10 Nov 2009 16:40:05 +0100
Joerg.Schilling@... (Joerg Schilling) wrote:

> Linux drivers make a strange assumptions by calling the different SCSI
> busses on a single card "channels" but without implementing a kernel
> interface that allows to ask about the number of busses on that card.
> This makes it impossible to implement a mapping from the Linux Scheme
> to what the SCSI standard defines for the CAM interface.

I assume this is not an issue on Solaris. Just for comparison, how does
say, FreeBSD, rate in this regard?

Cheers,

Mike Shell

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: -scanbus broken with hardware raid

2009-11-10T07:40:05Z

Joe Feise <jfeise@...> wrote:

> I have a SCSI hardware RAID system, using an Adaptec 2200S dual channel card.
> Channel 1 has a RAID 1 and a RAID 0 disk, channel 2 has a CD-ROM drive.
> cdrecord -scanbus shows this output:
> Linux sg driver version: 3.5.34
> cdrecord: Warning Linux Bus mapping botch.
> cdrecord: Warning Linux Bus mapping botch.
> cdrecord: Warning Linux Bus mapping botch.
> cdrecord: Warning Linux Bus mapping botch.
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 (i686-pc-linux-gnu) Copyright (C)
> 1995-2009 Jörg Schilling
> Using libscg version 'schily-0.9'.
> scsibus0:
> 0,0,0 0) 'Adaptec ' '2200S Legacy ' 'V1.0' Disk
> 0,1,0 1) 'Adaptec ' 'Media ' 'V1.0' Disk
> 0,2,0 2) *
> 0,3,0 3) 'MAXTOR ' 'ATLAS10K5_147WLS' 'GVV0' Disk
> 0,4,0 4) *
> 0,5,0 5) 'YAMAHA ' 'CRW-F1S ' '1.0g' Removable CD-ROM
> 0,6,0 6) *
> 0,7,0 7) *
>
> However, sgdiag (from http://scsirastools.sourceforge.net/) shows the correct
> output:
> -- sgdiag v1.60 log started at Fri Nov 6 08:32:13 2009
> 0 /dev/sg0 [0:0:0:0] Disk Adaptec 2200S Legacy V1.0 [em]
> 1 /dev/sg1 [0:0:1:0] Disk Adaptec Media V1.0 [em]
> 2 /dev/sg2 [0:1:0:0] Disk ModusLnk [em]
> 3 /dev/sg3 [0:1:1:0] Disk ModusLnk MXJ3300SC800600W M108 ML0001 [em]
> 4 /dev/sg4 [0:1:3:0] Disk MAXTOR ATLAS10K5_147WLS GVV0 D4Y00QYK [em]
> 5 /dev/sg5 [0:2:5:0] CDRM YAMAHA CRW-F1S 1.0g 16/04/03 [em]
>
> In other words, the RAID disks are listed at channel 0, the physical disks on
> channel 1 are listed at channel 1, and the cdrom on channel 2 is listed on
> channel 2, which is the correct layout.

Linux drivers make a strange assumptions by calling the different SCSI busses
on a single card "channels" but without implementing a kernel interface that
allows to ask about the number of busses on that card. This makes it impossible
to implement a mapping from the Linux Scheme to what the SCSI standard defines
for the CAM interface.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: -scanbus broken with hardware raid

2009-11-06T18:42:12Z

Joe,

The kernel was not known from your output, but the following also
could show that it was a linux box:

......
cdrecord -scanbus shows this output:
Linux sg driver version: 3.5.34

So the above line would imply that it is no a linux box. No offense
intended just an observation.

Also,
If you boot to an older kernel if possible, does the same thing happen?

Regards,

Antonio

On 11/6/09, Joe Feise <jfeise@...> wrote:

> Joe Feise wrote on 11/06/09 08:44:
>
>> I have a SCSI hardware RAID system, using an Adaptec 2200S dual channel
>> card.
>> Channel 1 has a RAID 1 and a RAID 0 disk, channel 2 has a CD-ROM drive.
>> cdrecord -scanbus shows this output:
>> Linux sg driver version: 3.5.34
>> cdrecord: Warning Linux Bus mapping botch.
>> cdrecord: Warning Linux Bus mapping botch.
>> cdrecord: Warning Linux Bus mapping botch.
>> cdrecord: Warning Linux Bus mapping botch.
>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 (i686-pc-linux-gnu) Copyright (C)
>> 1995-2009 Jörg Schilling
>> Using libscg version 'schily-0.9'.
>> scsibus0:
>> 0,0,0 0) 'Adaptec ' '2200S Legacy ' 'V1.0' Disk
>> 0,1,0 1) 'Adaptec ' 'Media ' 'V1.0' Disk
>> 0,2,0 2) *
>> 0,3,0 3) 'MAXTOR ' 'ATLAS10K5_147WLS' 'GVV0' Disk
>> 0,4,0 4) *
>> 0,5,0 5) 'YAMAHA ' 'CRW-F1S ' '1.0g' Removable CD-ROM
>> 0,6,0 6) *
>> 0,7,0 7) *
>>
>> However, sgdiag (from http://scsirastools.sourceforge.net/) shows the
>> correct
>> output:
>> -- sgdiag v1.60 log started at Fri Nov 6 08:32:13 2009
>> 0 /dev/sg0 [0:0:0:0] Disk Adaptec 2200S Legacy V1.0 [em]
>> 1 /dev/sg1 [0:0:1:0] Disk Adaptec Media V1.0 [em]
>> 2 /dev/sg2 [0:1:0:0] Disk ModusLnk [em]
>> 3 /dev/sg3 [0:1:1:0] Disk ModusLnk MXJ3300SC800600W M108 ML0001 [em]
>> 4 /dev/sg4 [0:1:3:0] Disk MAXTOR ATLAS10K5_147WLS GVV0 D4Y00QYK [em]
>> 5 /dev/sg5 [0:2:5:0] CDRM YAMAHA CRW-F1S 1.0g 16/04/03 [em]
>>
>> In other words, the RAID disks are listed at channel 0, the physical disks
>> on
>> channel 1 are listed at channel 1, and the cdrom on channel 2 is listed on
>> channel 2, which is the correct layout.
>
> I forgot to mention, the system is a Linux box.
> $: uname -a
> Linux joe 2.6.29.6 #7 SMP PREEMPT Tue Oct 27 01:39:17 PDT 2009 i686 Intel(R)
> Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux
>
> -Joe
>
> _______________________________________________
> Cdrecord-support mailing list
> Cdrecord-support@...
> https://lists.berlios.de/mailman/listinfo/cdrecord-support
>

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: -scanbus broken with hardware raid

2009-11-06T08:48:49Z

Joe Feise wrote on 11/06/09 08:44:

I forgot to mention, the system is a Linux box.
$: uname -a
Linux joe 2.6.29.6 #7 SMP PREEMPT Tue Oct 27 01:39:17 PDT 2009 i686 Intel(R)
Pentium(R) 4 CPU 3.40GHz GenuineIntel GNU/Linux

-Joe

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

-scanbus broken with hardware raid

2009-11-06T08:44:19Z

I have a SCSI hardware RAID system, using an Adaptec 2200S dual channel card.
Channel 1 has a RAID 1 and a RAID 0 disk, channel 2 has a CD-ROM drive.
cdrecord -scanbus shows this output:
Linux sg driver version: 3.5.34
cdrecord: Warning Linux Bus mapping botch.
cdrecord: Warning Linux Bus mapping botch.
cdrecord: Warning Linux Bus mapping botch.
cdrecord: Warning Linux Bus mapping botch.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 (i686-pc-linux-gnu) Copyright (C)
1995-2009 Jörg Schilling
Using libscg version 'schily-0.9'.
scsibus0:
0,0,0 0) 'Adaptec ' '2200S Legacy ' 'V1.0' Disk
0,1,0 1) 'Adaptec ' 'Media ' 'V1.0' Disk
0,2,0 2) *
0,3,0 3) 'MAXTOR ' 'ATLAS10K5_147WLS' 'GVV0' Disk
0,4,0 4) *
0,5,0 5) 'YAMAHA ' 'CRW-F1S ' '1.0g' Removable CD-ROM
0,6,0 6) *
0,7,0 7) *

However, sgdiag (from http://scsirastools.sourceforge.net/) shows the correct
output:
-- sgdiag v1.60 log started at Fri Nov 6 08:32:13 2009
0 /dev/sg0 [0:0:0:0] Disk Adaptec 2200S Legacy V1.0 [em]
1 /dev/sg1 [0:0:1:0] Disk Adaptec Media V1.0 [em]
2 /dev/sg2 [0:1:0:0] Disk ModusLnk [em]
3 /dev/sg3 [0:1:1:0] Disk ModusLnk MXJ3300SC800600W M108 ML0001 [em]
4 /dev/sg4 [0:1:3:0] Disk MAXTOR ATLAS10K5_147WLS GVV0 D4Y00QYK [em]
5 /dev/sg5 [0:2:5:0] CDRM YAMAHA CRW-F1S 1.0g 16/04/03 [em]

In other words, the RAID disks are listed at channel 0, the physical disks on
channel 1 are listed at channel 1, and the cdrom on channel 2 is listed on
channel 2, which is the correct layout.

-Joe

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a67 ready

2009-11-02T03:01:54Z

NEW features of cdrtools-2.01.01a67:

*******
NOTE: cdrtools is currently in a state of a release candidate for the next
major release.

*******

All:

- Prevent a compiler warning when compiling 64 bit binaries on HP-UX
using make CCOM=cc64

- Some files in include/schily/*.h have been enhanced to better support VMS

- config.guess now knows about OpenVMS

- Changed bash test to use --version instead of -version as bash on OpenVMS
is bash-1.x

- include/schily/xmconfig.h (containing a "static" configuration for VMS
because "configure" does not work on VMS) was enhanced.

- Trying to add support for OpenVMS to RULES/*

- New autoconf tests for the type "long double" and a new "max size" type.

Libschily:

- libschily/*bytes.c now support 64 bit compilation and use a "ssize_t"
typed count parameter instead of "int".

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

Libscgcmd:

Libmdigest:

Rscsi:

- First complete version of a man page for rscsi.

Cdrecord:

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

- cdda2wav now correctly deals with the case when no sound device
was specified. Thanks to Robert Grimm <rob@...>
for reporting.

Readcd:

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- Make "isovfy" CD-ROM-XA aware

- Make "isodump" CD-ROM-XA aware

HELIOS TODO:

- Add the HELIOS UNICODE mapping code. This needs to be done
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

- Make the Apple extensions work again with "mkisofs -find"

TODO:
- Support correct inode numbers for UDF hardlinks

- Support sockets, pipes, char/blk-dev specials with UDF

- read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

- add libecc/edc for CDI and similar.

The files are located on:

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: Looking for porting account on AIX and others

2009-10-22T05:12:12Z

Rob Bogus <rob23@...> wrote:

> > Linux Test machine ready
> >
> Which Linux? It runs on many CPUs, and at minimum x86_32, x86_64, SPARC
> and PPC are probably worth testing due to reasonable user base.
> Reasonable defined "more than Hurd" in this case.

If Linux is written internally in a way that could be called clean and
processor independent, then the processor independence of the portability
system in cdrtools should be sufficient to hide all specifics of other CPU
types.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Looking for porting account on AIX and others

2009-10-19T15:03:52Z

Hi,

the next final release for cdrtools is close and I am of course
interested in giving the best possible. I unfortunately did not have
access to some pf the supported platforms for a long time and it
seems that AIX may be the most important platform from this list.

Is there somebody who is able to give me ssh login access to an AIX
machine with a compiler ready?

BTW: this is the current porting situation:

SunOS (SunOS-3.x & SunOS-4.x) Test machine ready
Solaris (SunOS-5.x) Test machine ready
AIX ---
Apollo Domain ---
AmigaOS ---
ATARI MiNT ---
BeOS ---
BSD-OS ---
FreeBSD Test machine ready
NetBSD Test machine ready
OpenBSD Test machine ready
DragonFlyBSD Test machine ready
DG-UX ---
GNU-Hurd ---
Cygwin on win32 Test machine ready
Cygwin on win64 Test machine ready
Max OS X Test machine ready
Haiku Test machine ready
HP-UX Test machine ready (10.20 % 11.11)
IRIX ---
Linux Test machine ready
NextSTep ---
OSF-1 (Digital UNIX) ---
OS/2 ---
SCO OpenServer Test machine ready
SCO UnixWare Test machine ready
Sony NEWS-OS ---
Syllable Test machine ready
QNX ---
VMS ---
Zeta Test machine ready

I would love to get porting access to systems that are marked with "---"

So there are other platforms that are also of interest.

Thank you in advance!

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrtools-2.01.01a66 ready

2009-10-14T05:06:24Z

Bill Davidsen <davidsen@...> wrote:

> >
> > TODO:
> > - Support correct inode numbers for UDF hardlinks
> >
> > - Support sockets, pipes, char/blk-dev specials with UDF
> >
> >
> Another thing I will try before I comment.

I forgot to mention that this is of course work that is planned for the next
release and not to happen before the recently planned final.

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrtools-2.01.01a66 ready

2009-10-13T14:22:14Z

Bill Davidsen <davidsen@...> wrote:

> Joerg Schilling wrote:
> > NEW features of cdrtools-2.01.01a66:
> >
> > *******
> > NOTE: cdrtools is currently in a state just before a new major release.
> >
> >
> >
> You have been saying this for several years, it has less meaning than
> "have a nice day," so either release a new beta or release candidate, or
> stop promising things you can't deliver. You nit-pick other's posts, so
> don't complain if you get called on this.

You are not currect: I am saying this since three releases as we are currently
getting _very_ close to the mext major release.

There is not much to do except reworking for the man pages.

BTW: since the last major release, more than 30% of the code has been rewritten
or replaced and many new funtions have been added so more than 50% of the code
is new since the last "final" release from september 2004.

There have been 7100 single file edits in 2900 edit groups, resulting in an
average of aprox. 4 file edits per day during this period.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a66 ready

2009-10-11T07:51:50Z

NEW features of cdrtools-2.01.01a66:

*******
NOTE: cdrtools is currently in a state just before a new major release.

*******

All:

- Added support for 64 bit compilation on HP-HX using "cc".
Use make CCOM=cc64 as usual to switch to 64 bit compilation.

Libschily:

- libschily/fconv.c reworked to deal with non-C99 compliant systems and to deal
with the constraints found in HP-UX-11.11.

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

- Fixed a problem in libsiconv in case that the the locale is specified as
"iconv:name".

Libscg:

- Make libscg deal with the new error code from HP-UX that
is returned for a non-existing ATAPI slave.

- Some minor changes in libscg to make scgcheck report less problems
with HP-UX

Libscgcmd:

Libmdigest:

Rscsi:

Cdrecord:

- Better man page with repect to dev=

- The cdrecord man page has been restructured.

- Fixed a bug in the workaround code for a firmware bug for DVD+R
media in HL-DT-ST drives.

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

- Better man page with repect to dev=

- The cdda2wav man page has been restructured.

Readcd:

- readcd now only send the Plextor specific SCSI commands for the -cxscan
option in case that the drive identifies as Plextor.

- Better man page with repect to dev=

Scgcheck:

- Better man page with repect to dev=

Scgskeleton:

Btcflash:

- Better man page with repect to dev=

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- mkisofs man page reworked

- isoinfo man page reworked

- New file mkisofs/rock.h

- isodump now prints more information about Rock Ridge attributes to
help debugging non-compliant Rock Ridge ISO images.

- isoinfo now correctly identifies ISO images made with the Mac OS X
program "hdiutil" by e.g. calling:

hdiutil makehybrid -iso -hfs -verbose -o xxx.iso some_dir

As filesystems that violate the Rock Ridge standard.

Check e.g. by "isoinfo -i xxx.iso -d"

Interpreting Rock Ridge on such images can be enforced by calling:

"isoinfo -i xxx.iso -lR -debug"

- mkisofs now ignores the broken Rock Ridge attributes that have been
created by the Mac OS X program "hdiutil".

HELIOS TODO:

- Add the HELIOS UNICODE mapping code. This needs to be done
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

- Make the Apple extensions work again with "mkisofs -find"

TODO:
- Support correct inode numbers for UDF hardlinks

- Support sockets, pipes, char/blk-dev specials with UDF

- read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

- add libecc/edc for CDI and similar.

The files are located on:

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord backend ripper for Grip

2009-09-29T13:25:53Z

Daniel Clark <clarkddc@...> wrote:

> Joerg,
>
> Thank you very much for your reply. Yes I am using cddaw2av. I was
> successfully able to play the cd by issuing cdda2wav -N -e -B. My issue is
> getting both cdda2wav and grip to agree. By invoking cdda2wav directly, I
> receive the expected behaviour. When attempting to use a graphical front end
> to the cdda2wav (in this case Grip), each track is skipped, and no tracks
> are ripped. I'm experiencing the same behaviour as another user;
> http://osdir.com/ml/os.solaris.blastwave.user/2005-01/msg00033.html. In my
> case, Grip was built from sources. I'm also using both the cdda2wav provided
> by Sun (snv b121), and the alpha65 cdda2wav built from sources. I'm not sure
> if this topic is better suited elsewhere. If so, then please accept my
> apologies.

Then there is a bug in grip and you need to get help from the grip people.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord backend ripper for Grip

2009-09-29T08:15:44Z

Joerg,

Thank you very much for your reply. Yes I am using cddaw2av. I was successfully able to play the cd by issuing cdda2wav -N -e -B. My issue is getting both cdda2wav and grip to agree. By invoking cdda2wav directly, I receive the expected behaviour. When attempting to use a graphical front end to the cdda2wav (in this case Grip), each track is skipped, and no tracks are ripped. I'm experiencing the same behaviour as another user; http://osdir.com/ml/os.solaris.blastwave.user/2005-01/msg00033.html. In my case, Grip was built from sources. I'm also using both the cdda2wav provided by Sun (snv b121), and the alpha65 cdda2wav built from sources. I'm not sure if this topic is better suited elsewhere. If so, then please accept my apologies.

Best Regards,
Daniel

On Thu, Sep 24, 2009 at 1:34 PM, Joerg Schilling <Joerg.Schilling@...> wrote:

clarkddc <clarkddc@...> wrote:

> If this post is off-topic, then please recieve my apologies. I've done some
> googling, and have not found an answer to my dilemma. I running Solaris
> (Nevada b121), on the x86 platform. I've build Grip from an SFE spec file.
> The stock cdrecord supplied by Sun is installed. When it's time to rip the
> cd, the ripper skips each track, creates the necessary directory structure
> for the files, however no files are ripped. I've also tried downloading and
> buidling the latest cdrtools source (alpha 65). In this case the behaviour
> is slightly different. I see negative values for the rip progress of each
> track. But there are no files being ripped. Has anyone overcome this issue?
> Any suggestions will be greatly appreciated.

If you don't send information about your problem, it is hard to help you...

You did e.g. not mention whether you used cdda2wav at all.

You should first call:

cdda2wav -N -e -B

This should play the entire disk via the audio system.

Jörg

--
EMail%3Ajoerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord backend ripper for Grip

2009-09-24T10:34:55Z

clarkddc <clarkddc@...> wrote:

> If this post is off-topic, then please recieve my apologies. I've done some
> googling, and have not found an answer to my dilemma. I running Solaris
> (Nevada b121), on the x86 platform. I've build Grip from an SFE spec file.
> The stock cdrecord supplied by Sun is installed. When it's time to rip the
> cd, the ripper skips each track, creates the necessary directory structure
> for the files, however no files are ripped. I've also tried downloading and
> buidling the latest cdrtools source (alpha 65). In this case the behaviour
> is slightly different. I see negative values for the rip progress of each
> track. But there are no files being ripped. Has anyone overcome this issue?
> Any suggestions will be greatly appreciated.

If you don't send information about your problem, it is hard to help you...

You did e.g. not mention whether you used cdda2wav at all.

You should first call:

cdda2wav -N -e -B

This should play the entire disk via the audio system.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrecord backend ripper for Grip

2009-09-24T07:58:32Z

If this post is off-topic, then please recieve my apologies. I've done some googling, and have not found an answer to my dilemma. I running Solaris (Nevada b121), on the x86 platform. I've build Grip from an SFE spec file. The stock cdrecord supplied by Sun is installed. When it's time to rip the cd, the ripper skips each track, creates the necessary directory structure for the files, however no files are ripped. I've also tried downloading and buidling the latest cdrtools source (alpha 65). In this case the behaviour is slightly different. I see negative values for the rip progress of each track. But there are no files being ripped. Has anyone overcome this issue? Any suggestions will be greatly appreciated.

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a65 ready

2009-09-15T08:27:52Z

NEW features of cdrtools-2.01.01a65:

*******
NOTE: cdrtools is currently in a state just before a new major release.

*******

All:

- *BSD comes with a broken sed(1), so we need to go back to tr(1) based
code for GNU make in the Schily Makefilesystem.

- Added support for amd64-netbsd-cc.rul to the Schily Makefilesystem

- Added support for DragonFly BSD to config.guess and config.sub

Libschily:

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

- Added a hack to liscg to allow cdrecord -scanbus to work on NetBSD

- Added a hack to liscg to allow cdrecord -scanbus to work on OpenBSD

libscg now supports -scanbus and cdrecord's autotarget feature on the
following platforms:

SunOS (SunOS-3.x & SunOS-4.x)
Solaris (SunOS-5.x)
AmigaOS
ATARI MiNT
BeOS
FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Cygwin on win32
Cygwin on win64
Max OS X
Haiku
HP-UX
IRIX
Linux
NextSTep
OSF-1 (Digital UNIX)
OS/2
SCO OpenServer
SCO UnixWare
VMS
Zeta

Libscgcmd:

Libmdigest:

Rscsi:

Cdrecord:

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Readcd:

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- Avoid signed chars ad parameter to toupper

HELIOS TODO:

- Add the HELIOS UNICODE mapping code. This needs to be done
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

- Make the Apple extensions work again with "mkisofs -find"

TODO:
- Support correct inode numbers for UDF hardlinks

- Support sockets, pipes, char/blk-dev specials with UDF

- read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

- add libecc/edc for CDI and similar.

CYGWIN NT-4.0 NOTES:

To compile on Cygwin32, get Cygwin and install it.
For more information read README.win32

The files are located on:

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a64 ready

2009-09-03T14:29:59Z

NEW features of cdrtools-2.01.01a64:

*******
NOTE: cdrtools is currently in a state just before a new major release.

*******

All:

- The schily makefilesystem now by default sets all locale related envronment
variables to "C" in order to avoid problems.

- Make the makefile emulation mode for "non-automake aware" make programs
like SunPro Make and GNU make more immune against oddities in the tr(1)
program that are seen with a locale that differs from LC_ALL=C
Another step to prevent some tr(1) oddities was to replace the call to
tr(1) by a call to sed(1).

- Added GMAKE_NOWARN=true to allow to disable the gmake warning

- Enhanced include/schily/priv.h to distinct Solaris and AIX process privileges

- New include file include/schily/math.h

- Try to workaound a problem with GCC on newer AIX versions. It seems that
e.g. gcc on AIX is not C99 compliant and does not support isnan().

Note that the current solution may compile and run on newer AIX versions
but does not seem to be the optimal solution as it cannot check whether
a float is a number or not.

It is unfortunate, that we do not have an AIX login that would allow
to implement better AIX support.

Libschily:

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

- The low level SCSI transport code for Mac OS X has been reworked.

The code now supports cdrecord -scanbus

The code now supports cdrecord's autotarget mode

The code now supports to communicate with BluRay drives

The code now prints a longer help text that instructs what to do in order
to work against the "diskarbitrationd" program on Mac OS that tries to
steal us our hardware.

If someone is able and willing to help, please send mail!

I like to be able to tell "diskarbitrationd" to give up specific drives
and to set up shared access.

Libscgcmd:

Libmdigest:

Rscsi:

Cdrecord:

- The cdrecord man page now mentions that the -clone mode is a bad idea to copy
audio CDs.

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Readcd:

- The readcd man page now mentions that the -clone mode is a bad idea to copy
audio CDs.

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

HELIOS TODO:

- Add the HELIOS UNICODE mapping code. This needs to be done
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

- Make the Apple extensions work again with "mkisofs -find"

TODO:
- Support correct inode numbers for UDF hardlinks

- Support sockets, pipes, char/blk-dev specials with UDF

- read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

- add libecc/edc for CDI and similar.

CYGWIN NT-4.0 NOTES:

To compile on Cygwin32, get Cygwin and install it.
For more information read README.win32

The files are located on:

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a62 ready

2009-07-30T03:13:20Z

NEW features of cdrtools-2.01.01a62:

*******
NOTE: cdrtools is currently in a state just before a new major release.

*******

All:

- New include files include/schily/ctype.h, include/schily/pwd.h
and include/schily/grp.h

- All programs are now using schily/stdio.h
for orthogonality.

- Haiku default install dir is now /boot/opt/schily

- New rules RULES/os-cygwin_nt-6.0-wow64.id and
RULES/os-cygwin_nt-6.1-wow64.id support Cygwin on 64bit
installations of Win Vista and "Win 7".

- New rules for compiling 64 Bit binaries on cygwin_nt-wow64
NOTE: You need to have a 64 bit aware gcc on Cygwin to use this!

- TEMPLATES/temp-gcc.rul and TEMPLATES/temp-xcc.rul
now correctly include cc-gcc.rul and cc-dumb.rul and thus
make the automake feature working again for completely
unknown platforms.

- Fixed RULES/rules.inc to make sure we install xx.h instead of
xx.h.exe

- Workaround an infinite hang in an autoconf test on 64 Bit Vista
with Cygwin

- Include limits.h in schily/hostname.h for Linux

- Several "%s" formats have been introduced in order to make gcc-4
happy even though the original strings have been pointer to constant
and well known strings

- Change the option order in the autoconf test for calling the linker
in order to avoid problems with the microsoft linker.

Libschily:

- libschily now is thread aware and uses the thread specific errno
value on Solaris, Linux and FreeBSD.

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

- Raised the SCSI Bus-number limit from 256 to 500 for Linux as a workaround
for a resource leak bug in the linux kernel. The workaround lets the problem
happen much later but cannot completely avoid it. If you are hit by the Linux
kernel resource leak bug, you need to reboot.

Libscgcmd:

Rscsi:

Cdrecord:

- Correctly abort the FIFO in cdrecord on BeOS and Haiku
in case that the clone ara cannot be made shared.

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Readcd:

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- Fixed a potential malloc problem in mkisofs

The files are located on:

ftp://ftp.berlios.de/pub/cdrecord/alpha ...

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a61 ready

2009-07-06T03:45:57Z

NEW features of cdrtools-2.01.01a61:

*******
NOTE: cdrtools is currently in a state just before a new major release.

*******

All:

- Support for 64 bit compilation on mac OS X was added.
Call make CCOM=cc64 as on other platforms.

- $OLIBSDIR is no longer in the RUNPATH

- New include file include/schily/limits.h

- Make sure that all include files in include/schily/ include
include/schily/mconfig.h

- wide character support new

- New makefile "Mocsw" sets defaults for "opencsw" instead of Blastwave.
Mcsw for Blastwave of course continues to exist

- New defaults directory DEFAULTS_CSW includes special defaults that
compile e.g. for Sparc-V8 in order to get working binaries for older
Sparc non 64 Bit hardware.

- New autoconf test HAVE_SETBUF and HAVE_SETVBUF

- Several modification in hope to better support MINGW

Libschily:

- wide character support new

- sevaral str*.c functions new for orthogonality with the new wcs* code.

- Added a wide character patern matcher with: patwcompile(), patwmatch(), patwlmatch()
See files:

libschily/matchw.c and libschily/matchwl.c

- libschily/stdio/*.c fixed to use size_t as length parameter for
read*()/write*() operations.

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

- Added a workaround for the type desaster in the Appls IOKit include files
in order to support 64 bit binaries

Libscgcmd:

Rscsi:

Cdrecord:

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

- The -interactive option is now mentioned in the -help output and the man page.

- Call unit_ready() before retrieving the TOC data in order to work around a Solaris
scsa2usb (SCSA to USB Driver) bug.

Readcd:

- "readcd" no longer dumps core if the C2Scan function is selected from the
interactive interface.

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- Fixed a typo bug in the mkisofs man page that caused the two synopsis lines
to appear as one line when using GNU troff.

- isoinfo now prints "???" in case that an illegal month is in a ISO-9660
filesystem.

HELIOS TODO:

- Add the HELIOS UNICODE mapping code. This needs to be done
at UCS-2 level for Joliet and UDF (instead of UTF-8) and only
for Rock Ridge (in case of a UTF-8 based target locale) using
UTF-8 based translations.

- Make the Apple extensions work again with "mkisofs -find"

TODO:
- Support correct inode numbers for UDF hardlinks

- Support sockets, pipes, char/blk-dev specials with UDF

- read Joliet filenames with multi-session if no TRANS.TBL
or RR is present. I am looking for a volunteer for this task!

Note that this can never be 100% correct as there is no relation
between the names on the master (UNIX) filesystem, the ISO-9660
names and the Joliet names. Only the Rock Ridge names are
untranslated with respect to the original files on the
master (UNIX) filesystem.

- add libecc/edc for CDI and similar.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

ftp site down, can't download cdrtools-2.01.01a60

2009-06-27T12:31:57Z

The requested operation could not be completed
Connection to Server Refused
Details of the Request:
URL: ftp://ftp.berlios.de/pub/cdrecord/alpha
Protocol: ftp
Date and Time: Saturday 27 June 2009 14:26
Additional Information: ftp.berlios.de: Timed out trying to connect to
remote host

will install a59 in the meantime copied to usb drive..

Thanks,

Antonio
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrtools-2.01.01a60 ready

2009-05-21T08:39:11Z

ftp://ftp.berlios.de/pub/cdrecord/alpha/

NEW features of cdrtools-2.01.01a60:

*******
NOTE: cdrtools is currently in a state just before a new major release.

*******

All:

- Trying to work around nasty Linux distributions that try to fool autoconf
function tests and thus may result in incorrect results for the functions
fexecl fexecle fexecv fexecve fspawnv fspawnl fspawnv_nowait getline fgetline

- New include files include/schily/dlfcn.h and include/schily/shcall.h

- New autoconf tests for dlopen() and similar functions

- Fixed a typo in include/schily/fnmatch.h that prevented compilation on BeOS

- Fixed a typo in include/schily/libport.h that prevented compilation on BeOS

- New makefile "Mocsw" allows to create packages for "opencsw"

- RULES/rules.csw enhanced to allow to overwrite EMAIL= and HOTLINE= from
the make command line.

- New autoconf test for getprogname()/setprogname()

- Support for using Microsoft "cl" to compile 64 bit binaries from Cygwin now
has been finished

Libschily:

- Code in libschily/fexec.c cleaned up for better readability

- libschily/checkerr.c now correctly handles the "WARN" directive.

Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphmont@...):

Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

Libcdrdeflt:

Libdeflt:

Libfind:

Libfile:

Libhfs_iso:

Libsiconv:

Libscg:

Libscgcmd:

Rscsi:

Cdrecord:

- Cdrecord now calls read_format_capacities() in silent mode in order to
check whether the current drive supports this SCSI command.

Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt heiko@...):

- cdda2wav now gives better readable text with cdda2wav -help

- BeOS has a /boot/develop/headers/be/support/ByteOrder.h that also defines
_BYTEORDER_H and thus interferes with our cdda2wav/byteorder.h

Readcd:

Scgcheck:

Scgskeleton:

Btcflash:

Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale):

- libschily/checkerr.c (used by mkisofs) now correctly handles the "WARN" directive.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord and 2.6.28.10 linux kernel hangs

2009-05-08T03:32:47Z

On Fri, 08 May 2009 10:31:43 +0200
Joerg.Schilling@... (Joerg Schilling) wrote:

> You may try to look into the kernel messages and other Linux
> kernel related resources to find indications for the
> problem and report it to the Linux kernel people.
> Did you report it?

Jörg,

There does not seem to be anything related in the log messages, but
this is expected given that the system cannot write to the disk
during the event. :(

I did not report it yet. I was hoping that someone else watching
the list can reproduce it on their machine. I do not know which
version of the kernel first showed the problem. It happened
somewhere between 2.6.20 and 2.6.28.10.

I note that in that 2.6.28.10 kernel configuration that
SCSI emulation support is now labeled as DEPRECATED and
it states:

"If both this SCSI emulation and native ATAPI support
are compiled into the kernel, the native support will
be used."

On both my kernels both these configuration options are selected,
but I do not pass any special kernel boot options (e.g., scsi
emulation setup) for the (ATA) DVD writer drive.

Mike

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord and 2.6.28.10 linux kernel hangs

2009-05-08T01:31:43Z

Michael Shell <list1@...> wrote:

> Sorry to report some bad news. Using cdrecord cdrtools-2.01.01a60pre2
> (which reports itself as Cdrecord-ProDVD-ProBD-Clone 2.01.01a59), I
> get a bad hang (I think the entire IDE bus hangs as no other applications
> seem to be able to do disk I/O) doing a simple -scanbus. I have a CDROM
> reader on a SCSI card and a PATA DVD writer as /dev/hdc.
>
> Under kernel 2.6.20 (this is an older AMD 32-bit i586 system) everything
> is just fine:
>
> [root]: cdrecord -scanbus
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a59 (i586-pc-linux-gnu) Copyright (C) 1995-2009 Jörg Schilling
> Linux sg driver version: 3.5.27
> Using libscg version 'schily-0.9'.
> scsibus0:
> 0,0,0 0) *
> 0,1,0 1) *
> 0,2,0 2) 'PLEXTOR ' 'CD-ROM PX-32TS ' '1.03' Removable CD-ROM
> 0,3,0 3) *
> 0,4,0 4) *
> 0,5,0 5) *
> 0,6,0 6) *
> 0,7,0 7) *
> scsibus1001:
> 1001,0,0 100100) '_NEC ' 'DVD_RW ND-4551A ' '1-09' Removable CD-ROM
> 1001,1,0 100101) *
> 1001,2,0 100102) *
> 1001,3,0 100103) *
> 1001,4,0 100104) *
> 1001,5,0 100105) *
> 1001,6,0 100106) *
> 1001,7,0 100107) *
> [root]:
>
>
> However, under the very latest 2.6.28.10 kernel, things go very wrong.
> The first scsibus scan prints, but the IDE bus seems to hang up hard
> when cdrecord scans scsibus1000. An error message "Too many
> CD/DVD/BD-recorder targets found" is reported before any devices are
> reported.

Thank you for the information!

You may try to look into the kernel messages and other Linux kernel related
resources to find indications for the problem and report it to the Linux kernel
people. Did you report it?

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrecord and 2.6.28.10 linux kernel hangs

2009-05-07T20:33:47Z

Jörg,

Sorry to report some bad news. Using cdrecord cdrtools-2.01.01a60pre2
(which reports itself as Cdrecord-ProDVD-ProBD-Clone 2.01.01a59), I
get a bad hang (I think the entire IDE bus hangs as no other applications
seem to be able to do disk I/O) doing a simple -scanbus. I have a CDROM
reader on a SCSI card and a PATA DVD writer as /dev/hdc.

Under kernel 2.6.20 (this is an older AMD 32-bit i586 system) everything
is just fine:

[root]: cdrecord -scanbus
Cdrecord-ProDVD-ProBD-Clone 2.01.01a59 (i586-pc-linux-gnu) Copyright (C) 1995-2009 Jörg Schilling
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.9'.
scsibus0:
0,0,0 0) *
0,1,0 1) *
0,2,0 2) 'PLEXTOR ' 'CD-ROM PX-32TS ' '1.03' Removable CD-ROM
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1001:
1001,0,0 100100) '_NEC ' 'DVD_RW ND-4551A ' '1-09' Removable CD-ROM
1001,1,0 100101) *
1001,2,0 100102) *
1001,3,0 100103) *
1001,4,0 100104) *
1001,5,0 100105) *
1001,6,0 100106) *
1001,7,0 100107) *
[root]:

However, under the very latest 2.6.28.10 kernel, things go very wrong.
The first scsibus scan prints, but the IDE bus seems to hang up hard
when cdrecord scans scsibus1000. An error message "Too many
CD/DVD/BD-recorder targets found" is reported before any devices are
reported.

The last thing reported is something like:

scsibus1000:
1000,0,0 100000)*

and after that I can't kill cdrecord with ctl-C or even do a ps in
another shell as that process hangs too. :(

This behavior probably indicates a kernel problem because even if
cdrecord were at fault, the whole IDE bus should not hang like that.

Anyway, I thought I'd warn you about it in case more people
encounter it.

Mike Shell

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

cdrecord and DOS

2009-04-26T17:38:08Z

I wrote on my message of 21 April 2009:

>> >What is the output of the cdrecord -scanbus run?
>>
>> Exactly as below:
>>
>> Cdrecord-ProDVD-ProBD-Clone 2.01.01a51 (i686-pc-msdos)
>> Copyright (C) 1995-2008 Jörg Schilling
>> Using libscg version 'schily-0.9'.
>> scsibus0:
>> 0,0,0 0) '' '' '' NON CCS Disk
>> 0,1,0 1) *
>> 0,2,0 2) *
>> 0,3,0 3) *
>> 0,4,0 4) *
>> 0,5,0 5) *
>> 0,6,0 6) *
>> 0,7,0 7) *

You replied

>Looks like you have a non-working ASPI on your system.
>Please try to call:
> cdrecord dev=0,0,0 -inq
>and report the results from cdrecord.

They are as follows:

Cdrecord-ProDVD-ProBD-Clone 2.01.01a51 (i686-pc-msdos)
Copyright (C) 1998-2005 J"rg Schilling
scsidev; '0,0,0'
scsibus: 0 target: 0 lun: 0
Using libscg version 'schily-0.9'
cdrecord.exe: Cannot do inquiry for CD/DVD/BD-Recorder
cdrecord.exe: No Error. test unit ready: scsisendcmd:
cmd timeout after 39.980 (40)s
CDB: 00 00 00 00 00 00
cmd finished after 39.980s timeout 40s

Another question you asked:

>Do you really like to _compile_ _on_ DOS?

Well, I would rather not compile at all; I need
a program to write CDs under plain DOS. If I
can find it ready to use, so much the better.

Regards
JAS

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord and DOS

2009-04-22T03:46:26Z

"jassenna\@itelefonica\.com\.br" <jassenna@...> wrote:

> Jörg Schilling wrote:
>
> >What is the output of the cdrecord -scanbus run?
>
> Exactly as below:
>
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a51 (i686-pc-msdos)
> Copyright (C) 1995-2008 Jörg Schilling
> Using libscg version 'schily-0.9'.
> scsibus0:
> 0,0,0 0) '' '' '' NON CCS Disk
> 0,1,0 1) *
> 0,2,0 2) *
> 0,3,0 3) *
> 0,4,0 4) *
> 0,5,0 5) *
> 0,6,0 6) *
> 0,7,0 7) *

Looks like you have a non-working ASPI on your system.

libscg tries to load ASPI and prints an error message in case that it cannot
load ASPI.

libscg and cdrecord take care that error conditions that are reported by ASPI
result in an error message.

Please try to call:

cdrecord dev=0,0,0 -inq

and report the results from cdrecord.

> >Another problem is the short filenames that are at a level of the
> >1960s. You have to compile on Win9x or WinNt for this reason.
>
> You mean the source files have only long names ?

The cdrtools source uses the filename conventions that are in avialable
since 28 years. It seems to make no sense to put efforts in artificially
shortening file names because this reduces readability.

Do you really like to _compile_ _on_ DOS?

BTW: The last time, I needed to hack a source/makefile system to deal with
short file names and short identifiers was in 1987, this is more than 20 years
ago.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord and DOS

2009-04-21T19:09:18Z

Jörg Schilling wrote:

>What is the output of the cdrecord -scanbus run?

Exactly as below:

Cdrecord-ProDVD-ProBD-Clone 2.01.01a51 (i686-pc-msdos)
Copyright (C) 1995-2008 Jörg Schilling
Using libscg version 'schily-0.9'.
scsibus0:
0,0,0 0) '' '' '' NON CCS Disk
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *

>> BTW, I can open SCSIMGR$ with this function.

>It may be that this is what ASPI does....

No, SCSIMGR$ is ASPI.SYS resident part.

>Another problem is the short filenames that are at a level of the
>1960s. You have to compile on Win9x or WinNt for this reason.

You mean the source files have only long names ?

JAS

_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord truncates .wav file

2009-04-21T14:14:08Z

Joanie Abalone <pfenerty@...> wrote:

> the problem that i see is that cdrecord -pad successfully pads a file that it
> thinks is of length 79499220.
>
> but the file is actually much larger:
>
> -rw-rw-r-- 1 pf pf 127866524 Apr 21 10:16 hayes_walkonby_latest.wav
>
> i have no idea what process decided that the file size is 79499220, or why
> that process consistently gets only this one filesize wrong, among hundreds
> (thousands?) of files handled correctly ... only that cdrecord complains
> about it.
>
> however, it's probably quite telling that cdrecord correctly writes out the
> entire file when /usr/bin/normalize is not invoked.

Well, then it looks like some program was called that introduced a bad *.WAV
header to that file. Cdrecord reads the WAV header and uses the size that is in
the WAV header unless the file is actually shorter than announced by the WAV
header.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord truncates .wav file

2009-04-21T13:46:52Z

the problem that i see is that cdrecord -pad successfully pads a file that it thinks is of length 79499220.

but the file is actually much larger:

-rw-rw-r-- 1 pf pf 127866524 Apr 21 10:16 hayes_walkonby_latest.wav

i have no idea what process decided that the file size is 79499220, or why that process consistently gets only this one filesize wrong, among hundreds (thousands?) of files handled correctly ... only that cdrecord complains about it.

however, it's probably quite telling that cdrecord correctly writes out the entire file when /usr/bin/normalize is not invoked.

thanks one last time ... i'm out

Joerg Schilling-3 wrote:

Joanie Abalone <pfenerty@earthlink.net> wrote:

> /usr/bin/cdrecord: Bad audio track size 79499220 for track 04.
> /usr/bin/cdrecord: Audio tracks must be at least 705600 bytes and a multiple
> of 2352.
> /usr/bin/cdrecord: See -pad option.

The problem is that you used a program that changed the length of track 4 to a
value that is not a multiple of 2352.

If you follow the advise from cdrecord and use the -pad option, cdrecord will
fill up the missing 732 bytes with null bytes at the end of the track.

Jörg

--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/cdrecord-support

Re: cdrecord truncates .wav file

2009-04-21T12:24:14Z

Joanie Abalone <pfenerty@...> wrote:

>
> thanks for all of your replies, and of course, for all of your efforts
> regarding the cdrtools package itself. i am a big fan.
>
> the latest:
>
> 1) updated cdrecord & cdda2wav (also mkisofs, etc)
> 2) re-ripped the track ('Walk On By') from the 2005 (remastered) source CD
> (ASIN: B000BBOVGC).
> 3) problem persists
>
> =================
>
> [pf@gezora cdrtools-2.01.01]$ /usr/bin/cdrecord -version
> Cdrecord-ProDVD-ProBD-Clone 2.01.01a59 (i686-pc-linux-gnu) Copyright (C)
> 1995-2009 J???rg Schilling
>
> [pf@gezora cdrtools-2.01.01]$ /usr/bin/cdda2wav -version
> cdda2wav 2.01.01a59 (i686-pc-linux-gnu) Copyright (C) 1993-2004 Heiko
> Ei???feldt (C) 2004-2009 J???rg Schilling
>
> =================
>
>
> ... excerpts from k3b logfile:
>
> Used versions
> -----------------------
> cdrecord: 2.1.1a59
>
> /usr/bin/cdrecord: Bad audio track size 79499220 for track 04.
> /usr/bin/cdrecord: Audio tracks must be at least 705600 bytes and a multiple
> of 2352.
> /usr/bin/cdrecord: See -pad option.

The problem is that you used a program that changed the length of track 4 to a
value that is not a multiple of 2352.

If you follow the advise from cdrecord and use the -pad option, cdrecord will
fill up the missing 732 bytes with null bytes at the end of the track.

Jörg

--
EMail:joerg@... (home) Jörg Schilling D-13353 Berlin
js@... (uni)
joerg.schilling@... (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
Cdrecord-support mailing list
Cdrecord-support@...
https://lists.berlios.de/mailman/listinfo/cdrecord-support