Jorge Almeida <jjalmeida@xxxxxxxxx> wrote:
> On Wed, Sep 14, 2011 at 4:52 PM, Joerg Schilling
> <Joerg.Schilling@xxxxxxxxxxxxxxxxxxx> wrote:
>
> > results. If you like to most agressive parameters, I recommend to call:
> >
> > cdda2wav paraopts=proof
>
> I'll keep this one in mind for next time.
This is thwe latest important change incdda2wav and it allows to use a value
that would need a second run if you like to do things manually: paraopts=proof
means use overlap that is maxtransfer - 1 sector.
> > This just verifies that cdparanoia doesn't inform you about the problems.
> >
>
> Nevertheless, it did inform about the two small problems corresponding to '+' ("
> Unreported loss of streaming/other error in read"), which disappeared
> when I repeated the ripping with speed 1.
Did you also tell cdda2wav to use speed=1?
If you cannot repeat this now, it would be impossible to find the reason now.
> Of course. What I do is to extract it all ("-B") and then try again
> for each track that didn't came out perfect ("-t n"). I even have the
> feeling that it may get better after letting the drive resting for a
> while, maybe heat is a problem...
Temparature influences results.
> > Before 2006, cdda2wav did not enable dynamic overlap with libparanoia.
> > This may cause different results.
> >
> Can you positively confirm that there are no different algorithms in
> the two programs that might sometimes have influence? I used the
> current version from the Arch (extra/cdparanoia 10.2-3), which I
> suppose is not the one you mean.
I fixed some bugs in cdparanoia (e.g. a buffer overflow problem and some
problems in the code that creates the statistics).
These problems most likely still exist in cdparanoia.
Also note that cdparanoia uses the kernel interface to read audio data. This
results in fewer reported errors and in worse data in some cases.
The kernel uses simpler code and does not evaluate all error information that
is checked by cdda2wav.
The error report written by cdda2wav is a result of many tests with bad CDs
that include listening to the results.
Jörg
--
EMail:joerg@xxxxxxxxxxxxxxxxxxxxxxxxxxx (home) Jörg Schilling D-13353 Berlin
js@xxxxxxxxxxxxxxx (uni)
joerg.schilling@xxxxxxxxxxxxxxxxxxx (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
