public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Brad Campbell <brad@wasp.net.au>
Cc: linux-kernel@vger.kernel.org, Sebastian <sebastian_ml@gmx.net>
Subject: Re: Digital Audio Extraction with ATAPI drives far from perfect
Date: Mon, 9 Jan 2006 10:30:25 +0100	[thread overview]
Message-ID: <20060109093025.GO3389@suse.de> (raw)
In-Reply-To: <43C00C32.9050002@wasp.net.au>

On Sat, Jan 07 2006, Brad Campbell wrote:
> Sebastian wrote:
> >(please, don't forget to me and axboe@suse.de)
> 
> Did I? I'm sorry, I was *sure* I hit reply-to-all.
> 
> >>Yes, but now we need to find out why one interface fails while another 
> >>works.. I have the same problem here using cdrdao when ripping entire 
> >>disk images. I'd love to fix the real issue rather than work around it by 
> >>having userspace use another interface.
> >>I would have thought that both interfaces should return the same data..
> >>
> >>Brad
> >
> >I think cdrdao can use SG_IO if you tell it to. Check their documentation. 
> >Or did I misunderstand what you're saying?
> 
> Slightly.. If I'm not mistaken, we have a piece of software (for arguments 
> sake let's call it cdparanoia). The stock software uses the ATA or ATAPI 
> interface and produces bodged reads, the modified version you have uses 
> SG_IO and produces accurate reads.

It's the cdrom CDROMREADAUDIO vs SG_IO interface, there's not ata/atapi
specific interface.

> What I'm wondering is why the difference, and is there a problem with the 
> ATA/ATAPI interface that leads to this that needs looking into.

Definitely, that's the big question. It could just be that cdparanoia
enables extra error correction/checking, which it can do since it
tailors the SCSI commands to its liking. Where as with CDROMREADAUDIO,
you're basically stuck with whatever is coded into the cdrom layer.

> *or* is it an inherent problem/limitation with that particular interface

Could very well be. Once could use blktrace to see what the commands
submitted to the drives look like and get some data out of that.

Sebastian, care to try one more thing? Patch your kernel with this
little patch and try ripping a known "faulty" track again _not_ using
SG_IO. See if that produces the same faulty results again, or if it
actually works.

diff --git a/drivers/cdrom/cdrom.c b/drivers/cdrom/cdrom.c
index 1539603..2e44d81 100644
--- a/drivers/cdrom/cdrom.c
+++ b/drivers/cdrom/cdrom.c
@@ -426,7 +426,7 @@ int register_cdrom(struct cdrom_device_i
 		cdi->exit = cdrom_mrw_exit;
 
 	if (cdi->disk)
-		cdi->cdda_method = CDDA_BPC_FULL;
+		cdi->cdda_method = CDDA_BPC_SINGLE;
 	else
 		cdi->cdda_method = CDDA_OLD;
 

-- 
Jens Axboe


  reply	other threads:[~2006-01-09  9:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-03 22:20 Digital Audio Extraction with ATAPI drives far from perfect Sebastian
2006-01-04  9:20 ` Jens Axboe
2006-01-04  9:24   ` Jens Axboe
2006-01-04 15:08     ` Mark Lord
2006-01-04 15:13       ` Jens Axboe
2006-01-04 15:50     ` Sebastian
2006-01-04 19:36       ` Alistair John Strachan
2006-01-04 21:54         ` Sebastian
2006-01-06 13:39       ` jerome lacoste
2006-01-05  6:43     ` Sebastian
2006-01-06  8:06 ` Joshua Kwan
2006-01-06 23:25   ` Sebastian
2006-01-06 23:30     ` Mark Knecht
2006-01-07 10:39       ` Sebastian
2006-01-07 10:56         ` Jens Axboe
2006-01-07 11:00           ` Jens Axboe
2006-01-07 11:53             ` Sebastian
2006-01-07 11:57               ` Jens Axboe
     [not found]           ` <20060107112443.GA18749@section_eight.mops.rwth-aachen.de>
     [not found]             ` <20060107115340.GW3389@suse.de>
     [not found]               ` <20060107115449.GB20748@section_eight.mops.rwth-aachen.de>
     [not found]                 ` <20060107115947.GY3389@suse.de>
2006-01-07 14:08                   ` Sebastian
2006-01-07 14:22                     ` Jens Axboe
2006-01-07 16:06                       ` Sebastian
2006-01-07 17:44                         ` Brad Campbell
2006-01-07 18:02                           ` Sebastian
2006-01-07 18:39                             ` Lee Revell
2006-01-07 18:45                             ` Brad Campbell
2006-01-09  9:30                               ` Jens Axboe [this message]
2006-01-09  9:49                                 ` Sebastian
2006-01-09 10:03                                   ` Jens Axboe
2006-01-10 22:43                                     ` Rene Herman
2006-01-10 22:52                                       ` Lee Revell
2006-01-10 23:05                                         ` Rene Herman
2006-01-07 17:24                       ` Sebastian
2006-01-07 19:18                     ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060109093025.GO3389@suse.de \
    --to=axboe@suse.de \
    --cc=brad@wasp.net.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sebastian_ml@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox