Date: Sat, 29 Nov 2008 21:04:14 GMT From: Yuri <yuri@tsoft.com> To: freebsd-gnats-submit@FreeBSD.org Subject: docs/129281: Audio CD ripping/duplication shouldn't recommend the use of non endianness safe dd/burncd commands Message-ID: <200811292104.mATL4EmQ005786@www.freebsd.org> Resent-Message-ID: <200811292110.mATLA9xn090247@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811292104.mATL4EmQ005786>