cdrtools-support — Cdrtools user support

[Cdrtools-support] Cdrtools-3.02a01 was published

[Joerg S. <Joe...@fo...>]

See: https://sourceforge.net/projects/cdrtools/files/alpha/

Please note that due to the fact that this release mainly enhances portability, 
adds a bugfix for libparanoia and ointroduced better sound output support, 
there is a plan to make the test phase short and create a 3.02-final soon.

***************** Please Test *********************************

NEW features of cdrtools-3.02a01:

This is the first localization step for cdrtools. All programs now (hopefully)
call gettext() for all strings that need localization.

-	The next step will include dgettext() calls for the libraries.

-	The following step will include the extracted strings

-	The last step will include German translations and install support
	for the resulting binary message object files.

----------> Please test and report compilation problems! <---------

***** NOTE: As mentioned since 2004, frontends to cdrtools should *****
*****		call all programs from cdrtools in the "C" locale *****
*****		by e.g. calling: LC_ALL=C cdrecord ....		  *****
*****		unless these frontends support localized strings  *****
*****		used by the cdrtools with NLS support.		  *****

This version compiles on Win-DOS using the Microsoft compiler cl.exe but
warning: due to missing POSIX compliance with basic features (e.g. stat()
does not return inode numbers), there are many problems with the resulting
code and thus it is recommended to better use a POSIX layer on top of 
WIN-DOS.

		*** WARNING        ***
		*** Need new smake ***

	*** Due to the fact that schily-2014-04-03 introduced to use new macro
	*** expansions and a related bug fix in smake, you need a new smake
	*** to compile this source. To ensure this, get a recent "schily"
	*** tarball from http://sourceforge.net/projects/schilytools/files/
	*** and call:

	cd ./psmake
	./MAKE-all
	cd ..
	psmake/smake
	psmake/smake install

	The new smake version mentioned above is smake-1.2.4.
	Note that smake-1.2.5 exists and is preferrable.

	Now you have a new smake that is able to compile this source.

	Note that the major makefile restructuring introduced in
	schily-2014-04-03 is now more than one month ago and thus seems
	to work without problems.

	WARNING: the new version of the isoinfo program makes use of the 
		*at() series of functions that have been introduced by Sun
		in August 2001 and added to POSIX.1-2008. For older platforms,
		libschily now includes emulations for these functions but
		these emulations have not yet been tested thoroughly.
		Please report problems!


All:

-	As the defective typedef for idtype_t is already in NetBSD-5,
	we added a workaround based on a new related autoconf test.

-	Added support to compile on "Bitrig", an OpenBSD fork for non
	automake aware make implementations like gmake.

-	Added an autoconf test for tcgetsid()

Libschily:

Libcdrdeflt:

Libdeflt:

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

Libfile:

Libfind:

-	libfind: a final workaround for the problems with vfork() in the linux
	system include files has been introduced and a variable has been declared
	volatile.

-	libfind no longer uses gettext() but dgettext() and thus no longer
	destroys the message binding from the Bourne Shell

-	libfind: find -mtime +2s -mtime +20s now works, as file timestamps
	are now compared to the current time. Before, the current time +60s
	was used - a timestamp that is needed for switching between both 
	time stamp variants for -ls.

Libhfs_iso:

Libmdigest:

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

-	libparanoia: Make abs() a self defined macro as ISO-C defines abs()
	to be a function with int parameter.

-	libparanoia: work around a bug that resulted from uninitalized 
	statistics data for C2 checks in case that C2 checking was disabled.

Libscg:

-	libscg: added a new error code to make search for the right
	device node work again with newer OpenBSD versions.

Libscgcmd:

Libsiconv:

Rscsi:

Cdrecord:

-	The man page now mentions that root-less operation is possible with
	Solaris fine grained privileges or Linux capabilties.

-	The man page now mentions the SCSI CAM standard for dev=

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

-	cdda2wav: Comparison of function name with NULL replaced with
	comparison of function pointer with NULL.

-	cdda2wav: Do no longer initialize the sound card from the main process
	as pulseaudio does not follow UNIX rules for forked processes.

-	cdda2wav: Fixed a bug in the DMA residual computation for the C2 read
	functions where a wrong divisor (2353 instead of 2646) was used.

-	cdda2wav: Heiko tried to make audio output work on OpenBSD

-	cdda2wav: Heiko added code for pulseaudio support in Linux

-	cdda2wav: Fixed a typo ("KHz" -> "kHz")

-	cdda2wav: fixed a problem related to position differences between
	the CD extract part and the filesystemwrite part.

-	cdda2wav: We now include "c2check" in the paranoia mode "proof"
	again and fallback to a non-C2 mode in case the drive does not
	support C2checks.

-	The man page now mentions the SCSI CAM standard for dev=

Readcd:

-	The man page now mentions the SCSI CAM standard for dev=

Scgcheck:

Scgskeleton:

Btcflash:

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

-	mkisofs: HFS creation: fixed comparison of array with 0 to become
	comparison of array value with 0.

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:

	-	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:

http://sourceforge.net/projects/cdrtools/files/alpha/ ...

NOTE:	These tar archives are 100% POSIX compatible. GNU tar may get some
	minor trouble. If you like a 100% POSIX compliant tar, get star from
	http://sourceforge.net/projects/s-tar/files/ of from the schily-*
	tarball at: http://sourceforge.net/projects/schilytools/files/

WARNING: Do not use 'winzip' to extract the tar file!
	Winzip cannot extract symbolic links correctly.

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/'

Re: [Cdrtools-support] recommended path to compile on ARM

[Erik K. <eri...@gm...>]

Sorry for not responding for some time, but the system had multiple
hardware issues and was therefore replaced. I could set it up and start my
test earliest yesterday.

I ran a test compile last night and can report back that a simple "make" in
the "schily-dist" directory was enough to generate binaries.

After "make" worked, I tried "sudo make install", and after that didn't
work, I read "INSTALL", copied "smake" by hand to "/usr/local/bin", and ran
"sudo smake install", which finished everything without problems.

So, false alarm. There were transient hardware issues which influenced the
outcome.

Thanks for your help!
Erik

Joerg Schilling <Joe...@fo...> schrieb am Mo., 26.
Okt. 2015 um 14:12 Uhr:

> Erik Koennecke <eri...@gm...> wrote:
>
> > Thanks for the link and the explanation. I have already tried this, but
> > unsuccessful. Meanwhile, I suspect that a hardware issue could also be
> > responsible, but it's good that you confirmed that it *can* be done on a
> > Raspberry.
>
> What problems do you have?
>
> Do you have a compiler on the system?
>
> 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/'
>

Re: [Cdrtools-support] cdda2wav only finds errors

[Volker K. <lis...@pa...>]

On Tue 27 Oct 2015 03:41:13 NZDT +1300, Joerg Schilling wrote:

> This is a preliminary (alpha) release, do the version.h file was not edited.

So when I tell you I've tested with version "3.01", because that's what
it tells me, you know exactly which of the heap of varieties I'm talking
about? Fine by me, you're the expert of your software...


Here's the drive list.

I use output like this as a measure that your fix is working:
100%  track 15  recorded successfully
100%  track 17  recorded with minor problems
100%  track 19  recorded with minor problems (0.2% problem sectors)
100%  track  8  recorded with audible hard errors

The bad version only outputs lines like this:
100%  track 13  recorded with audible hard errors

No drives with bad output found. These drives produce good output:

Lite-on, fresh from the shop
Type: ROM, Vendor 'ATAPI   ' Model 'iHAS124   F     ' Revision 'CL07' MMC+CDDA

Stoneage CD-RW:
Type: ROM, Vendor 'HP      ' Model 'CD-Writer+ 8100 ' Revision '1.0g' MMC+CDDA

LG, appr 5y old:
Type: ROM, Vendor 'HL-DT-ST' Model 'DVDRAM GH22LS50 ' Revision 'TL03' MMC+CDDA

Laptop drive, appr 4-5y old
Type: ROM, Vendor 'MATSHITA' Model 'DVD+-RW UJ8B1   ' Revision 'D.04' MMC+CDDA

Old Sony/NEC/Optiarc CD-RW:
Type: ROM, Vendor 'Optiarc ' Model 'DVD RW AD-7200S ' Revision '1.R1' MMC+CDDA

I have these to test as well but would need to re-arrange hardware. It's
not much point because it's clear it's working again.
Type: ROM, Vendor 'CDWRITER' Model 'IDE5232         ' Revision '000R' MMC+CDDA
Type: ROM, Vendor 'PIONEER ' Model 'DVD-RW  DVR-106D' Revision '1.08' MMC+CDDA

I'm not totally sure but occasionally I had the feeling the 3.01 has a
slightly lower final read error rate.

Thanks muchly for improvement!

Volker

-- 
Volker Kuhlmann
http://volker.top.geek.nz/	Please do not CC list postings to me.

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

Volker Kuhlmann <lis...@pa...> wrote:

> On Wed 21 Oct 2015 22:29:40 NZDT +1300, Joerg Schilling wrote:
>
> > > Thanks for letting me know. There appears to be no more traffic there
> > > than here, but hey. When SF gets round to processing subscriptions.
> > 
> > Are there problems?
> > Which ones?
>
> Yes. I tried to subscribe. No reaction from the list server. Not what I
> was expecting from SF. Does the list require moderator approval for
> subscriptions?

OK, I just did a test with "joe user" and there is no problem. It took less 
than a minute to get a first mail as a result from the clicking on the web form 
and after I replied to that mail, it took 30 minutes to get the final 
confirmation mail that confirmed the new membership.

You should check your mailer whether it might have blocked the first mail or 
whether the reply was not returned to SF.

> > Is it hard to understand that the file listed as most recent file on that 
> > download page is the right one?
>
> Yes, the most recent files listed is
>   Looking for the latest version? Download scg-i386-sol9 (19.5 kB)
> I save myself the trouble with solaris 9.

Could you explain how you could believe that?

Regardless of where your current directory is in the download area, it lists

	schily-dist-pre3.tar.xz

as the most recent file

>
> If I may say so, I do not find it intelligent that dozens of different
> source archives all produce a tool with -version cdda2wav 3.01. I'm
> expecting it to report itself as 3.01-schily-dist-pre3 if it came fom
> there.

This is a preliminary (alpha) release, do the version.h file was not edited.

> > If you read the public information, you should know that "schily tools" is just 
> > a frequently updated snapshot of all sources - not only cdrtools.
>
> http://sourceforge.net/projects/schilytools/files/
> Schily Tools
> A Tool Box with tools written or managed by Jörg Schilling
> Brought to you by: schily
>
> As you see, you see nothing of that sort.

It say:

	README cannot be displayed here, do you want to download it?

> Still testing, but looking good so far. I'll give you a drive list.

OK



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/'

Re: [Cdrtools-support] recommended path to compile on ARM

[Joerg S. <Joe...@fo...>]

Erik Koennecke <eri...@gm...> wrote:

> Thanks for the link and the explanation. I have already tried this, but
> unsuccessful. Meanwhile, I suspect that a hardware issue could also be
> responsible, but it's good that you confirmed that it *can* be done on a
> Raspberry.

What problems do you have?

Do you have a compiler on the system?

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/'

Re: [Cdrtools-support] recommended path to compile on ARM

[Erik K. <eri...@gm...>]

Thanks for the link and the explanation. I have already tried this, but
unsuccessful. Meanwhile, I suspect that a hardware issue could also be
responsible, but it's good that you confirmed that it *can* be done on a
Raspberry.

Joerg Schilling <Joe...@fo...> schrieb am Mo., 26.
Okt. 2015 um 13:03 Uhr:

> Joerg Schilling <Joe...@fo...> wrote:
>
> > Erik Koennecke <eri...@gm...> wrote:
> >
> > > What's the recommended way to bootstrap a compile of Schily tools or
> more
> > > specific, cdda2wav, on ARM architecture (Raspberry Pi 2)?
> > >
> > > Ideally, I would like to get rid of the debian crap and replace with
> your
> > > versions where applicable.
> > >
> > > My initial attempts were met with segmentation faults on the device.
> >
> > If you do not use the "cdrtools" tarball but the "schilytools" tarball,
>
> Sorry, I forgot to mention the download location:
>
> http://sourceforge.net/projects/schilytools/files/
>
> Check for the schily-*.tar.bz2 archives.
>
> The most recent "schily-dist-pre3" contains some imortant cdda2wav
> bugfixes.
>
> 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/'
>

Re: [Cdrtools-support] recommended path to compile on ARM

[Joerg S. <Joe...@fo...>]

Joerg Schilling <Joe...@fo...> wrote:

> Erik Koennecke <eri...@gm...> wrote:
>
> > What's the recommended way to bootstrap a compile of Schily tools or more
> > specific, cdda2wav, on ARM architecture (Raspberry Pi 2)?
> >
> > Ideally, I would like to get rid of the debian crap and replace with your
> > versions where applicable.
> >
> > My initial attempts were met with segmentation faults on the device.
>
> If you do not use the "cdrtools" tarball but the "schilytools" tarball,

Sorry, I forgot to mention the download location:

http://sourceforge.net/projects/schilytools/files/

Check for the schily-*.tar.bz2 archives.

The most recent "schily-dist-pre3" contains some imortant cdda2wav bugfixes.

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/'

Re: [Cdrtools-support] recommended path to compile on ARM

[Joerg S. <Joe...@fo...>]

Erik Koennecke <eri...@gm...> wrote:

> What's the recommended way to bootstrap a compile of Schily tools or more
> specific, cdda2wav, on ARM architecture (Raspberry Pi 2)?
>
> Ideally, I would like to get rid of the debian crap and replace with your
> versions where applicable.
>
> My initial attempts were met with segmentation faults on the device.

If you do not use the "cdrtools" tarball but the "schilytools" tarball,
you get more than just cdrtools and this inlcudes e.g. "smake" and a bootstrap 
environment to automatically compile everythig even when you do not have a make 
program at all.

See the file BOOTSTRAP.

If you have a make program, just call "make" and this will cause the boostrap 
smake to be made using a shell script  and then the rest ujsing the boostrap 
smake. If you like to do things manually,

chdir to "psmake"
Call "./MAKE-all"
chdir ..
call psmake/smake

Everything works automatically unless something bad happened - I did the last 
test on a Raspberry early this year.

IIRC, compile time is aprox. 20 minutes.

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/'

Re: [Cdrtools-support] recommended path to compile on ARM

[Erik K. <eri...@gm...>]

What's the recommended way to bootstrap a compile of Schily tools or more
specific, cdda2wav, on ARM architecture (Raspberry Pi 2)?

Ideally, I would like to get rid of the debian crap and replace with your
versions where applicable.

My initial attempts were met with segmentation faults on the device.

Re: [Cdrtools-support] cdda2wav only finds errors

[Volker K. <lis...@pa...>]

On Wed 21 Oct 2015 22:29:40 NZDT +1300, Joerg Schilling wrote:

> > Thanks for letting me know. There appears to be no more traffic there
> > than here, but hey. When SF gets round to processing subscriptions.
> 
> Are there problems?
> Which ones?

Yes. I tried to subscribe. No reaction from the list server. Not what I
was expecting from SF. Does the list require moderator approval for
subscriptions?

> Is it hard to understand that the file listed as most recent file on that 
> download page is the right one?

Yes, the most recent files listed is
  Looking for the latest version? Download scg-i386-sol9 (19.5 kB)
I save myself the trouble with solaris 9.

The rest of the files are named schily-* and neither the file name nor
the project description (tool box) tell me it's cdrecord.

I assume you meant schily-dist-pre3.tar.xz

If I may say so, I do not find it intelligent that dozens of different
source archives all produce a tool with -version cdda2wav 3.01. I'm
expecting it to report itself as 3.01-schily-dist-pre3 if it came fom
there.

> If you read the public information, you should know that "schily tools" is just 
> a frequently updated snapshot of all sources - not only cdrtools.

http://sourceforge.net/projects/schilytools/files/
Schily Tools
A Tool Box with tools written or managed by Jörg Schilling
Brought to you by: schily

As you see, you see nothing of that sort.


> are you satisfied with the recent changes?

Still testing, but looking good so far. I'll give you a drive list.

Thanks muchly,

Volker

-- 
Volker Kuhlmann
http://volker.top.geek.nz/	Please do not CC list postings to me.

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

grarpamp <gra...@gm...> wrote:

> > If you are interested in dsicussing aspects of a better version control system,
> > you are highly welcome!
>
> And highly unqualified :) I think people try to consolidate to git to
> have greater interop with the rest of the internet projects, might
> not be the best for all things but it is where people are today.
> Locally and at work we use whatever we like, is best suited, or is
> handed to us from legacy. This one has some interesting features...
> http://monotone.ca/

Sometimes it helps to look at things in the unexpected way.

I need people who tell me what might be bad in the current SCCS plans before 
things cannot be changed anymore without creatring problems.

> >
> > OK, I thought you have the older archives in mind, e.g. Debian or BerliOS.
>
> Yes, those older ones should also be collected to include in
> the downloadable MUA seed tarball.

Berlios mailing list may be lost, I could not find a mail archive mirror for 
berlios.

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/'

Re: [Cdrtools-support] cdda2wav only finds errors

[grarpamp <gra...@gm...>]

On Fri, Oct 23, 2015 at 9:43 AM, Joerg Schilling
<Joe...@fo...> wrote:
> Well, there are of course ways to do this. I just thought that someone might
> have written a script. I did e.g. write a script to convert RCS to SCCS.

Which is often easier than time spent validating someone elses.

> http://sccs.sourceforge.net/sccs_vs_rcs.html

You may like to include these types of notes files in a
docs dir in the tarballs, if they are not already included.

> just seems the right time to start with SCCS again.

It's good that people continue to develop things even
though they may not make it to the top, if nothing else
for the science.

> So it took me until December 2006 and negotiations with Sun to make SCCS
> OpenSource.

Corporations are difficult unfortunately.

> If you are interested in dsicussing aspects of a better version control system,
> you are highly welcome!

And highly unqualified :) I think people try to consolidate to git to
have greater interop with the rest of the internet projects, might
not be the best for all things but it is where people are today.
Locally and at work we use whatever we like, is best suited, or is
handed to us from legacy. This one has some interesting features...
http://monotone.ca/


>> http://sourceforge.net/projects/msmtp/files/msmtp/msmtp-users/
>
> OK, I thought you have the older archives in mind, e.g. Debian or BerliOS.

Yes, those older ones should also be collected to include in
the downloadable MUA seed tarball.

> Vor SF, there is an interface for the archives at e.g.
> https://sourceforge.net/p/cdrtools/mailman/cdrtools-support/
> https://lists.sourceforge.net/lists/listinfo/cdrtools-support

AFAIK, those are "web only" html rendered archives, there
does not seem to be any interface where the reader can
download for their MUA a mbox compatible original copy,
or even an mbox compatible redacted one, or text one.

Here is an example of a list that offers
- web only html rendered monthlies
- mbox compatible redacted monthlies
- the entire history in one unredacted mbox compatible file
https://cpunks.org/pipermail/cypherpunks/

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

grarpamp <gra...@gm...> wrote:

> On Wed, Oct 21, 2015 at 6:35 AM, Joerg Schilling
> <Joe...@fo...> wrote:
> >> https://www.google.com/search?q=sccs+to+git
> >
> > Did you find a working script this way?
> > I just see talks without code and links that point nowhere.
>
> Maybe sccs is old enough that, having moved on long ago
> (if they were going to move at all), folks aren't writing / maintaining
> scripts for that anymore, lost to history. Wouldn't be too hard to
> interate each commit, message and timestamp into the filesystem
> and then load that into any other repo, the original timestamps might
> become comments, or bump the clock. Perhaps try going to one
> of the historical intermediates in the same lineage first...
>
> https://www.google.com/search?q=sccs+to+cssc
> https://www.google.com/search?q=sccs+to+rcs
> https://www.google.com/search?q=sccs+to+cvs
> https://www.google.com/search?q=sccs+to+svn

Well, there are of course ways to do this. I just thought that someone might 
have written a script. I did e.g. write a script to convert RCS to SCCS.

BTW: Your search strings helped me to discover that my RCS vs. SCCS text now 
made it to the top of the Google search results:

http://sccs.sourceforge.net/sccs_vs_rcs.html

So it now seems to be easier not to find the unproven claim that RCS is 
supposed to be faster than SCCS.

Regarding CSSC: this could have been a solution in the 1990s but this project 
did never reached a state that makes it a real SCCS replacement. It 
artificially limits the number of deltas to 30000 and is aprox. 30x slower than 
SCCS. 

> Those that know unix know that ;)
>
> > Check e.g. "NSE", "TeamWare" and "KitKeeper".
>
> Which, fortunate or not, are all forgotten by the open
> source community likely due to licenses and lack of
> maintenance and public userbase.

NEW was the base for TeamWare and Teamware was in use by Sun, HP, IBM, AT&T, 
Xerox,.... for development of CDE.

BitKeeper has been developed by one of the co-developers of TeamWare after he 
left Sun.

Thanks to Glenn Skinner, one of the TeamWare project leaders, I know that the 
idea "smoosh" was patented but the patent did time out a year ago. So It now 
just seems the right time to start with SCCS again.

I am sorry that this took too much time, but I did make a negitioation with SCO 
to make SCCS OpenSource in 2001, but then the Linux Company "Caldera Linux" 
bought SCO and there was no interest in OpenSource anymore 2 weeks before the 
source code should have been handed out.

So it took me until December 2006 and negotiations with Sun to make SCCS 
OpenSource.

> > The advantage of SCCS is the history file format that allows a lot of features
> > and that gives the best performance.
> >
> > http://schillix.sourceforge.net/man/man4/sccschangeset.4.html
> > http://schillix.sourceforge.net/man/man4/sccsfile.4.html
>
> There are a lot of good in many things to continue to advocate
> and integrate and deploy, and a lot of market share and good
> stuff in things that users are using today.

If you are interested in dsicussing aspects of a better version control system, 
you are highly welcome!

> > If you know a way to retrieve this, please send the archive.
>
> AFAIK, only the admin of a SF project list can do that somehow,
> see example below. And all the old list homes are dead, so
> you would have the archives to be able to publish them as well.
>
> http://sourceforge.net/projects/msmtp/files/msmtp/msmtp-users/

OK, I thought you have the older archives in mind, e.g. Debian or BerliOS.

Vor SF, there is an interface for the archives at e.g.

https://sourceforge.net/p/cdrtools/mailman/cdrtools-support/

see: https://lists.sourceforge.net/lists/listinfo/cdrtools-support


> > are you satisfied with the recent changes?
>
> cdrtools never let me down yet, and star helped a lot on some
> projects :)

OK, I am still in hope to get feedback from Volker as well.

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/'

Re: [Cdrtools-support] cdda2wav only finds errors

[grarpamp <gra...@gm...>]

On Wed, Oct 21, 2015 at 6:35 AM, Joerg Schilling
<Joe...@fo...> wrote:
>> https://www.google.com/search?q=sccs+to+git
>
> Did you find a working script this way?
> I just see talks without code and links that point nowhere.

Maybe sccs is old enough that, having moved on long ago
(if they were going to move at all), folks aren't writing / maintaining
scripts for that anymore, lost to history. Wouldn't be too hard to
interate each commit, message and timestamp into the filesystem
and then load that into any other repo, the original timestamps might
become comments, or bump the clock. Perhaps try going to one
of the historical intermediates in the same lineage first...

https://www.google.com/search?q=sccs+to+cssc
https://www.google.com/search?q=sccs+to+rcs
https://www.google.com/search?q=sccs+to+cvs
https://www.google.com/search?q=sccs+to+svn

> I am not sure whether you know that all modern version control systems are
> based on the ideas of SCCS

Those that know unix know that ;)

> Check e.g. "NSE", "TeamWare" and "KitKeeper".

Which, fortunate or not, are all forgotten by the open
source community likely due to licenses and lack of
maintenance and public userbase.

> The advantage of SCCS is the history file format that allows a lot of features
> and that gives the best performance.
>
> http://schillix.sourceforge.net/man/man4/sccschangeset.4.html
> http://schillix.sourceforge.net/man/man4/sccsfile.4.html

There are a lot of good in many things to continue to advocate
and integrate and deploy, and a lot of market share and good
stuff in things that users are using today.

>> A tarball containing a collated mbox or maildir archive of all the
>> messages to the various cdrtools lists since inception.
>
> If you know a way to retrieve this, please send the archive.

AFAIK, only the admin of a SF project list can do that somehow,
see example below. And all the old list homes are dead, so
you would have the archives to be able to publish them as well.

http://sourceforge.net/projects/msmtp/files/msmtp/msmtp-users/

> are you satisfied with the recent changes?

cdrtools never let me down yet, and star helped a lot on some
projects :)

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

Volker Kuhlmann <lis...@pa...> wrote:

> I can do some testing on various drives, however please point to exact

Hi,

are you satisfied with the recent changes?

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/'

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

grarpamp <gra...@gm...> wrote:

> On Wed, Oct 21, 2015 at 5:12 AM, Joerg Schilling
> <Joe...@fo...> wrote:
> > Well, GIT would loss meta data and I suspect there is no code to convert SCCS
> > into GIT.
>
> Farthest I did were RCS ages ago.
> Other people have done from SCCS...
>
> https://www.google.com/search?q=sccs+to+git

Did you find a working script this way?
I just see talks without code and links that point nowhere.

> > The good news is that SCCS is already close to the planned v6 release and
> > Sourceforge signalled to integrate support for SCCS once it is ready.
>
> The not so bad news is that the open source world has largely
> moved on to distributed systems, mostly represented by git.
> Putting a hoop that todays generation has never used or heard
> of in front of a project likely won't help bring people to it.
> I like old hoops too, but only for private use.

I am not sure whether you know that all modern version control systems are 
based on the ideas of SCCS and that a frontend to SCCS was the first 
distributed system at all.

Check e.g. "NSE", "TeamWare" and "KitKeeper".

All modern systems more or less even copied the BitKeeper Command line 
interface.

The advantage of SCCS is the history file format that allows a lot of features 
and that gives the best performance.

Please read http://schillix.sourceforge.net/man/man4/sccschangeset.4.html
and
http://schillix.sourceforge.net/man/man4/sccsfile.4.html

> > A tarball from what mail archive?
>
> A tarball containing a collated mbox or maildir archive of all the
> messages to the various cdrtools lists since inception.

If you know a way to retrieve this, please send the archive.

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/'

Re: [Cdrtools-support] cdda2wav only finds errors

[grarpamp <gra...@gm...>]

On Wed, Oct 21, 2015 at 5:12 AM, Joerg Schilling
<Joe...@fo...> wrote:
> Well, GIT would loss meta data and I suspect there is no code to convert SCCS
> into GIT.

Farthest I did were RCS ages ago.
Other people have done from SCCS...

https://www.google.com/search?q=sccs+to+git

> The good news is that SCCS is already close to the planned v6 release and
> Sourceforge signalled to integrate support for SCCS once it is ready.

The not so bad news is that the open source world has largely
moved on to distributed systems, mostly represented by git.
Putting a hoop that todays generation has never used or heard
of in front of a project likely won't help bring people to it.
I like old hoops too, but only for private use.

> A tarball from what mail archive?

A tarball containing a collated mbox or maildir archive of all the
messages to the various cdrtools lists since inception.

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

Volker Kuhlmann <lis...@pa...> wrote:

> On Tue 20 Oct 2015 23:11:14 NZDT +1300, Joerg Schilling wrote:
>
> > please do not use cd...@ot... anymore, there is nobody really 
> > listening and the only traffic seems to be spam since Debian attacked cdrtools.
> > 
> > Please rather use cdr...@li...,
>
> Thanks for letting me know. There appears to be no more traffic there
> than here, but hey. When SF gets round to processing subscriptions.

Are there problems?
Which ones?

> > There was a problem with an uninitalized variable in libparanoia in case of 
> > disabled C2 Checks. The problem was fixed two weeks ago and published in a 
> > preliminary copy of the schily tools:
> > 
> > 	http://sourceforge.net/projects/schilytools/files/
> > 
> > Since yesterday evening, the paraopts=proof macro again includes c2check and 
> > there is an automatic fallback to the "no c2" case when the drive does not 
> > support C2 Checks. Note that this was only tested with a single drive so far,
> > so we need more tests here from people with different hardware.
>
> I can do some testing on various drives, however please point to exact
> software tar files to try, I don't have time to run around 5 different
> websites, all with dead links (berlios etc), outdated stuff, and

???

Is it hard to understand that the file listed as most recent file on that 
download page is the right one?

> ridiculous naming schemes of tar files, and I don't have time to sort
> out all the schily-whatever.tar stuff, like cdrtools-3.01.tar.bz2 and
> schily-2015-09-16.tar.bz2 seemingly containing the same, sorry. And I'm
> not interested in politics.

If you read the public information, you should know that "schily tools" is just 
a frequently updated snapshot of all sources - not only cdrtools.

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/'

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

grarpamp <gra...@gm...> wrote:

> On Tue, Oct 20, 2015 at 11:58 AM, Joerg Schilling
> <Joe...@fo...> wrote:
> > Schilytools get frequent updates and all the code is in SCCS.
> > There will be a public version control once I got the time to make SCCS network
> > aware ;-)
>
> Even from FTP days :) Yet importing that as big diffs isn't ideal, and
> maybe the old are unpublished now from moving around Fokus, Berlios, SF.
> Perhaps you can export this SCCS to github before you get time to
> write new SchilyNetworkSCCS ;-)

Well, GIT would loss meta data and I suspect there is no code to convert SCCS 
into GIT.

The good news is that SCCS is already close to the planned v6 release and 
Sourceforge signalled to integrate support for SCCS once it is ready.

> And put a tarball of the history of mail archive in download area of SF
> once in a while for loading as easy reference into users MUA's.

A tarball from what mail archive?

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/'

Re: [Cdrtools-support] cdda2wav only finds errors

[Volker K. <lis...@pa...>]

On Tue 20 Oct 2015 23:11:14 NZDT +1300, Joerg Schilling wrote:

> please do not use cd...@ot... anymore, there is nobody really 
> listening and the only traffic seems to be spam since Debian attacked cdrtools.
> 
> Please rather use cdr...@li...,

Thanks for letting me know. There appears to be no more traffic there
than here, but hey. When SF gets round to processing subscriptions.

> There was a problem with an uninitalized variable in libparanoia in case of 
> disabled C2 Checks. The problem was fixed two weeks ago and published in a 
> preliminary copy of the schily tools:
> 
> 	http://sourceforge.net/projects/schilytools/files/
> 
> Since yesterday evening, the paraopts=proof macro again includes c2check and 
> there is an automatic fallback to the "no c2" case when the drive does not 
> support C2 Checks. Note that this was only tested with a single drive so far,
> so we need more tests here from people with different hardware.

I can do some testing on various drives, however please point to exact
software tar files to try, I don't have time to run around 5 different
websites, all with dead links (berlios etc), outdated stuff, and
ridiculous naming schemes of tar files, and I don't have time to sort
out all the schily-whatever.tar stuff, like cdrtools-3.01.tar.bz2 and
schily-2015-09-16.tar.bz2 seemingly containing the same, sorry. And I'm
not interested in politics.

My early tests show that cdda2wav 3.01 with libscg and libschily
3.01~a15 doesn't work any better, but cdda2wav 3.01a15 with those shows
at least plausible error rates.

My testing is spread over openSUSE Linux 12.3 and 13.2, with OBS
packages. I verified that the one patch applied by suse is not the
problem (you might want to check it out for other fixes though).

Thanks muchly,

Volker

-- 
Volker Kuhlmann
http://volker.top.geek.nz/	Please do not CC list postings to me.

Re: [Cdrtools-support] cdda2wav only finds errors

[grarpamp <gra...@gm...>]

On Tue, Oct 20, 2015 at 11:58 AM, Joerg Schilling
<Joe...@fo...> wrote:
> Schilytools get frequent updates and all the code is in SCCS.
> There will be a public version control once I got the time to make SCCS network
> aware ;-)

Even from FTP days :) Yet importing that as big diffs isn't ideal, and
maybe the old are unpublished now from moving around Fokus, Berlios, SF.
Perhaps you can export this SCCS to github before you get time to
write new SchilyNetworkSCCS ;-)
And put a tarball of the history of mail archive in download area of SF
once in a while for loading as easy reference into users MUA's.

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

grarpamp <gra...@gm...> wrote:

> This reminds me... is there a publicly accessible online version control
> repository for schilytools, such as git, svn, hg, etc? If so, where? Thanks :)

Schilytools get frequent updates and all the code is in SCCS.

There will be a public version control once I got the time to make SCCS network 
aware ;-)

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/'

Re: [Cdrtools-support] cdda2wav only finds errors

[grarpamp <gra...@gm...>]

On Tue, Oct 20, 2015 at 6:11 AM, Joerg Schilling
<Joe...@fo...> wrote:
>         Since some years, there is unfortunately few feedback on cdrtools. But
>         quality also depends on user feedback.....

>> --- cdrtools-3.01a15/cdda2wav/cdda2wav.c      2013-05-31 08:56:43.000000000 +1200
>> +++ cdrtools-3.01a25/cdda2wav/cdda2wav.c      2014-03-04 11:57:08.000000000 +1300

> There was a problem with an uninitalized variable in libparanoia in case of
> disabled C2 Checks. The problem was fixed two weeks ago and published in a
> preliminary copy of the schily tools:
>
>         http://sourceforge.net/projects/schilytools/files/

> Since yesterday evening, the paraopts=proof macro again includes c2check and
> there is an automatic fallback to the "no c2" case when the drive does not
> support C2 Checks. Note that this was only tested with a single drive so far,
> so we need more tests here from people with different hardware.

This reminds me... is there a publicly accessible online version control
repository for schilytools, such as git, svn, hg, etc? If so, where? Thanks :)

Re: [Cdrtools-support] cdda2wav only finds errors

[Joerg S. <Joe...@fo...>]

Hi,

please do not use cd...@ot... anymore, there is nobody really 
listening and the only traffic seems to be spam since Debian attacked cdrtools.

Please rather use cdr...@li..., this is where people 
are listening and answering.

Volker Kuhlmann <lis...@pa...> wrote:

> Trying to digitise audio CDs with cdda2wav from cdrtools 3.01 I only
> get:
>
> 100%  track 21  recorded with audible hard errors
> 100%  track 22  recorded with audible hard errors
> 100%  track 23  recorded with audible hard errors (0.1% problem sectors)
>
> I.e. every track is reported with "recorded with audible hard errors" as
> best result. The same happens with 3.01a25. All on about 5 different
> drives.

This problem is active since Spring 2014 or even since late 2013 if you did not 
use c2checks. So the problem (that depends on some compiler constraints) was really
visible since Spring 2014 when (as a hacky fix against dumb drives) the c2check 
was removed from the paraopts=proof macro.

Since the problem is not triggered by the Sun C-compiler, it was not detected 
while testing at that time.


	Since some years, there is unfortunately few feedback on cdrtools. But
	quality also depends on user feedback.....



> With cdda2wav 3.01a15, on the same drive as above example, the result
> is:
>
> 100%  track 11  recorded successfully
> 100%  track 12  recorded successfully
> 100%  track 16  recorded with minor problems
> 100%  track 18  recorded with minor problems (0.3% problem sectors)
> 100%  track 19  recorded successfully
> 100%  track 20  recorded with minor problems (0.3% problem sectors)
> 100%  track 21  recorded with minor problems
> 100%  track 22  recorded successfully
> 100%  track 23  recorded with medium problems (5.4% problem sectors)
>
> I.e. a mix of success and some (usually minor) problems.
>
> Between 3.01a15 and 3.01a25 is this change:
>
> --- cdrtools-3.01a15/cdda2wav/cdda2wav.c	2013-05-31 08:56:43.000000000 +1200
> +++ cdrtools-3.01a25/cdda2wav/cdda2wav.c	2014-03-04 11:57:08.000000000 +1300
> -				if (para_stat->readerrs) {
> +				if (para_stat->readerrs || para_stat->c2badsecs) {
>  					fprintf(outfp,
>  						_(" with audible hard errors"));
>
> Which suggests the error detection has become better. However, if every
> CD and every track is read with "audible hard errors" then either the
> process is flawed, all drives are not really useful, or the software is
> either flawed or not so useful - I don't quite believe all pressed CDs
> are that bad everywhere.
>
> Is there a problem in the software?
> If the software is indeed operating correctly, what are good drives to
> use for digitising an audio CD collection?

There was a problem with an uninitalized variable in libparanoia in case of 
disabled C2 Checks. The problem was fixed two weeks ago and published in a 
preliminary copy of the schily tools:

	http://sourceforge.net/projects/schilytools/files/

Since yesterday evening, the paraopts=proof macro again includes c2check and 
there is an automatic fallback to the "no c2" case when the drive does not 
support C2 Checks. Note that this was only tested with a single drive so far,
so we need more tests here from people with different hardware.

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/'

Re: [Cdrtools-support] EXTERNAL: Re: Problem with growisofs -- cannot write multisession DVDs without ejecting and reloading tray

[Joerg S. <Joe...@fo...>]

"Richardson, Eric J" <eri...@lm...> wrote:

> > It seems that you are using the wrong devices.....
>
> > You started with dev=1,0,0, why did you try to use a different device later on?
>
> Whoops!  Sorry, that was my bad.  I typed this out from memory:
>
> > > cdrecord -v speed=2 dev=1,0,0 -multi /tmp/file.raw
>
> But the later ones I copied directly from the screen.  I am not really switching devices; I just got the machines confused when I typed the first command.
>
> > Given the fact that you did not report about errors from the first write process, I assume that you used the right device.
>
> Yes, I use dev=2,0,0 for the initial cdrecord.  I got this number from cdrecord -scanbus.  Using this device does not generate any errors.
>
> > Given the fact that you could not mount the device, I assume that you used the wrong UNIX device name.
>
> I use /dev/sr0 to mount the device.  I cannot mount the drive, using /dev/sr0 OR /dev/dvd, after the first write without manually reloading the tray. After I reload the tray, /dev/sr0 mounts just fine.  I cannot perform the second write at all, as I said.  From reading the man page, I think I am supposed to use the UNIX device name with the -M in mkisofs, but mkisofs does not like /dev/sr0.  It did attempt to write when I used /dev/dvd, which is a link to /dev/sr1, but I don't know enough about Linux device names to know why.  As I said in my first email, the attempt to write was unsuccessful.
>
> > If there is only on CD-ROM type device on your machine, cdrecord will use the right one without a need to specify dev= - read the man pages....
>
> Yes, I read that in the man pages, but there is a second CD-ROM device that confuses things.  The KVM that this machine is on attaches a "bonus" device via USB, which for some reason shows up as a CD drive at 0,0,0.  This is why I specify the dev.

Linux device naming in special related to SCSI is a nightmare and you would 
first need to find out the right device names.

I would start with a definitely working medium and see whether there is an 
automounter that is clever enough to mount the device.

Besides the problems in Linux that Mr. Torvalds intentionally removed the 
ioctl()s that would allow to correctly map all device names, there is another 
problem: hald and it's successors - all writtenby  the same person that does 
not know enough about the state graph of CD-ROMs...

The latter may cause Linux interrupt a write process and to detect media.

If you wrote the medium and if you did not got any error message from the 
drive and still the medium is apparently not written, you may have used bad 
media or the Linux kernel did hide problems from you, so cdrecord could not 
report.

First run cdrecord -minfo -v for the same device you used for writing.

If this does not work, try media that is known to be OK, e.g. Verbatim (small 
quantities for consumer packages have higher 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://sourceforge.net/projects/schilytools/files/'