oreilly.comSafari Books Online.Conferences.


Creating Audio CDs With Linux

by Dave Phillips

Recently a friend asked me for a CD of music I wrote and recorded many years ago. Unfortunately, the material existed only as a 4-track cassette tape master, but the tape had been recorded on a Yamaha MT120 home studio 4-track, with a speed of 9.5 centimeters per second and with dbx (a noise reduction method) enabled. Though the tape was hardly a sonic or musical masterpiece, it did sound good enough to warrant recording to hard disk for processing before eventually burning the songs to CD.

This article follows the process of recording the material to the hard disk, editing and filtering it with signal processing software, and finally creating an audio CD from the results, complete with custom covers for the jewel case. I'll present and describe the tools used in each stage of the process, and I'll explain how you too can turn your computer into a powerful audio CD mastering machine, using only free and open-source Linux software.

Stage 1: recording to hard disk: ecasound

Kai Vehmanen's ecasound (Figure 1) is multitrack-ready, capable of recording as many channels as your sound card setup permits. The system used for this project includes two sound cards, a SoundBlaster PCI128 and an SBLive Value. It is possible to record two channels into one card and two into another to create a system with four-channel analog input, but due to clock drift, it is impossible to correctly synchronize the recorded tracks (see Paul Winkler's excellent Linux Audio Quality HOWTO for a summary of dual sound-card clock drift). Synchronized multichannel I/O is normally found only on high-end digital audio boards. Only a few such boards enjoy Linux driver support at this time. (Two notable examples are the boards from MidiMan and RME.) Alas, I don't own one of those boards, so I decided to simply mix the master tape's four tracks with the mixer on the MT120, sending the mixed stereo output to the input of the SBLive (its audio specifications are somewhat better than those for the PCI128).

Screen shot of ecssound.

Figure 1. Kai Vehmanen's ecasound.

Recording with ecasound (or with qtecasound, its GUI sibling (Figure 2) is extremely simple. I issued the following command from an xterm:

ecasound -c -b:4096 -r -i:alsa,0,0,0 -o my_song_01.wav

The command options are as follows:

  • -c starts ecasound in interactive mode
  • -b sets the audio buffer size
  • -r sets the realtime scheduler (SCHED_FIFO) flag
  • -i sets the input device and its parameters
  • -o names the output file

I have a lot of RAM (256 MB) in a decently fast machine (a PIII 550), so I set the buffer size to a relatively large number. You may need to adjust it for best results on your own system. Ecasound will work with any Linux sound driver, but in this example I've set the input device to the ALSA driver for my SBLive. The numbers indicate the first sound card in my system (the count starts at 0), the first audio input device (0, or /dev/snd/pcmC0D0), and the subdevice (also 0). The output file will be recorded at the default CD-quality specifications, i.e., a stereo recording with a sampling rate of 44.1 kHz and 16-bit sample resolution.


Coaster-Free Burning with IDE CD Writers

Broadcast 2000 Brings DV Editing to Linux

Achieving Low-Latency Response Times Under Linux

What Is This 3D Audio Business?

Creating Great Audio for the Web

Setting the realtime scheduler helps prevent underruns (gaps and dropouts in the recording), but to guarantee dropout-free recording, I suggest installing a kernel patched for low latency. (See my O'Reilly Network article on low-latency audio for the details.) The results are definitely worth the minimal effort, and if you intend to do much recording in Linux, I strongly urge you to patch your kernel for low-latency response.

The actual recording starts when you type t at ecasound's command prompt. Press s to finish. If all goes well, ecasound will report no errors. If underruns are reported, you probably need to upgrade to a low-latency patched kernel and tune your IDE drive with hdparm (as described in my low-latency article).

Stage 2: editing and processing sound: tools for X and the console

After recording the songs to the hard disk, I wanted to edit them before burning the files to the audio CD. I used Doug Scott's MiXViews (Figure 3) to perform the following operations:

  • Cut extraneous length from the files
  • Adjust the overall amplitude (the gain factor, oddly called "Phrase" in MiXViews)
  • Filter extraneous high frequencies
Screenshot of MiXViews.

Figure 3. Doug Scott's MiXViews.

Readers who are familiar with other, more modern Linux soundfile editors may wonder why I chose MiXViews. My best reason is that I know it very well, having assisted in an early port to Linux. Other reasons include its ease of use (it can be controlled from the keyboard as well as the mouse), its accuracy and definition (the file view can be zoomed to single-sample resolution), its well-designed filters, and its speed.

Soundfiles are most easily edited in graphic displays, and Linux can claim a number of fine soundfile editors with graphic interfaces, including Snd, Broadcast2000, and DAP. All of those editors absolutely require the X-Window graphics system, but console users are not entirely shut out from the world of graphic editing: Bernhard Oemer's WaveTools is a suite of WAV-format soundfile editing utilities that includes wView, an interactive console SVGA soundfile viewer. Although wView isn't actually an editor, the information it provides can be utilized by the other tools in the suite (which includes mixing, cutting, and filtering modules). Traditional Unix pipes can be used to link operations together for a deceptively simple yet powerful soundfile editing environment at the Linux console.

Console and X users alike may also be interested in J.A. Bezemer's GramoFile. This utility was originally designed for cleaning up soundfiles created from phonograph recordings. Such recordings are often marred by clicks and pops caused by imperfections of the original medium, and GramoFile's greatest strength lies in its selection of audio filters (Figure 4).

The final step in my editing process dealt with the problem of uneven amplitudes between soundfiles, i.e., some files were louder than others, so I employed Chris Vaill's normalize. This handy little tool can batch process a group of WAV files to bring their relative volumes into balance with each other, ensuring that my listeners would not need to adjust their player's volume level for each song. In order to normalize all the files I intended to burn, I ran this simple command:

normalize -m /home/dlphilp/soundfiles/cd-audio/my_songs/*.wav

The -m flag adjusts the level of each track to the average level of all the tracks. Once the levels had been normalized, it was time to move on to the next stage and actually burn the soundfiles to an audio disc.

Pages: 1, 2

Next Pagearrow

Linux Online Certification

Linux/Unix System Administration Certificate Series
Linux/Unix System Administration Certificate Series — This course series targets both beginning and intermediate Linux/Unix users who want to acquire advanced system administration skills, and to back those skills up with a Certificate from the University of Illinois Office of Continuing Education.

Enroll today!

Linux Resources
  • Linux Online
  • The Linux FAQ
  • Linux Kernel Archives
  • Kernel Traffic

  • Sponsored by: