Being member of the operator group this is not really needed in my case, but that may not always be that way:

Code:

$ groupinfo operator
name operator
passwd *
gid 5
members root j65nko

Requirement for access to the CDDB server(s) is that the firewall should allow outgoing TCP connections to port 888.

Code:

$ grep cddb /etc/services
cddb 888/tcp cddbp # Audio CD Database

A pf firewall rule to pass this kind of traffic:

Code:

pass out quick on egress inet proto tcp from egress to any port cddb

The original Uncle Meat album was a vinyl double LP( 4 sides). The CD version also has 2 CD's but the second CD contains what most Zappa fans consider to be three "penalty tracks".
I want to combine the tracks of CD 1 and CD 2 on a single CD, excluding those three tracks.

The cdio(1) command to rip the CD is cdrip described in the man page as:

Code:

cdrip [track1-trackN ...]
Rip specified tracks from disk. Audio tracks are saved as WAVE
sound files. All tracks will be saved in the current working
directory. If parameters are omitted, all tracks are ripped.
Both individual tracks and track ranges may be specified, in the
same format as the cdplay command.
cdplay [track1-trackN ...]
Play specified tracks from disk. Unlike play, the CD player need
not be connected to an audio device; instead it rips tracks from
disk and outputs audio data to the default audio(4) device or
aucat(1) socket. Both individual tracks and track ranges may be
specified. If range is specified in descending order tracks will
be played in descending order. If the first value in the range
is omitted, tracks from first track on disk to the specified one
will be played. If the last value in the range is omitted,
tracks from the specified track to the last track on disk will be
played.[/b]

Now we have to solve the following: We have 'track04.wav' up to "track09.wav" files
in both CD_1 and CD_2 directories. I have no idea if that could pose a problem in the track sequence if we
would write them.
We could of course test this with a CD-RW, but by using hard links we can easily solve this issue.

Having all our tracks hard linked in a single directory, we now can write the tracks to the CD:
The appropiate command according to the man page is:

Code:

tao [-ad] [-s speed] trackfile ...
[command line only] Write a track-at-once CD containing the
specified trackfile.
The options are as follows:
-a Write files as audio tracks. File formats of audio
tracks may be CDDA or WAVE with 2 channels of PCM audio,
signed 16-bit (little endian) values sampled at 44100 Hz.
-d Write files as data tracks (the default).
-s speed
Specify a write speed for tracks. speed may be a
numerical value between 1 and the maximum speed supported
by the media and drive, or one of the literal strings
``auto'' or ``max'', meaning the optimal or maximum speed
detected.

So somebody else has submitted this CD 1 & 2 combination to the CD DB server(s).

Actually I was a little bit concerned whether this all could fit on a 700 MB CD. The total time is 76:26 minutes.That is below the 80 minutes playing capability of the CD-R, but the nr of MB exceeds it's 700 MB specification:

About the difference between 80 min audio CD and 700 MB data CD, I once looked into this with the power of google, and wrote a little summary for future reference. Here is the relevant extract of that in case anyone is curious about it:

================================================== ==============
Consider an 80-minute audio CD. Bar spittin', the bytes of data it can hold are audio data, in the amount of (approx):

However, apparantly when writing a data CD (i.e., iso9660 filesystem) the area of a 2352-byte audio frame (1/75 sec worth) is used to only hold 2048 bytes of data, i.e., 2Kb. This gives a scale-down factor of

2048 / 2352 = 0.87075

and so the CD will only hold

0.87075 * 807.5 = 703.1 MB

This is basically the "700 MB" / "80 min" that almost all commercial CD's advertise on the label. My odd-ball Sun-Power CD-RW's say "730 MB", but I suspect this refers to mega = 10^6, where the above translates into 737.3 million bytes.
================================================== ==============

Even though I have used cdio from the base in the past to rip and burn music CDs in exactly the fashion that you described I just find much easier these days to do ripping with ABCDE http://lly.org/~rcw/abcde/page/. It boils down to about the same except that you are using somebody's debugged script (Ok not quite since ABCDE uses cdparanoia for ripping instead of cdio rip). By the way cdrtools port (cdparanoia is the part of the suit) has just been updated to the latest release 3.0 so everyone who runs OpenBSD current should help testing.

There are some serious problems associated with ripping CD's. The biggest problem is that most CD/DVD drives are not able to accurately report whether an error occurred, and due to strange caching algorithms may produce very strange results.

The "gold standard" for accurate CD ripping is Exact Audio Copy, while excellent software, it is Windows-only and closed source.
I'm not aware of an alternative that runs on BSD. One solution might be to rip them twice and compare hashes...

__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.

Yamaha's Audio Master Quality Recording is intended for maximum compatibility audio CDs, but is only available on some models, notably the CRW3200 series[1] and the F1 series[2].

It uses a Disc At Once method with a fixed linear recording speed of 1.4 m/s, burning longer, sharper pits and lands. Since the pits and lands are longer, the quantity of information that can fit on a disc is less than with a normal method: 63 minutes instead of 74 minutes on a 650meg CD, and 68 minutes instead of 80 minutes on a 700meg CD.

The main advantage of this recording mode is an easier to read audio CD. According to a reviewer, the sound quality is noticeably better.[3]

I am not sure whether these drives are still available.

__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

new audio data writing mode that basically produces CD-R with less jitter

Quote:

since pits are longer the CD player’s lens receives more reflected information for each pit

Both would be true if CD work like gramophone records. But they don't. It's either a 0 or a 1. I'm not sure what "more reflected information" a CD player is supposed to receive. The same applies to jitter. The jitter isn't read from the CD, it's introduced by your listening equipment.

Quote:

Now you may be wondering if the human ear can hear the difference between an Audio Master recorded CD and a normal written CD. The answer is definitely yes. Indeed the Audio Master recorded CD reproduced, on our Yamaha HiFi system, a much clearer and accurate sound than the same music CD recorded normally.

Since it's not mentioned how the test if performed, II think it's safe to assume it's not a blind test, meaning it's a useless test.