docs/129281: Audio CD ripping/duplication shouldn't recommend the use of non endianness safe dd/burncd commands

[Marc Fonvieille]

The following reply was made to PR docs/129281; it has been noted by GNATS.

From: Marc Fonvieille <blackend at FreeBSD.org>
To: Yuri <yuri at tsoft.com>
Cc: freebsd-gnats-submit at 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 08:46:34 +0100

 On Sat, Nov 29, 2008 at 09:04:14PM +0000, Yuri wrote:
 > 
 > >Number:         129281
 > >Category:       docs
 > >Synopsis:       Audio CD ripping/duplication shouldn't recommend the use of non endianness safe dd/burncd commands
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       medium
 > >Responsible:    freebsd-doc
 > >State:          open
 > >Quarter:        
 > >Keywords:       
 > >Date-Required:
 > >Class:          doc-bug
 > >Submitter-Id:   current-users
 > >Arrival-Date:   Sat Nov 29 21:10:08 UTC 2008
 > >Closed-Date:
 > >Last-Modified:
 > >Originator:     Yuri
 > >Release:        7.1-PRERELEASE
 > >Organization:
 > >Environment:
 > >Description:
 > 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 at 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.
 
 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