docs/129281: Audio CD ripping/duplication shouldn't recommend the use of non endianness safe dd/burncd commands
Yuri
yuri at tsoft.com
Sat Nov 29 21:10:09 UTC 2008
>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 at 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:
More information about the freebsd-doc
mailing list