Comments below. On Thu, Feb 24, 2011 at 7:16 AM, Bastiaan Timmer <[email protected]>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 > [email protected] > http://lists.gnu.org/mailman/listinfo/libcdio-help >
_______________________________________________ Libcdio-help mailing list [email protected] http://lists.gnu.org/mailman/listinfo/libcdio-help
