Package: abcde
Version: 2.3.99.6-1
Severity: wishlist

Says here:

    % man abcde | grep -nA 5 LOWDISK | tail -n 6
    456:       LOWDISK
    457-              If set to y, conserves disk space by encoding tracks 
immediately
    458-              after reading them. This is  substantially  slower  than  
normal
    459-              operation but requires several hundred MB less space to 
complete
    460-              the encoding of an entire CD. Use only if your system is 
low  on
    461-              space and cannot encode as quickly as it can read.

Lines #460-461; it says "Use only if...".  However, I've noticed there's
a second reason to use '-l'.

When a disk is badly scratched, ("abnormal operation"?), regular
'abcde' consistently tends to produce more read errors (e.g. 'V' in the
rip progress bar) than 'abcde -l' does.  The '-l' makes the rip better
and often faster.

The cause is that 'cdparanoia' on a scratchy disk is quite timing
sensitive:

  % zgrep -B 3 -A 15 shaking /usr/share/doc/cdparanoia/FAQ.txt.gz
  delicate balance. In addition, a player is never distracted from what
  it's doing... it has nothing else taking up its time. Now add a
  non-realtime, (relatively) high-latency, multitasking kernel into the
  mess; it's like picking up the player and constantly shaking it.

  CDROM drives generally assume that any sort of DAE will be linear and
  throw a readahead buffer at the task. However, the OS is reading the
  data as broken up, separated read requests. The drive is doing
  readahead buffering and attempting to store additional data as it
  comes in off media while it waits for the OS to get around to reading
  previous blocks. Seeing as how, at 36x, data is coming in at
  6.2MB/second, and each read is only 13 sectors or ~30k (due to DMA
  restrictions), one has to get off 208 read requests a second, minimum
  without any interruption, to avoid skipping. A single swap to disc or
  flush of filesystem cache by the OS will generally result in loss of
  streaming, assuming the drive is working flawlessly. Oh, and virtually
  no PC on earth has that kind of I/O throughput; a Sun Enterprise
  server might, but a PC does not. Most don't come within a factor of
  five, assuming perfect realtime behavior.

...so plain old 'abcde' which multitasks the encoding in the background
might consume every CPU clock.  Thus 'cdparanoia' performance degrades,
it thrashes, and after several minutes gives up, and goes on to the
next equally troublesome sector.  Whereas 'abcde -l'
lets 'cdparanoia' single task, (relative to encoding anyway), so
its performance becomes optimal.  

Users: if you have a scratched disk that keeps getting 'V' errors,
try the '-l' switch, and the 'V's may be fewer or go away completely.
AND 'abcde -l' rips faster, because 'cdparanoia' doesn't get so badly
stuck on scratches.

The LOWDISK text in 'man abcde' should make a note of this.  Apologies
to the maintainer for including no patch -- I couldn't think of a
succinct revision, (maybe later!), and this tip is so useful it
deserves to be public now.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages abcde depends on:
ii  cd-discid             0.9-1              CDDB DiscID utility
ii  cdda2wav              9:1.1.6-1          Dummy transition package for iceda
ii  cdparanoia            3.10+debian~pre0-5 audio extraction tool for sampling
ii  flac                  1.1.2-6            Free Lossless Audio Codec - comman
ii  speex                 1.1.12-3           The Speex Speech Codec
ii  vorbis-tools          1.1.1-11+b1        several Ogg Vorbis tools
ii  wget                  1.10.2-2           retrieves files from the web

abcde recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to