On Thu, Feb 24, 2011 at 7:16 AM, Bastiaan Timmer
<address@hidden> wrote:
Hi! I am thinking about writing a simple cd-ripping application which checks ripping results against the AccurateRip database. The code for checking the AR database is already finished, and now I am just trying to find out what my options are for the CD-extraction, and how hard it is going to be.
Now I've ripped a CD with several different programs: Exact Audio Copy (under windows), cdparanoia (from xiph), cd-read (from libcdio), cued (with and without the -p switch for paranoia) and the 'paranoia.c' example from libcdio (slightly adjusted to rip the entire disc and dump to file). After ripping I adjusted some of the files, where the program didn't take option for it, to adjust for my drive read-offset (24 bytes) and prepend a wave header.
When checking the resulting rips, the results of EAC, cdparanoia, cued without paranoia and cd-read are exactly the same (md5 hashed) and reported 100% accurate by the AR db.
The rips from cued with paranoia and the paranoia.c example are also identical, but fail the AR check on a couple tracks with identical 'bad' CRCs. All of these rips are completely reproducible by the five programs.
Now, seeing as cued (-p) and the example program both use cdio_paranoia_read() to read the disc, while the others do not, can it be said that cdio_read_sector() is a better read function?
I thought the paranoia functions were supposed to be more likely to give error free rips.
What is actually the difference between cdio_read_sector() and cdio_paranoia_read(), and why and how would one choose between them?
cdio_read_sector() doesn't try to do any verification or correction of data while cdio_paranoia_read() and uses cdio_sector_read() and then tries to adjust the data assuming it is an audio sample.
So if what you start out with is a perfect read of data, then cdio_paranoia_read() can only mangle this. Another interesting question though is whether it mangles it in an audibly noticeable way. For example it could replace one kind of silence with another kind.
That cdparanoia is more accurate is interesting and suggests that the port to libcdio is not as good as it could be.
And are there more read functions to consider?
cdio_read_sector() is a wrapper around a lower-level read command. When available, it uses MMC (multi-media command), which is a standard for issuing commands to devices. See
http://www.t10.org/drafts.htm#MMC_Family
The MMC library, when available depending on OS, allows one to roll one's own command. So another possibility is to look over the various MMC commands and try those.
However if you go this route and find something ultimately useful, I'd ask you consider wrapping it up as a function which could be included back in with the distribution.
How does xiph's paranoia compare to libcdio various read functions?
From what you report xiph's paranoia on surface is better. (Ouch -- unintended pun).
My understanding is that the most recent changes to paranoia were more centered around making better use of the system calls provided by more recent GNU/Linux OS's which give access to or information on things like the drive's track caching mechanism.
libcdio tries to wrap the OS-level access, but it doesn't have anything for things like track caches. And a main focus of libcdio was to give user-level access that what had before been only privileged access. That is, ripping software had to be installed as root and some sort of root-level privilege was needed to run it, so it either had to be a set-uid program or you had to be in some sort of special group on Unix.
Alas there's been somewhat of a conflict, since OS's have been tending over time to consider drive access as something privileged, especially say on OSX.
xiph's paranoia is only supported on GNU/Linux. There are ports of it for other OS's, but I believe these efforts are individual and uncoordinated. And as such I don't think they have been tracking those recent improvements to xiph, because those improvements tend to be OS specific.
On an unrelated note, I think I found an insignificant mistake in the cd-read.c source. At line 437 it says "end LSN (%lu) needs to be less than start LSN", which I think should say bigger/greater than.
Yes, you are correct
Obviously, it does not affect program execution.
Nevertheless it's wrong. So I've corrected it in the git repository. Many thanks. libcdio improves by the support of those who use it.
Thanks,
Bas Timmer
_______________________________________________
Libcdio-help mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/libcdio-help