Date: Sun, 30 Nov 2008 07:50:06 GMT From: Marc Fonvieille <blackend@FreeBSD.org> To: freebsd-doc@FreeBSD.org Subject: Re: docs/129281: Audio CD ripping/duplication shouldn't recommend the use of non endianness safe dd/burncd commands Message-ID: <200811300750.mAU7o6Mb009239@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/129281; it has been noted by GNATS. From: Marc Fonvieille <blackend@FreeBSD.org> To: Yuri <yuri@tsoft.com> 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 > <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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811300750.mAU7o6Mb009239>