Copying a CD with k3b is no problem, except I want to include on my copy the cbbd data (from freedb.org). I've configured k3b's cddb section according to instructions at http://www.freedb.org/en/faq.3.html#15 and read every article google could find about "k3b cddb freedb.org config", but still k3b can't manage it. Grip handles getting the cddb data just fine. I'm beginning to think that k3b is simply broke as far as this functionality is concerned. But I thought I'd ask here if anyone has found a way to make this work.
tia for all helpful tips.
ken gebser@mousecar.com wrote:
Copying a CD with k3b is no problem, except I want to include on my copy the cbbd data (from freedb.org). I've configured k3b's cddb section according to instructions at http://www.freedb.org/en/faq.3.html#15 and read every article google could find about "k3b cddb freedb.org config", but still k3b can't manage it. Grip handles getting the cddb data just fine. I'm beginning to think that k3b is simply broke as far as this functionality is concerned. But I thought I'd ask here if anyone has found a way to make this work.
Doing this is no problem if you just use the cdrtools from the commandline.
BTW: I recommend to use cdda2wav for audio extraction.
Jörg
n 08/17/2013 05:29 PM Joerg Schilling wrote:
ken gebser@mousecar.com wrote:
Copying a CD with k3b is no problem, except I want to include on my copy the cbbd data (from freedb.org). I've configured k3b's cddb section according to instructions at http://www.freedb.org/en/faq.3.html#15 and read every article google could find about "k3b cddb freedb.org config", but still k3b can't manage it. Grip handles getting the cddb data just fine. I'm beginning to think that k3b is simply broke as far as this functionality is concerned. But I thought I'd ask here if anyone has found a way to make this work.
Doing this is no problem if you just use the cdrtools from the commandline.
BTW: I recommend to use cdda2wav for audio extraction.
Jörg
Jörg,
Thanks for your reply. As late as November 2012 I always used the CLI for copying *data* CDs, using cdrecord and readcd. But though I read and studied manpages and scads of documentation, I never had any luck cloning a music CD using these commands. So I'd doubt I could figure out on my own, in addition to cloning a CD, adding in the song titles etc.
I guess I wasn't clear about ripping a CD. Grip, as I said handles this fine, including downloading the cddb data. So if I wanted to create wav (or ogg or other) files, I could use grip. But for some CDs, a series of wav files just doesn't play back well; I'm talking about music in which one track blends into the following track with no break in between. These don't play back well because audio players insert a break (perhaps because they need a second or so to load that second track) and, in addition, often this break isn't in a good moment. So I've decided to just burn the entire CD to avoid hearing the breaks. So is it even possible to save the cddb data to a copied CD?
ken gebser@mousecar.com wrote:
Thanks for your reply. As late as November 2012 I always used the CLI for copying *data* CDs, using cdrecord and readcd. But though I read and studied manpages and scads of documentation, I never had any luck cloning a music CD using these commands. So I'd doubt I could figure out on my own, in addition to cloning a CD, adding in the song titles etc.
Are you using recent original software or are you using an outdated, dead and defective fork that is distributed by some non-OpenSource oriented Linux sources?
If you are using this bad fork that is from September 2004 - 9 years ago, you suffer from many problems, like incomplete documentation and many bugs that cannot be found in the original software.
I guess I wasn't clear about ripping a CD. Grip, as I said handles this fine, including downloading the cddb data. So if I wanted to create wav (or ogg or other) files, I could use grip. But for some CDs, a series of wav files just doesn't play back well; I'm talking about music in which one track blends into the following track with no break in between. These don't play back well because audio players insert a break (perhaps because they need a second or so to load that second track) and, in addition, often this break isn't in a good moment. So I've decided to just burn the entire CD to avoid hearing the breaks. So is it even possible to save the cddb data to a copied CD?
Programs like grip and cdparanoia don't care about the usability of the extracted files for later burning tasks and they are not able to extract so called "un-CDs".
cdda2wav knows about the writing process, feteches cddb data and includes a bug-fixed libparanoia.
Recent man pages also contain several related examples. Did you read a recent manpage and follow the EXAMPLE section?
Jörg
On 08/18/2013 04:13 PM Joerg Schilling wrote:
ken gebser@mousecar.com wrote:
Thanks for your reply. As late as November 2012 I always used the CLI for copying *data* CDs, using cdrecord and readcd. But though I read and studied manpages and scads of documentation, I never had any luck cloning a music CD using these commands. So I'd doubt I could figure out on my own, in addition to cloning a CD, adding in the song titles etc.
Are you using recent original software or are you using an outdated, dead and defective fork that is distributed by some non-OpenSource oriented Linux sources?
If you are using this bad fork that is from September 2004 - 9 years ago, you suffer from many problems, like incomplete documentation and many bugs that cannot be found in the original software.
cdrecord and readcd are both part of this package:
$ rpm -qi cdrecord Name : cdrecord Relocations: (not relocatable) Version : 2.01 Vendor: CentOS Release : 10.7.el5 Build Date: Thu 26 Feb 2009 06:30:50 PM EST Install Date: Mon 05 Sep 2011 03:03:56 PM EDT Build Host: chamkaur.karan.org Group : Applications/Archiving Source RPM: cdrtools-2.01-10.7.el5.src.rpm Size : 1383954 License: GPL Signature : DSA/SHA1, Sun 08 Mar 2009 09:45:19 PM EDT, Key ID a8a447dce8562897 Packager : Karanbir Singh kbsingh@karan.org URL : http://cdrecord.berlios.de/old/private/cdrecord.html Summary : A command line CD/DVD recording program. Description : ....
The "Description" states nothing about it being from a bad fork from 2004. :) So how would anyone know?
I guess I wasn't clear about ripping a CD. Grip, as I said handles this fine, including downloading the cddb data. So if I wanted to create wav (or ogg or other) files, I could use grip. But for some CDs, a series of wav files just doesn't play back well; I'm talking about music in which one track blends into the following track with no break in between. These don't play back well because audio players insert a break (perhaps because they need a second or so to load that second track) and, in addition, often this break isn't in a good moment. So I've decided to just burn the entire CD to avoid hearing the breaks. So is it even possible to save the cddb data to a copied CD?
Programs like grip and cdparanoia don't care about the usability of the extracted files for later burning tasks and they are not able to extract so called "un-CDs".
cdda2wav knows about the writing process, feteches cddb data and includes a bug-fixed libparanoia.
Recent man pages also contain several related examples. Did you read a recent manpage and follow the EXAMPLE section?
I don't know what is meant here by "recent". Which is the earliest version which contains the functionality required?
ken gebser@mousecar.com wrote:
If you are using this bad fork that is from September 2004 - 9 years ago, you suffer from many problems, like incomplete documentation and many bugs that cannot be found in the original software.
cdrecord and readcd are both part of this package:
$ rpm -qi cdrecord Name : cdrecord Relocations: (not relocatable) Version : 2.01 Vendor: CentOS Release : 10.7.el5 Build Date: Thu 26 Feb 2009 06:30:50 PM EST Install Date: Mon 05 Sep 2011 03:03:56 PM EDT Build Host: chamkaur.karan.org Group : Applications/Archiving Source RPM: cdrtools-2.01-10.7.el5.src.rpm Size : 1383954 License: GPL Signature : DSA/SHA1, Sun 08 Mar 2009 09:45:19 PM EDT, Key ID a8a447dce8562897 Packager : Karanbir Singh kbsingh@karan.org URL : http://cdrecord.berlios.de/old/private/cdrecord.html Summary : A command line CD/DVD recording program. Description : ....
The "Description" states nothing about it being from a bad fork from 2004. :) So how would anyone know?
You will not get useful version information from calling "rpm".
There is nothing like: cdrtools-2.01-10.7.el5
If you like to know what you are using, I recommend to call:
cdrecord -version cdda2wav -version readcd -version mkisofs -version
If you are using original software, you will see someting like:
Cdrecord-ProDVD-ProBD-Clone 3.01a16 (i386-pc-solaris2.11) Copyright (C) 1995-2013 Joerg Schilling
If one of the commends does not print a message like this, you should be careful.
BTW: cdrtools-2.01 is from September 2004.
Programs like grip and cdparanoia don't care about the usability of the extracted files for later burning tasks and they are not able to extract so called "un-CDs".
cdda2wav knows about the writing process, feteches cddb data and includes a bug-fixed libparanoia.
Recent man pages also contain several related examples. Did you read a recent manpage and follow the EXAMPLE section?
I don't know what is meant here by "recent". Which is the earliest version which contains the functionality required?
The features in question are in since a longer time, but if you are on a Linux distro that does not deliver up-to-date software, you should expect that there are bugs in your version that never have been in the original software.
Since 2004, the man pages have been completely rewritten for better readability, the features have been massively enhanced (they did more than double since September 2004) and many bugs have been fixed. In January 2010, cdda2wav e.g. added support for hidden tracks. Mkisofs added support for libfind in 2006 and cdrecord added support for BluRay in 2007.
Would you like to run a Linux kernel from 2004 today?
Jörg
On 08/19/2013 09:58 AM Joerg Schilling wrote:
ken gebser@mousecar.com wrote:
If you are using this bad fork that is from September 2004 - 9 years ago, you suffer from many problems, like incomplete documentation and many bugs that cannot be found in the original software.
cdrecord and readcd are both part of this package:
$ rpm -qi cdrecord Name : cdrecord Relocations: (not relocatable) Version : 2.01 Vendor: CentOS Release : 10.7.el5 Build Date: Thu 26 Feb 2009 06:30:50 PM EST Install Date: Mon 05 Sep 2011 03:03:56 PM EDT Build Host: chamkaur.karan.org Group : Applications/Archiving Source RPM: cdrtools-2.01-10.7.el5.src.rpm Size : 1383954 License: GPL Signature : DSA/SHA1, Sun 08 Mar 2009 09:45:19 PM EDT, Key ID a8a447dce8562897 Packager : Karanbir Singh kbsingh@karan.org URL : http://cdrecord.berlios.de/old/private/cdrecord.html Summary : A command line CD/DVD recording program. Description : ....
The "Description" states nothing about it being from a bad fork from 2004. :) So how would anyone know?
You will not get useful version information from calling "rpm".
There is nothing like: cdrtools-2.01-10.7.el5
[cdrtools-2.01-10.7.el5 ist einmalig???]
You're saying this is the preferred package, yes? and it will have the functionality needed? If yes and yes, where does one get that package?
Note that my rpm command output above says: Source RPM: cdrtools-2.01-10.7.el5.src.rpm
If you like to know what you are using, I recommend to call:
cdrecord -version cdda2wav -version readcd -version mkisofs -version
So there should be something definitive to say about these:
$ cdrecord -version Cdrecord-Clone 2.01 (cpu-pc-linux-gnu) Copyright (C) 1995-2004 J�rg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla Note: The author of cdrecord should not be bothered with problems in this version. $ cdda2wav -version cdda2wav version 2.01_linux_2.6.18-92.1.10.el5_x86_64_x86_64 $ readcd -version readcd 2.01 (cpu-pc-linux-gnu) Copyright (C) 1987, 1995-2003 J�rg Schilling $ mkisofs -version mkisofs 2.01 (cpu-pc-linux-gnu)
If you are using original software, you will see someting like:
Cdrecord-ProDVD-ProBD-Clone 3.01a16 (i386-pc-solaris2.11) Copyright (C) 1995-2013 Joerg Schilling
If one of the commends does not print a message like this, you should be careful.
Well, I'm always careful (except that one time I backed my car into the garage door).
Without knowing what is *essential* in the "-version" output, it's hard to say anything definitive. Jörg, I'm not a lawyer, but I know it's possible to get a tradename which then others could use only with your permission. So is you owned "Jörg's unmessed with software" or "Jörg's truly functional code", you could put that in the "-version" output, but no one else could unless they had your permission... iow, they couldn't muck with your code and then confuse people by saying it's your code. (I'm assuming that this is what you mean by "original".) This then would constitute a definitive determination.
BTW: cdrtools-2.01 is from September 2004.
Programs like grip and cdparanoia don't care about the usability of the extracted files for later burning tasks and they are not able to extract so called "un-CDs".
What's an "un-CD"?
cdda2wav knows about the writing process, feteches cddb data and includes a bug-fixed libparanoia.
Recent man pages also contain several related examples. Did you read a recent manpage and follow the EXAMPLE section?
I don't know what is meant here by "recent". Which is the earliest version which contains the functionality required?
The features in question are in since a longer time, but if you are on a Linux distro that does not deliver up-to-date software, you should expect that there are bugs in your version that never have been in the original software.
What I hear is that you and Redhat/CentOS have different ideas as to what "up-to-date" means. My system is completely up-to-date as defined by the latter.
For a person of considerable talents as you, it shouldn't be a big deal to put together an RPM package for currently supported RH/cOS (v. 5.9 and 6.x) with the needed utilities and which wouldn't break dependent apps such as k3b, grip, gnome-cd, etc. Then these two disparate worlds would be united, at least as far as burning and ripping CDs and DVDs goes.
Since 2004, the man pages have been completely rewritten for better readability, the features have been massively enhanced (they did more than double since September 2004) and many bugs have been fixed. In January 2010, cdda2wav e.g. added support for hidden tracks. Mkisofs added support for libfind in 2006 and cdrecord added support for BluRay in 2007.
Would you like to run a Linux kernel from 2004 today?
No. But I wouldn't either want to go back to the days before package management.
Jörg
ken gebser@mousecar.com wrote:
There is nothing like: cdrtools-2.01-10.7.el5
[cdrtools-2.01-10.7.el5 ist einmalig???]
You're saying this is the preferred package, yes? and it will have the functionality needed? If yes and yes, where does one get that package?
Note that my rpm command output above says: Source RPM: cdrtools-2.01-10.7.el5.src.rpm
A version cdrtools-2.01-10.7.el5 does not exist.
If you like to know what you are using, I recommend to call:
cdrecord -version cdda2wav -version readcd -version mkisofs -version
So there should be something definitive to say about these:
$ cdrecord -version Cdrecord-Clone 2.01 (cpu-pc-linux-gnu) Copyright (C) 1995-2004 J???rg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla Note: The author of cdrecord should not be bothered with problems in this version.
So this is a release where somebody did rip off the working original DVD support code and replaced it with half baken other code that is known not to work correctly.
You still get a completely outdated software.
$ cdda2wav -version cdda2wav version 2.01_linux_2.6.18-92.1.10.el5_x86_64_x86_64 $ readcd -version readcd 2.01 (cpu-pc-linux-gnu) Copyright (C) 1987, 1995-2003 J???rg Schilling $ mkisofs -version mkisofs 2.01 (cpu-pc-linux-gnu)
Be careful, this mkisofs is full of bugs and creates ISO buggy images.
Without knowing what is *essential* in the "-version" output, it's hard
If I have trouble with a piece of software, I call xxx -version and if that prints 2004 as the newest date, I know that something is wrong.
to say anything definitive. Jörg, I'm not a lawyer, but I know it's possible to get a tradename which then others could use only with your permission. So is you owned "Jörg's unmessed with software" or "Jörg's truly functional code", you could put that in the "-version" output, but no one else could unless they had your permission... iow, they couldn't muck with your code and then confuse people by saying it's your code. (I'm assuming that this is what you mean by "original".) This then would constitute a definitive determination.
There is no need to get a trademark as the name "cdrecord" is a trademark even wihtout registering it.
Programs like grip and cdparanoia don't care about the usability of the extracted files for later burning tasks and they are not able to extract so called "un-CDs".
What's an "un-CD"?
Did you try google?
Intentionally broken CD shaped media sold by the music industry.
What I hear is that you and Redhat/CentOS have different ideas as to what "up-to-date" means. My system is completely up-to-date as defined by the latter.
Someone who did not do his homework for 9 years could be called dead. It seems that your distro missed 97 updated versions from cdrtools.
If FORD did stop creating newer models with Model T, this was still "up to date", but would you like to use it today?
For a person of considerable talents as you, it shouldn't be a big deal to put together an RPM package for currently supported RH/cOS (v. 5.9 and 6.x) with the needed utilities and which wouldn't break dependent apps such as k3b, grip, gnome-cd, etc. Then these two disparate worlds would be united, at least as far as burning and ripping CDs and DVDs goes.
You miss the point: I write software that compiles/runs nearly everywhere from source.
It is the duty of the distros to create packages. I cannot create packages for > 100 OS/cpu combinations.
Would you like to run a Linux kernel from 2004 today?
No. But I wouldn't either want to go back to the days before package management.
I am sure that if you go to your favorite PC shop and this shop has no model from after 2004, you would ask the dealer to get newer items or chose another dealer.
In other words, you either choose a distro that offers up to date packages or you need to compile yourself.
Jörg
On Mon, Aug 19, 2013 at 3:23 PM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Would you like to run a Linux kernel from 2004 today?
Has the CD format changed since 2004?
In other words, you either choose a distro that offers up to date packages or you need to compile yourself.
I'm sure you realize that no one on this list wants 'up to date' software as shipped by developers - and why. Is there some compromise possible where a somewhat vetted, packaged release exists? Or RedHat gets appropriate bug reports so they fix the broken parts?
Les Mikesell lesmikesell@gmail.com wrote:
On Mon, Aug 19, 2013 at 3:23 PM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Would you like to run a Linux kernel from 2004 today?
Has the CD format changed since 2004?
This is why you are happy with buggy software from 2004 shipped by redhat when there is software with no known bugs?
In other words, you either choose a distro that offers up to date packages or you need to compile yourself.
I'm sure you realize that no one on this list wants 'up to date' software as shipped by developers - and why. Is there some compromise possible where a somewhat vetted, packaged release exists? Or RedHat gets appropriate bug reports so they fix the broken parts?
Redhat had more than 100 bugs filed against the "cdrtools" version they ship. All these bugs could be avoided by upgrading to a recent original version. Redhat closed these unfixed bugs instead of doing it's homework that would result in updated versions.
So it seems that redhat doesn't care about bug reports.
Jörg
On Mon, Aug 19, 2013 at 3:54 PM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Would you like to run a Linux kernel from 2004 today?
Has the CD format changed since 2004?
This is why you are happy with buggy software from 2004 shipped by redhat when there is software with no known bugs?
This isn't aimed at you personally, but the reason people like RHEL/CentOS is that the 'no known bugs' status of a developer's software release often turns pretty quickly into 'bugs with no known fix' when they hit a wider distribution. And developers like to change things in ways that break existing interfaces in what they think are improvements.
Redhat had more than 100 bugs filed against the "cdrtools" version they ship. All these bugs could be avoided by upgrading to a recent original version. Redhat closed these unfixed bugs instead of doing it's homework that would result in updated versions.
So it seems that redhat doesn't care about bug reports.
You are in a better position to judge that than me, but the whole point of RHEL is to never break exiting, previously working interfaces (and thus their user's programs...) within the life cycle of the distro. So if they would lose backwards compatibility anywhere by updating - and perhaps even if it isn't clear that they wouldn't, they they are correctly following the policy that the people on this list typically want. Othewise we'd be off reinstalling todays new and buggy version of some other disto instead of reading email while our servers keep working. But, maybe it's not so great for desktop type activity that wasn't feature-complete in 2004. And if you are talking about bug reports that were made long enough before the 6.0 release to have gotten the update in, then I'd say you are right regardless of compatibility.
Les Mikesell lesmikesell@gmail.com wrote:
On Mon, Aug 19, 2013 at 3:54 PM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Would you like to run a Linux kernel from 2004 today?
Has the CD format changed since 2004?
This is why you are happy with buggy software from 2004 shipped by redhat when there is software with no known bugs?
This isn't aimed at you personally, but the reason people like RHEL/CentOS is that the 'no known bugs' status of a developer's software release often turns pretty quickly into 'bugs with no known fix' when they hit a wider distribution. And developers like to change things in ways that break existing interfaces in what they think are improvements.
The Linux kernel and Linux distros are known for breaking things by e.g. changing interfaces.
Cdrtools are known for stability and backwardscompatibility while at the same time enhancing functionality.
Redhat had more than 100 bugs filed against the "cdrtools" version they ship. All these bugs could be avoided by upgrading to a recent original version. Redhat closed these unfixed bugs instead of doing it's homework that would result in updated versions.
So it seems that redhat doesn't care about bug reports.
You are in a better position to judge that than me, but the whole point of RHEL is to never break exiting, previously working interfaces (and thus their user's programs...) within the life cycle of the distro. So if they would lose backwards compatibility anywhere by updating - and perhaps even if it isn't clear that they wouldn't, they they are correctly following the policy that the people on this list typically want. Othewise we'd be off reinstalling todays new and buggy version of some other disto instead of reading email while our servers keep working. But, maybe it's not so great for desktop type activity that wasn't feature-complete in 2004. And if you are talking about bug reports that were made long enough before the 6.0 release to have gotten the update in, then I'd say you are right regardless of compatibility.
I am talking about obvious bugs that apply to the redhat version but not to the original code. I am talking about closing unfixed bugs instead of upgrading to newer versions. I am talking abut redhat that is not doing it's homeworks.
People complain about problems and redhat is ignoring them even though the bug reports contain comments that make it obvious that the right way to deal with the bug is to upgrade to a more recent version. Nothing happens and after a few years the bugs are closed even thoug the bug still exists on redhat.
Jörg
On Mon, Aug 19, 2013 at 5:36 PM, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
This isn't aimed at you personally, but the reason people like RHEL/CentOS is that the 'no known bugs' status of a developer's software release often turns pretty quickly into 'bugs with no known fix' when they hit a wider distribution. And developers like to change things in ways that break existing interfaces in what they think are improvements.
The Linux kernel and Linux distros are known for breaking things by e.g. changing interfaces.
Yes, that is true in general. RHEL (and thus CentOS) are known for _not_ changing interfaces within the supported life of each major release version. It is extremely rare for any previously working program to be broken by an OS update over that many-year span. And that is a good thing - and why they are popular.
Cdrtools are known for stability and backwardscompatibility while at the same time enhancing functionality.
That stops a little short of saying they would be fully compatible with any previous invocation or library linkage.
I am talking about obvious bugs that apply to the redhat version but not to the original code. I am talking about closing unfixed bugs instead of upgrading to newer versions. I am talking abut redhat that is not doing it's homeworks.
Part of the story must be missing here - why does a broken version exist in the first place and why would RedHat have picked it?
On 2013-08-19, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Redhat had more than 100 bugs filed against the "cdrtools" version they ship. All these bugs could be avoided by upgrading to a recent original version. Redhat closed these unfixed bugs instead of doing it's homework that would result in updated versions.
So it seems that redhat doesn't care about bug reports.
None of this is helpful to the OP. You should either point him to your preferred location for acquiring your version of cdrtools, or provide a yum repository for RHEL/CentOS users to download rpms. You should warn him that either of these methods will "officially" break binary compatibility with upstream (which users need to decide for themselves if they wish to do that).
--keith
Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On 2013-08-19, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
Redhat had more than 100 bugs filed against the "cdrtools" version they ship. All these bugs could be avoided by upgrading to a recent original version. Redhat closed these unfixed bugs instead of doing it's homework that would result in updated versions.
So it seems that redhat doesn't care about bug reports.
None of this is helpful to the OP. You should either point him to your preferred location for acquiring your version of cdrtools, or provide a yum repository for RHEL/CentOS users to download rpms. You should warn him that either of these methods will "officially" break binary compatibility with upstream (which users need to decide for themselves if they wish to do that).
Please do not write false claims!
If you know about problems, send evidence
There are more then 100 bug reports in the redhat bugtracking system (just change your view to see all closed but unfixed bugs) that confirm problems with the binaries distributed by redhat and the users who reported the bugs confirmed that upgrading to recent original software fixed the problem.
It is pretty obvious that redhat does not care about it's users...
Jörg
On 2013-08-19, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
If you know about problems, send evidence
The problem seems to be that you would rather rant about distributions' licensing and packaging decisions than help the OP. It seems like he would be perfectly happy to use your version of cdrtools, yet you insist on not telling him how to get it!
There are more then 100 bug reports in the redhat bugtracking system (just change your view to see all closed but unfixed bugs) that confirm problems with the binaries distributed by redhat and the users who reported the bugs confirmed that upgrading to recent original software fixed the problem.
It is pretty obvious that redhat does not care about it's users...
Still, none of this solves the OP's problem! You do yourself and your software a disservice by being deliberately unhelpful to score political points. (Perhaps that is why distros are reluctant to include your software, preferring a buggy version to one with a difficult author.)
--keith
Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
On 2013-08-19, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
If you know about problems, send evidence
The problem seems to be that you would rather rant about distributions' licensing and packaging decisions than help the OP. It seems like he would be perfectly happy to use your version of cdrtools, yet you insist on not telling him how to get it!
???
I told him that if his distro does not do it's homework, he needs to compile himself. The URL is in my signature and in contrary to many autoconf based sources, my software compiles out if the box by just calling "make".
There are more then 100 bug reports in the redhat bugtracking system (just change your view to see all closed but unfixed bugs) that confirm problems with the binaries distributed by redhat and the users who reported the bugs confirmed that upgrading to recent original software fixed the problem.
It is pretty obvious that redhat does not care about it's users...
Still, none of this solves the OP's problem! You do yourself and your software a disservice by being deliberately unhelpful to score political points. (Perhaps that is why distros are reluctant to include your software, preferring a buggy version to one with a difficult author.)
As mentioned before: I deliver something that compiles and runs out of the box on aprox. 30 OS platforms (not counting the CPU and OS-version variants). It is not my duty to deliver binary packages for more than 100 OS/CPU variants.
Jörg
On 08/20/2013 04:57 AM Joerg Schilling wrote:
I told him that if his distro does not do it's homework, he needs to compile himself. The URL is in my signature and in contrary to many autoconf based sources, my software compiles out if the box by just calling "make".
Joerg,
Wouldn't doing this cause conflicts with existing libraries?
Will the many apps which depend upon the existing code-- e.g., grip, k3b, gnome-cd-- still work after installing your software?
On 2013-08-20, ken gebser@mousecar.com wrote:
Will the many apps which depend upon the existing code-- e.g., grip, k3b, gnome-cd-- still work after installing your software?
You can install Joerg's version to someplace separate, like /usr/local, then test those dependent apps against the /usr/local version. I do not use these programs, so I don't know exactly how they work--if they are built against cdrecord libraries, this process might be challenging, but if they are just calling external helper programs it might be easy to configure e.g. k3b to use the /usr/local versions.
I hope that's helpful.
--keith
On 08/20/2013 10:33 PM Keith Keller wrote:
On 2013-08-20, ken gebser@mousecar.com wrote:
Will the many apps which depend upon the existing code-- e.g., grip, k3b, gnome-cd-- still work after installing your software?
You can install Joerg's version to someplace separate, like /usr/local, then test those dependent apps against the /usr/local version. I do not use these programs, so I don't know exactly how they work--if they are built against cdrecord libraries, this process might be challenging, but if they are just calling external helper programs it might be easy to configure e.g. k3b to use the /usr/local versions.
I hope that's helpful.
--keith
Keith,
Thanks for the suggestion. Yes, that would work. But then I'm pretty sure that I'd also need to compile (from source) all (or most) of the dependent apps (grip, k3b, gnome-cd, etc.) so that they would look to /usr/local/* for supporting libraries and utilities (Joerg's code). But then other supporting libraries-- e.g., for creating and managing the GUI-- would use the already existing libraries not under /usr/local/, so there'd be quite a bit of tinkering involved. I haven't actually looked at the code for all these apps, so I'm just guessing based on past experience.
Then too of course there'd need to be a way to ascertain if there was any substantial differences in the outputs. There's some code out there since kernel version 2.2 called cdfs which doesn't seem to be on my (v.5.9) system. This allows mounting an audio CD or a disk image of one so that it can be examined and, presumably, manipulated. In fact, maybe this is all I need at the moment... that is, after cloning the CD to a disk image, it might be possible to edit the track data prior to burning. I don't burn CDs that often, so this would be an acceptable solution.
Yeah, it might be nice if Joerg's code were incorporated, but I really don't know. I have to think that RH has their reasons. I'd hope that in this FOSS age they'd be purely technical, but who the heck knows? Does Debian use the post-2004 code? And if not, why not? Lotsa questions.
Me, I just wanted to both rip and clone four music CDs. Grip handled ripping all four just fine. k3b cloned the last two fine, but not the first two. With the last two, gnome-cd displays the cddb data, but I don't think it's getting it from the CD itself, though I could be wrong about that. Again, cdfs would be a nice tool to have here. But hacking code and research and testing is much more than I want to get into just to be able to burn a few CDs.
Greets, ken
ken gebser@mousecar.com wrote:
Then too of course there'd need to be a way to ascertain if there was any substantial differences in the outputs. There's some code out there since kernel version 2.2 called cdfs which doesn't seem to be on my (v.5.9) system. This allows mounting an audio CD or a disk image of one so that it can be examined and, presumably, manipulated. In fact, maybe this is all I need at the moment... that is, after cloning the CD to a disk image, it might be possible to edit the track data prior to burning. I don't burn CDs that often, so this would be an acceptable solution.
This cdfs does not deliver better quality than from using the "read audio" ioctls from the kernel. Cdda2wav gives much better quylity in case of non-optiimal media and cdda2wav gives you the meta data you need to make a decent copy. You don't get that from cdfs.
Jörg
On 08/21/2013 07:53 AM Joerg Schilling wrote:
ken gebser@mousecar.com wrote:
Then too of course there'd need to be a way to ascertain if there was any substantial differences in the outputs. There's some code out there since kernel version 2.2 called cdfs which doesn't seem to be on my (v.5.9) system. This allows mounting an audio CD or a disk image of one so that it can be examined and, presumably, manipulated. In fact, maybe this is all I need at the moment... that is, after cloning the CD to a disk image, it might be possible to edit the track data prior to burning. I don't burn CDs that often, so this would be an acceptable solution.
This cdfs does not deliver better quality than from using the "read audio" ioctls from the kernel. Cdda2wav gives much better quylity in case of non-optiimal media and cdda2wav gives you the meta data you need to make a decent copy. You don't get that from cdfs.
Jörg
CDfs allows mounting a CD with something like:
# mount -t cdfs -o ro /dev/cdrom /mnt/cdfs
[From http://users.elis.ugent.be/~mronsse/cdfs/.]
How would a person mount a CD using the software mentioned above (if that would be possible at all)?
Also, I haven't been able to find cdfs in 5.9. Is it to be found in a later version?
From: ken gebser@mousecar.com
CDfs allows mounting a CD with something like:
# mount -t cdfs -o ro /dev/cdrom /mnt/cdfs
[From http://users.elis.ugent.be/~mronsse/cdfs/.]
How would a person mount a CD using the software mentioned above (if that would be possible at all)?
Also, I haven't been able to find cdfs in 5.9. Is it to be found in a later version?
It seems a bit old... Did you read the INSTALL file?
JD
On 08/26/2013 04:46 AM John Doe wrote:
From: ken gebser@mousecar.com
CDfs allows mounting a CD with something like:
# mount -t cdfs -o ro /dev/cdrom /mnt/cdfs
[From http://users.elis.ugent.be/~mronsse/cdfs/.]
How would a person mount a CD using the software mentioned above (if that would be possible at all)?
Also, I haven't been able to find cdfs in 5.9. Is it to be found in a later version?
It seems a bit old... Did you read the INSTALL file?
JD
JD,
This is a CentOS list. I was assuming everyone would understand I was talking about a CentOS package. So I wasn't talking about installing from sources. This wouldn't be the correct list to ask about that anyway.
As for it's being "a bit old", if software works and does a job that's needed, what does it matter if it's "old"? Maybe that just means no bugs have been found in it, so it hasn't been necessary to update it, make it *newer*. E.g., the "cat" command is also quite old. Should we on that account be dismissive of it as well? Should we not install it because it's "old"?
That said, I have to ask you if you read the (rather short) webpage I gave the URL for? There it states there is a version of cdfs for kernel version 2.6.27, which is more recent than the latest from CentOS (for v.5.9 at any rate). So by what measure is cdfs "old" (if "old" were a meaningful measure of anything)?
Sorry to be so frank, but it was doubtful that subtler language would be effective, I've heard this glib Tier 1 mantra already quite enough in this lifetime, and would very much like to dispel this and similar noetic cruft in hopes of actually engaging the relevant technological issues.
Now back to the original question: Is cdfs available in CentOS...? or is there perhaps another way to mount audio CDs?
From: ken gebser@mousecar.com
This is a CentOS list. I was assuming everyone would understand I was talking about a CentOS package.
Sorry, my crystal ball is not working today... Good luck anyway (meaning despite your "frank" attitude).
JD
On 08/21/2013 07:53 AM Joerg Schilling wrote:
ken gebser@mousecar.com wrote:
Then too of course there'd need to be a way to ascertain if there was any substantial differences in the outputs. There's some code out there since kernel version 2.2 called cdfs which doesn't seem to be on my (v.5.9) system. This allows mounting an audio CD or a disk image of one so that it can be examined and, presumably, manipulated. In fact, maybe this is all I need at the moment... that is, after cloning the CD to a disk image, it might be possible to edit the track data prior to burning. I don't burn CDs that often, so this would be an acceptable solution.
This cdfs does not deliver better quality than from using the "read audio" ioctls from the kernel. Cdda2wav gives much better quylity in case of non-optiimal media and cdda2wav gives you the meta data you need to make a decent copy. You don't get that from cdfs.
Jörg
I was asking about *mounting* an audio CD. Is there a way to mount an audio CD in any of the software you mentioned?
ken gebser@mousecar.com wrote:
This cdfs does not deliver better quality than from using the "read audio" ioctls from the kernel. Cdda2wav gives much better quylity in case of non-optiimal media and cdda2wav gives you the meta data you need to make a decent copy. You don't get that from cdfs.
Jörg
I was asking about *mounting* an audio CD. Is there a way to mount an audio CD in any of the software you mentioned?
No, but why do you like to "mount" an audio CD?
Jörg
On 08/26/2013 09:33 AM Joerg Schilling wrote:
ken gebser@mousecar.com wrote:
This cdfs does not deliver better quality than from using the "read audio" ioctls from the kernel. Cdda2wav gives much better quylity in case of non-optiimal media and cdda2wav gives you the meta data you need to make a decent copy. You don't get that from cdfs.
Jörg
I was asking about *mounting* an audio CD. Is there a way to mount an audio CD in any of the software you mentioned?
No, but why do you like to "mount" an audio CD?
Jörg
I gave a couple reasons previously in this thread... too involved to repeat. There must be a lot of other reasons if so many people have spent time developing cdfs for so long a time.
On 8/26/2013 5:41 AM, ken wrote:
I was asking about*mounting* an audio CD. Is there a way to mount an audio CD in any of the software you mentioned?
there are no 'files' on a Audio CD. you can mount an iso 9660 (or UDF etc) file system, but those don't exist on an Audio CD.
On 08/26/2013 02:50 PM John R Pierce wrote:
On 8/26/2013 5:41 AM, ken wrote:
I was asking about*mounting* an audio CD. Is there a way to mount an audio CD in any of the software you mentioned?
there are no 'files' on a Audio CD. you can mount an iso 9660 (or UDF etc) file system, but those don't exist on an Audio CD.
Yes, that's all true... and why all the other fstypes don't work for mounting audio CDs (and video DVDs).
On 8/26/2013 12:22 PM, ken wrote:
Yes, that's all true... and why all the other fstypes don't work for mounting audio CDs (and video DVDs).
actually, video DVD's use UDF, and store the video streams in UDF named files. now, most commercial video DVDs are copy protected, so you can't actually READ those files unless you play the CSS dance with the drive.
On 2013-08-21, ken gebser@mousecar.com wrote:
Thanks for the suggestion. Yes, that would work. But then I'm pretty sure that I'd also need to compile (from source) all (or most) of the dependent apps (grip, k3b, gnome-cd, etc.) so that they would look to /usr/local/* for supporting libraries and utilities (Joerg's code).
Like I said, I don't use k3b and friends. But from what I remember of it from a while back, it was configured to explicitly call (e.g.) /usr/bin/cdrecord, so it wasn't linked to cdrtools libraries directly. If that is the case now, then you could configure k3b to use your version of cdrecord instead, without needing to recompile (because in theory the GUI should not depend on cdrtools libs).
It's worth investigating. If k3b does indeed compile against cdrtools libraries then you may be out of luck.
--keith
Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
It's worth investigating. If k3b does indeed compile against cdrtools libraries then you may be out of luck.
Writing optical media is a task that needs special privileges. Calling e.g. cdrecord as a separate program gives prilviege separation and prevents you from being forced to do a security audit on higly complex GUI.
The main problem wth k3b is that it does not support feature enhancements implemented during the past 10 years.
It is e.g. a pitty that there is no support for the libfind based features in mkisofs. It would be a real challenge for a GUI writer to implement GUI support for something like find(1). So this is even expected to give fun to the author!
Jörg
ken gebser@mousecar.com wrote:
On 08/20/2013 04:57 AM Joerg Schilling wrote:
I told him that if his distro does not do it's homework, he needs to compile himself. The URL is in my signature and in contrary to many autoconf based sources, my software compiles out if the box by just calling "make".
Joerg,
Wouldn't doing this cause conflicts with existing libraries?
Why do you believe this? Do you believe that centos delivers inconstsistent libraries?
Will the many apps which depend upon the existing code-- e.g., grip, k3b, gnome-cd-- still work after installing your software?
My software delivers nackwards compatible interfaces: it enhances but it does not break things.
Jörg
On 8/21/2013 4:15 AM, Joerg Schilling wrote:
Why do you believe this? Do you believe that centos delivers inconstsistent libraries?
if you replace the stuff thats under RPM package management with code you self compile and simply copy, you break the package management system. an update might come along and not realize your code is in the place of the original RPM supplied files and replace them.
btw, are /any/ CDDL components bundled with major linux distributions? I know Sun Java was never bundled due to CDDL entanglement, instead we have OpenJDK, which is GPL.
On Wed, Aug 21, 2013 at 1:25 PM, John R Pierce pierce@hogranch.com wrote:
On 8/21/2013 4:15 AM, Joerg Schilling wrote:
Why do you believe this? Do you believe that centos delivers inconstsistent libraries?
if you replace the stuff thats under RPM package management with code you self compile and simply copy, you break the package management system. an update might come along and not realize your code is in the place of the original RPM supplied files and replace them.
btw, are /any/ CDDL components bundled with major linux distributions? I know Sun Java was never bundled due to CDDL entanglement, instead we have OpenJDK, which is GPL.
I'm pretty sure there was a point where Sun Java was in the Red Hat subscription update streams, but not in the publicly available src rpms. And debian included it. Not sure about the status now.
John R Pierce pierce@hogranch.com wrote:
On 8/21/2013 4:15 AM, Joerg Schilling wrote:
Why do you believe this? Do you believe that centos delivers inconstsistent libraries?
if you replace the stuff thats under RPM package management with code you self compile and simply copy, you break the package management system. an update might come along and not realize your code is in the place of the original RPM supplied files and replace them.
You cannot break something that is broken already. A distro that ignores updates since nearly 10 year is definitely broken.
btw, are /any/ CDDL components bundled with major linux distributions? I know Sun Java was never bundled due to CDDL entanglement, instead we have OpenJDK, which is GPL.
Of course. The CDDL is one of the 8 major OSS licenses.
Jörg
On 08/20/2013 04:57 AM Joerg Schilling wrote:
As mentioned before: I deliver something that compiles and runs out of the box on aprox. 30 OS platforms (not counting the CPU and OS-version variants). It is not my duty to deliver binary packages for more than 100 OS/CPU variants.
Jörg
Why not just create one RPM package for i386...? This would/should run on a whole lot of linux boxes and if, as you claim, it overcomes a lot of bugs and adds so much more functionality and documentation, then the word will get out about it and people will clamor for it. This would speak much more loudly and convincingly than all your posts here.
ken gebser@mousecar.com wrote:
On 08/20/2013 04:57 AM Joerg Schilling wrote:
As mentioned before: I deliver something that compiles and runs out of the box on aprox. 30 OS platforms (not counting the CPU and OS-version variants). It is not my duty to deliver binary packages for more than 100 OS/CPU variants.
Jörg
Why not just create one RPM package for i386...? This would/should run on a whole lot of linux boxes and if, as you claim, it overcomes a lot of bugs and adds so much more functionality and documentation, then the word will get out about it and people will clamor for it. This would speak much more loudly and convincingly than all your posts here.
You are of course welcome to create such a pacjage!
Jörg
Keith,
I was wondering if anyone would notice. Thanks.
ken (the OP)
On 08/19/2013 07:38 PM Keith Keller wrote:
On 2013-08-19, Joerg Schilling Joerg.Schilling@fokus.fraunhofer.de wrote:
If you know about problems, send evidence
The problem seems to be that you would rather rant about distributions' licensing and packaging decisions than help the OP. It seems like he would be perfectly happy to use your version of cdrtools, yet you insist on not telling him how to get it!
There are more then 100 bug reports in the redhat bugtracking system (just change your view to see all closed but unfixed bugs) that confirm problems with the binaries distributed by redhat and the users who reported the bugs confirmed that upgrading to recent original software fixed the problem.
It is pretty obvious that redhat does not care about it's users...
Still, none of this solves the OP's problem! You do yourself and your software a disservice by being deliberately unhelpful to score political points. (Perhaps that is why distros are reluctant to include your software, preferring a buggy version to one with a difficult author.)
--keith
ken gebser@mousecar.com wrote:
Keith,
I was wondering if anyone would notice. Thanks.
what problem do you have? You have been pointed to compile and install recent original software. Did you do that?
Jörg
-
Joerg Schilling -
John Doe -
John R Pierce -
Keith Keller -
ken -
Les Mikesell