Skip site navigation (1)Skip section navigation (2)
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>