From owner-freebsd-doc@FreeBSD.ORG Sun Nov 30 07:50:06 2008 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74466106564A for ; Sun, 30 Nov 2008 07:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64D4E8FC13 for ; Sun, 30 Nov 2008 07:50:06 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mAU7o6JS009240 for ; Sun, 30 Nov 2008 07:50:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mAU7o6Mb009239; Sun, 30 Nov 2008 07:50:06 GMT (envelope-from gnats) Date: Sun, 30 Nov 2008 07:50:06 GMT Message-Id: <200811300750.mAU7o6Mb009239@freefall.freebsd.org> To: freebsd-doc@FreeBSD.org From: Marc Fonvieille Cc: Subject: Re: docs/129281: Audio CD ripping/duplication shouldn't recommend the use of non endianness safe dd/burncd commands X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marc Fonvieille List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Nov 2008 07:50:06 -0000 The following reply was made to PR docs/129281; it has been noted by GNATS. From: Marc Fonvieille To: Yuri 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 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 > where he expressed these > arguments: > > > 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. > > > 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