From owner-freebsd-doc@FreeBSD.ORG Sat Nov 29 21:10:09 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 6ECDB1065679 for ; Sat, 29 Nov 2008 21:10:09 +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 512888FC1F for ; Sat, 29 Nov 2008 21:10:09 +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 mATLA9AA090254 for ; Sat, 29 Nov 2008 21:10:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mATLA9xn090247; Sat, 29 Nov 2008 21:10:09 GMT (envelope-from gnats) Resent-Date: Sat, 29 Nov 2008 21:10:09 GMT Resent-Message-Id: <200811292110.mATLA9xn090247@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Yuri Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3445D1065670 for ; Sat, 29 Nov 2008 21:04:15 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 282988FC1A for ; Sat, 29 Nov 2008 21:04:15 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id mATL4Ebq005787 for ; Sat, 29 Nov 2008 21:04:14 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id mATL4EmQ005786; Sat, 29 Nov 2008 21:04:14 GMT (envelope-from nobody) Message-Id: <200811292104.mATL4EmQ005786@www.freebsd.org> Date: Sat, 29 Nov 2008 21:04:14 GMT From: Yuri To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: 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 List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Nov 2008 21:10:09 -0000 >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. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: