Re: [CentOS] trying to recover an audio CD...
Fred Smith [hidden email] wrote: Jörg: Sorry I'm so late replying, I missed your reply back when it was new... I'm trying to recover data from an audio cd. it is a recording of a live session, made on a professional cd recorder, on the fly. Do you have any working CD from that drive? If yes, you could call: cdrecord -minfo to get the state and to find out whether it writes in TAO mode. (-minfo is a shortcut for -media-info). Such discs do exist, I just don't happen to have one handy at the moment. I'll see if I can acquire one. apparently, instead of stopping it and fixating the disc, someone turned off the power. oops. I know that wodim will fixate a disk as long as it was otherwise properly terminated (I've done it more than once), but this one it won't fixate. depending on the drive I try it in, I get different messages, but in either case, it remains unfixated. wodim is a defective variant from an extremely outdated cdrecord (taken from a cdrecord from September 2004). - Did you try the original software? Not yet. I just built latest cdrtools but haven't done anything with them yet. - Is it possible to use the original drive that was used for writing? the original isn't a drive per se, it's a professional audio recorder, rack-mounted, that contains a CD drive of some sort. I THINK what happened was the recorder was powered off while writing. Probably made a huge mess of the data, or at least left it in some bad unfinished state. so i've tried reading it with cdparanoia, but it can't do anything with it, or not that I've figured out how to do. cdparanoia is a patch on a cdda2wav version from 1997. There was never an update on the cdda2wav code and development stopped in 2001. Don't expect cdparanoia to be able to read such disks, as the _read_ properties in cdparanoia are generally bad compared to a recent cdda2wav. Note that after the development for cdparanoia stopped around 2000/2001, Heiko Eißfeld and I took the paranoia code (the code in cdparanoia above the read layer that is responsible for retries and result rating) out of cdparanoia, made a portable library from it and added it to cdda2wav. Your problem is that cdparanoia will never read a TOC-less disk and that the dead fork from a September 2004 cddda2wav called icedax is full of bugs. The real cdda2wav has a compile option to set up a virtual TOC, but if you ever like to read a CD without a TOC, you not only need to tell cdda2wav the TOC by exiting the compiled in TOC, but you also need to kill any hostile software on your computer that tries to access CDs in an unapropriate way, such as hald or it's successors. Once such a program did try to access a problematic CD, you will never be able to access the CD unless you reload it - which will result in a new access attempt :-( Ugh. I think I'll have to build a VM for this, since I don't want to break my existing system. If the CD has a PMA (which I expect from writing in TAO mode), the disk should be readable by cdda2wav if you use a drive that understands the PMA. so, if cdrecord -minfo tells me it was written as TAO, then there should be a PMA and I might then be able to read it with cdda2wav? Thanks for the info! Fred Jörg -- View this message in context: http://centos.1050465.n5.nabble.com/CentOS-trying-to-recover-an-audio-CD-tp5717892p5718276.html Sent from the CentOS mailing list archive at Nabble.com. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Latest Pidgin update problem
A while back I added the pidgin repo to my yum configuration and installed pidgin. it has automatically updated itself a time or two since without trouble. but now that Pidgin 2.1.0 is out, it won't update properly. Yum finds a couple of libpurple packages to update as well as pidgin-devel, but not the pidgin package itself: -- Populating transaction set with selected packages. Please wait. --- Package libpurple.i386 0:2.1.0-0.el4 set to be updated --- Package pidgin-devel.i386 0:2.1.0-0.el4 set to be updated --- Package libpurple-devel.i386 0:2.1.0-0.el4 set to be updated -- Running transaction check -- Processing Dependency: pidgin = 2.1.0 for package: pidgin-devel -- Finished Dependency Resolution Error: Missing Dependency: pidgin = 2.1.0 is needed by package pidgin-devel Anybody else seen this? It seems odd that the official pidgin repo would have 3 of the four necessary packages but not the fourth. -- Fred Smith -- [EMAIL PROTECTED] - The eyes of the Lord are everywhere, keeping watch on the wicked and the good. - Proverbs 15:3 (niv) - pgp63qYiG1Nfc.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Latest Pidgin update problem
On Sat, Aug 04, 2007 at 11:57:55AM -0500, Johnny Hughes wrote: fredex wrote: A while back I added the pidgin repo to my yum configuration and installed pidgin. it has automatically updated itself a time or two since without trouble. but now that Pidgin 2.1.0 is out, it won't update properly. Yum finds a couple of libpurple packages to update as well as pidgin-devel, but not the pidgin package itself: -- Populating transaction set with selected packages. Please wait. --- Package libpurple.i386 0:2.1.0-0.el4 set to be updated --- Package pidgin-devel.i386 0:2.1.0-0.el4 set to be updated --- Package libpurple-devel.i386 0:2.1.0-0.el4 set to be updated -- Running transaction check -- Processing Dependency: pidgin = 2.1.0 for package: pidgin-devel -- Finished Dependency Resolution Error: Missing Dependency: pidgin = 2.1.0 is needed by package pidgin-devel Anybody else seen this? It seems odd that the official pidgin repo would have 3 of the four necessary packages but not the fourth. Is it possible that the pidgin that you have installed has an epoch 0. Also, try: yum clean all Then try again, as maybe something is cached in metadata that does not show the latest pidgin. Also, if you have priorities (or protectbase) enabled, you will need to use this in the base and updates repo sections of /etc/yum.repos.d/CentOS-Base.repo to get things to be updateable by 3rd Part repos: exclude=pidgin* libpurple* Thanks, Johnny! The exclude=... statement did the trick. I find it curious that I haven't needed it before this. -- Fred Smith -- [EMAIL PROTECTED] - But God demonstrates his own love for us in this: While we were still sinners, Christ died for us. --- Romans 5:8 (niv) -- pgpGUPa9OQR96.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Strange C programming problem
I've got this little program I wrote to test something, and it keeps
giving the wrong result. I'm not inexperienced in C, but I can't believe
strtof (et al) are broken, so I must be doing something wrong. However,
I've spent hours looking at this and comparing it to the man pages and
don't see what I'm doing wrong. strtod() and strtold() also give equally
wrong results. (the example program given on the strotd man page works
fine, BTW.)
Can someone wield a clue-bat please? :)
Here's the program:
#include stdio.h
#include math.h
#include stdlib.h
#include errno.h
int main (int argc, char ** argv)
{
float ldbl = 0.0;
char * endp;
printf (%s\n, argv[1]);
errno = 0;
ldbl = strtof (argv[1], endp);
if (errno != 0)
printf (strtof failed! errno=%d\n, errno);
printf (%f\n, (double) ldbl);
printf (%f\n, (double) strtof (argv[1], (char **)NULL));
printf (%f\n, (double) atof (argv[1]));
return 0;
}
Compile it with:
cc -O0 -g -o x4 x4.c
then run it like this:
./x4 2.5
and I'd EXPECT it to produce this output:
2.5
2.5
2.5
2.5
but it actually produces this:
2.5
1075838976.00
1075838976.00
2.50
the typecase of the arg in the 3 printf calls makes no difference. Remove
it and the results are the same.
Using an input of something other than 2.5 changes the middle two lines in
some way in which I haven't yet discerned a pattern, but the result is still
highly bogus.
Thanks!
--
Fred Smith -- [EMAIL PROTECTED] -
And he will be called Wonderful Counselor, Mighty God, Everlasting Father,
Prince of Peace. Of the increase of his government there will be no end. He
will reign on David's throne and over his kingdom, establishing and upholding
it with justice and righteousness from that time on and forever.
--- Isaiah 9:7 (niv) --
pgpC0Og3135im.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Strange C programming problem
On Sat, Jul 14, 2007 at 12:52:09PM -0400, Michael Velez wrote:
I've got this little program I wrote to test something, and
it keeps giving the wrong result. I'm not inexperienced in C,
but I can't believe strtof (et al) are broken, so I must be
doing something wrong. However, I've spent hours looking at
this and comparing it to the man pages and don't see what I'm
doing wrong. strtod() and strtold() also give equally wrong
results. (the example program given on the strotd man page
works fine, BTW.)
Can someone wield a clue-bat please? :)
Here's the program:
#include stdio.h
#include math.h
#include stdlib.h
#include errno.h
int main (int argc, char ** argv)
{
float ldbl = 0.0;
char * endp;
printf (%s\n, argv[1]);
errno = 0;
ldbl = strtof (argv[1], endp);
if (errno != 0)
printf (strtof failed! errno=%d\n, errno);
printf (%f\n, (double) ldbl);
printf (%f\n, (double) strtof (argv[1], (char **)NULL));
printf (%f\n, (double) atof (argv[1]));
return 0;
}
Compile it with:
cc -O0 -g -o x4 x4.c
then run it like this:
./x4 2.5
and I'd EXPECT it to produce this output:
2.5
2.5
2.5
2.5
but it actually produces this:
2.5
1075838976.00
1075838976.00
2.50
the typecase of the arg in the 3 printf calls makes no
difference. Remove it and the results are the same.
Using an input of something other than 2.5 changes the middle
two lines in some way in which I haven't yet discerned a
pattern, but the result is still highly bogus.
The following strtod line works fine on my system (CentOS 5, latest updates,
x86_64):
printf (%lf\n, (double) strtod (argv[1], (char **)NULL));
For strtof, the SYNOPSIS in the man page mentions you need to add:
#define _ISO_C99_SOURCE
Or
#define _XOPEN_SOURCE 600
Either line should be added before ALL include files (note there is a
mistake in the synopsis. There should be no = sign in the define statement
for _XOPEN_SOURCE).
The above #define lines enforces C99 compatibility rules, which is the
revised ISO C standard which came out in 1999. As a previous responder
suggested, you can also specify -std=gnu99 or -std=C99 on the compile line.
Michael
Sorry, I forgot to mention that I'm using Centos 4.5. And the man
page here doesn't mention those #define settings. I'll give it a try,
thanks!
--
---
.Fred Smith /
( /__ ,__. __ __ / __ : /
// / /__) / / /__) .+' Home: [EMAIL PROTECTED]
// (__ (___ (__(_ (___ / :__ 781-438-5471
Jude 1:24,25 -
pgpNiPSHtvWEl.pgp
Description: PGP signature
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] Gnome Taskbar(s)
Question: All the newer Gnome distributions seem to configure themselves with two small taskbars (panels, I guess) one at the top and one at the bottom. I prefer the older scheme with one larger one (usually) at the bottom. When I install Centos5 in the near future I'm going to want to be able to restore the old-style panels. Anybody know what I need to change to make it work in the old way? Thanks! -- Fred Smith -- [EMAIL PROTECTED] - I can do all things through Christ who strengthens me. -- Philippians 4:13 --- pgp5UGye5OMvF.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
