Bug 129281

Summary: Audio CD ripping/duplication shouldn't recommend the use of non endianness safe dd/burncd commands
Product: Documentation Reporter: yuri
Component: Books & ArticlesAssignee: Marc Fonvieille <blackend>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description yuri 2008-11-29 21:10:08 UTC
In the Handbook section "18.6.5 Duplicating Audio CDs" it's recommended to treat SCSI and ATAPI drives differently. For ATAPI drives the use of dd/burncd combination is recommended.

In reality burncd doesn't work on all drives -- there is a long standing bug:
bin/118207: burncd(8) gives I/O error writing CD on Pioneer DVDR-112D/1.21
And 'cdrecord' command that I tried instead expects different endianness than the one produced by 'dd'.

Also 'dd' command doesn't always work on audio devices, here is the excerpt from the conversation with Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> where  he expressed these arguments:

<begin citation>
Here is a list of cons for dd even on FreeBSD:

-	dd may not work with all drives

-	Do you know what byteorder you get from a MMC CD-ROM drive 
	on FreeBSD/Sparc? You would need network byteorder on Sparc
	but the MMC CD-ROM drive delivers intel byteorder due to a 
	bug in the MMC standard

	cdrecord always asumes network byte order for RAW audio data,
	this is reasonable

-	Why would you deal with raw audio data at all if there are
	audio file formats that include a notation for byte order and
	sampling rates?

-	There is no jitter check and no quality control with dd on FreeBSD,
	cdda2wav works on all OS and has jitter control and qualiti control
	with e.g. libparanoia.

-	There is no way to get the correct CD structure back if you use dd.
	Cdda2wav reads meta-data and puts them into *.inf files.

-	With dd, you cannot read intentionally defective media as sold by 
	the music mafia.
<end citation>

It's much better to always deal with endianness-safe commands/formats.

My proposition:
Sub-section "ATAPI Drives" should be deleted.
Title of "SCSI Drives" should be changed to "SCSI/ATAPI Drives".

ATAPI drives are exposed as SCSI devices so there should be no problem.
Comment 1 Marc Fonvieille freebsd_committer freebsd_triage 2008-11-30 07:46:34 UTC
The fact one or some burners fail with burncd(8) is not a reason to
delete documentation.

The "7.3.2 Ripping CD Audio Tracks" section documents cdda2wav for both
interfaces.

I'd not remove/rename the ATAPI Drives since it's a feature provided by
FreeBSD, people are free to use or not the "/dev/acddtnn" feature
especially when the ripped file can be directly used by burncd(8).
(Don't forget both come with the base system).

But I think we can slightly reword this "18.6.5 Duplicating Audio CDs"
section to mention ATAPI interface supports both cdda2wav and dd(1)
method and that cdda2wav may be a better choice in many cases.

-- 
Marc
Comment 2 Szilveszter Adam 2008-11-30 09:37:45 UTC
On Sat, Nov 29, 2008 at 09:04:14PM +0000, Yuri wrote:
> My proposition:
> Sub-section "ATAPI Drives" should be deleted.
> Title of "SCSI Drives" should be changed to "SCSI/ATAPI Drives".
> 
> ATAPI drives are exposed as SCSI devices so there should be no problem.

I do not particularly care for the self-advertisement of Joerg for his
own software, but at least the last sentence is not true. On FreeBSD,
exposing ATAPI devices as SCSI is just a choice that the user is free to
make (or not). The use of the atapicam module or kernel option is just
that, entirely optional. Also, atapicam may have at least as many
problems with particular hardware/software combinations as burncd, so
YMMV. I for one use burncd and I am perfectly happy with it. 

Note: One other reason people used to prefer "cdrecord" was that it was
a standard staple on linux, and so a lot of pretty GUI frontends were
written for it that do little more than call cdrecord with the correct
arguments.  For me, this is not important, burning from the command line
just works(TM).


-- 
Regards:

Szilveszter ADAM
Budapest
Hungary
Comment 3 Yuri Victorovich freebsd_committer freebsd_triage 2008-11-30 18:18:56 UTC
Marc Fonvieille wrote:
> But I think we can slightly reword this "18.6.5 Duplicating Audio CDs"
> section to mention ATAPI interface supports both cdda2wav and dd(1)
> method and that cdda2wav may be a better choice in many cases.
>   

There is another pitfall of dd method: kern/115232: [ata] Audio CD 
tracks not displayed properly by atapi driver
The warning about this should also be added to the section describing 
the use of dd/burncd method
if this section is left there anyway.

--
Yuri
Comment 4 Marc Fonvieille freebsd_committer freebsd_triage 2008-11-30 19:13:31 UTC
On Sun, Nov 30, 2008 at 06:50:03PM +0000, Yuri wrote:
> The following reply was made to PR docs/129281; it has been noted by GNATS.
> 
> From: Yuri <yuri@rawbw.com>
> To: Marc Fonvieille <blackend@FreeBSD.org>
> Cc: freebsd-gnats-submit@FreeBSD.org
> Subject: Re: docs/129281: Audio CD ripping/duplication shouldn't recommend
>  the use of non endianness safe dd/burncd commands
> Date: Sun, 30 Nov 2008 10:18:56 -0800
> 
>  Marc Fonvieille wrote:
>  > But I think we can slightly reword this "18.6.5 Duplicating Audio CDs"
>  > section to mention ATAPI interface supports both cdda2wav and dd(1)
>  > method and that cdda2wav may be a better choice in many cases.
>  >   
>  
>  There is another pitfall of dd method: kern/115232: [ata] Audio CD 
>  tracks not displayed properly by atapi driver
>  The warning about this should also be added to the section describing 
>  the use of dd/burncd method

This is documented:

--
Make sure the appropriate files exist in /dev. If the entries are
missing, force the system to retaste the media:

# dd if=/dev/acd0 of=/dev/null count=1
--

which is a workaround to the problem you experienced.

-- 
Marc
Comment 5 Marc Fonvieille freebsd_committer freebsd_triage 2008-12-08 12:23:54 UTC
Responsible Changed
From-To: freebsd-doc->blackend

Take care of it.
Comment 6 Marc Fonvieille freebsd_committer freebsd_triage 2010-08-10 09:51:46 UTC
State Changed
From-To: open->closed

A note has been added to encourage people to use cdda2wav instead of dd. 
Thanks.
Comment 7 dfilter service freebsd_committer freebsd_triage 2010-08-10 09:51:46 UTC
blackend    2010-08-10 08:51:37 UTC

  FreeBSD doc repository

  Modified files:
    en_US.ISO8859-1/books/handbook/disks chapter.sgml 
  Log:
  Add a note mentioning that cdda2wav can also be used on ATAPI drives and
  that this choice can be a better one than the dd(1) method for question
  of jitter correction, etc.
  
  PR:             docs/129281
  Submitted by:   Yuri <yuri@tsoft.com>
  
  Revision  Changes    Path
  1.295     +9 -0      doc/en_US.ISO8859-1/books/handbook/disks/chapter.sgml
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"