Re: [linux-audio-dev] cdparanoia fails / audiofile comparer

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] cdparanoia fails / audiofile comparer
From: Fred Gleason (fredg_AT_salemradiolabs.com)
Date: Mon Dec 15 2003 - 23:45:26 EET


On Monday 15 December 2003 15:37, Juhana Sadeharju wrote:

> I ripped a CD two times with the following results:
> (== PROGRESS == [ !-------| 159332 00 ] == :^D * ==)
> (== PROGRESS == [ + + + | 159332 00 ] == :^D * ==)
>
> The errors are explaned this way:
> - Jitter correction required
> + Unreported loss of streaming/other error in read
> ! Errors are getting through stage 1 but corrected in stage2

The bottom line: your CD reader is too broken to reliably rip audio. In
particular, the 'unreported loss of streaming' error indicates buggy firmware
in the drive. For a fuller explanation of all this, see:

        http://www.xiph.org/paranoia/faq.html#play

Very informative discussion of the challenges involved in accurately ripping
CDs.

> Which error is more severe: "+" or "!"?
> Is "+" corrected properly?

Who knows? That's the whole problem -- basically the drive's firmware is
lying to the kernel's CDROM layer at this point, by reporting "everything is
fine" when in fact it has lost streaming.

> Also an audiofile comparer program would be great to have: a program
> which finds matching regions. Now it was easy to compare the regions
> up to the "!" point with md5sum program, but it was difficult to compare
> the end part due misaligning. I compared them visually at a few random
> points. In such a comparer program each matching sample would match
> bitwise for this application, but they could match with an error tolerance
> if the application is to compare an original audio and an edited audio
> which is affected by dither noise (say). So, such a comparer would
> reveal what edits were done in an audio editor -- I have needed such
> a program a few times earlier.

AFAIK Paranoia actually contains such code -- it's how it detects the
"unreported loss of streaming" in the first place, by sensing that the sector
overlaps don't match. How usable this would be for the more general case you
posit is uncertain.

Cheers!

|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Director of Broadcast Software Development |
| | Salem Radio Labs |
|-------------------------------------------------------------------------|
| Nothing ever becomes real till it is experienced -- even a proverb is |
| no proverb to you till your life has illustrated it. |
| -- John Keats |
|-------------------------------------------------------------------------|


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Dec 15 2003 - 23:49:08 EET