From merlijn at archive.org  Thu Apr 23 09:07:45 2020
From: merlijn at archive.org (Merlijn B.W. Wajer)
Date: Thu, 23 Apr 2020 11:07:45 +0200
Subject: [Paranoia] Specify max amount of re-read or corrections (per
 sector) in paranoid mode?
In-Reply-To: <79aaa92a-cba4-5bf2-68bb-f690e3a95cfe@archive.org>
References: <79aaa92a-cba4-5bf2-68bb-f690e3a95cfe@archive.org>
Message-ID: <622eec9b-40e2-2f40-bc1a-7c137a41e3f4@archive.org>

Hi,

I made some progress, looks like it's a bug in paranoia/paranoia.c --

On 31/03/2020 16:46, Merlijn B.W. Wajer wrote:
> Hi,
> 
> I was wondering if anyone had any insight into limiting the amount of
> re-reads and corrections cdparanoia will attempt to do for a single
> sector (or at an even lower level). I find that for quite some CDs,
> cdparanoia will try re-reading specific parts many, many times.
> 
> I've logged all the callbacks with --stderr-progress, mapped "cdframes"
> to sectors to seconds of an audio CD, and for some parts, over 700000
> correction() callbacks are issued for a single second (so 75 seconds).
> 
> Ripping a CD (in some cases) in it's entirety takes over 7 hours.
> Ripping the same CD without any paranoia (-Z or -Y) will often finish
> within minutes. Around the sectors that are problematic, the no-paranoid
> mode will usually sound worse, and sometimes entire samples are gone.
> 
> So there is a clear advantage to using paranoia, but I can't help but
> wonder if 7000000 reads and corrections are really required for a single
> second of audio. Is there a way to set a cap on the amount of retries
> for any given sector, so that I can attempt to strike a balance between
> quality and time spent ripping? [1]

It looks like --never-skip=N only works if N is a multitude of 5. This
is due to a bug in the paranoia code, as far as I can tell..

In paranoia_read_limited, when retry_count is incremented, the following
check is used (code typed here by hand):

if (retry_count % 5 == 0) {
    if (p->dynoverlap == MAX_SECTOR_OVERLAP * CD_FRAMEWORDS ||
retry_count == max_retries) {
        /* Actually skip */
    }
}

This is problematic in two ways. First of all, it doesn't allow
--never-skip=N to skip before hitting N=5, but even worse, this part
will often fail if max_retries not a multitude of 5 (depending on the
dynoverlap value as well):

... || (retry_count == max_retries)


After fixing the code, I can now provide values like --never-skip=1 and
--never-skip=2 and they work as expected, which means I can continue
with my tests [*].

So - do others also perceive this as a bug, or a feature that I am not
quite aware of yet?


Cheers,
Merlijn



[*]

--never-skip=1 really means it doesn't retry even once, but still does a
better job than --disable-paranoia, and it's basically just as fast.

--never-skip=2 does a much better job of retrying, but also takes 27
minutes on this one track, as opposed to the 18 seconds that
--never-skip=1 took - and I can't hear the difference. (Of course, all
of this heavily depends on ones use cases, but for _audio book CDs_ the
"100% accurate part" might matter a little less, but actual skipping is
problematic). And in the cases where I ran with the default
--never-skip=20, the results per rip were still different, anyway.