From Vinyl to Digital
(edit the Makefile here)
cd .. make make perl-swig
Now, let's copy the executables into a directory that's in your $PATH:
cp gramofile bplay_gramo brec_gramo /usr/bin
Finally, cd into the perl-swig subdirectory, and copy two files from there into a directory in the Perl path. But first, check your Perl path for a suitable directory:
perl -e 'print join("\n",@INC), "\n"'
So, in my Debian setup:
cd perl-swig mkdir /usr/local/lib/site_perl cp Gramofile.pm Gramofile.so /usr/local/lib/site_perl
Finally, we're ready for xmcd2make:
tar xvzf xmcd2make-0.4.tar.gz cd xmcd2make-0.4 make install
xmcd2make installs with a default bitrate of 128, but I prefer a higher bitrate (at the expense of larger files and longer encoding time), so I edited the file /usr/local/bin/xmcd2make and changed the bitrate to 224:
# $bitrate = 128; $bitrate = 224;
If you can stand one more item, I recommend a mixer called umix, because it has a console version, offers numeric levels to set levels accurately and repeatably, and the ability to save or restore all settings with a single keystroke. This means the whole LP to CD process can be done on a low-end PC without even installing X. The default mixer path is /dev/sound/mixer, which you may want to adjust as follows: ./configure --with-mixer-dev=/dev/mixer. To load and save levels as an ordinary user, start umix with a config filename, like umix -f $HOME/umixrc. Press S to save the current settings and L to reload the last saved settings.
Here are the steps to capture Dory's On My Way To Where album to the hard drive, then process it to arrive at a set of wav files suitable for burning an audio CD, plus a set of Ogg files for use by computers and portable players. Eventually, we'll tell xmcd2make the basename is “where”, so we name the files appropriately.
Position the computer near your stereo, and connect stereo line out to your sound card line in with a quality, shielded cable. You probably will need a dual RCA-to-stereo mini-plug cable to make this connection.
Load your mixer in one console or xterm. Load gramofile in another after changing to an empty directory on a partition with a lot of free space.
Use the mixer to set “line in” to record mode and to mute all other channels. You may need to bring up input gain (igain) too. This reduces background noise.
Use gramofile's Record audio to a sound file to capture a sample, and use the mixer to adjust levels to bring the peaks on the gramofile level meter near the top.
Stop sampling, and verify that a reasonable percent of samples were above 50% of max volume, a few above 90%, but that few or none were above 99% (Figure 2).
Set gramofile to capture side one of the LP by giving it a descriptive name, in our example, where1.wav; start playing the LP, then start capturing.
When side one is completed, stop gramofile and verify that the sample levels are reasonable. If not, use your mixer to adjust the levels. Some of the volume spikes are caused by clicks, so a few clipped samples are acceptable.
Capture side two to a file called where2.wav.
Now we have two wav files of about 200MB each, digital representations of the sound in the vinyl grooves. This is a good time to decide whether this LP has significant surface noise—those clicks for which vinyl is famous. If the whole album is noisy, run both sides through the filter(s) gramofile offers. If only selected songs are noisy, typically the first track on each side, wait until the tracks are split.
The gramofile documentation includes a fascinating discussion (Signproc.txt) of each filter and the theory behind it. You'll notice when choosing Process the audio signal that Conditional Median Filter II already is selected. It's the most sophisticated, and I had good results with it. Clicking noises aren't obliterated, but they're greatly reduced. Multiple filters can be used, or you can use the same filter twice. I stick with one pass because when I used Conditional Median Filter II twice, there was a noticeable degradation in the music. However, the process takes only a few minutes, so feel free to experiment. The original file is preserved, and you have the opportunity to give the filtered file a meaningful name. Listen to this new wav file. If you like the result, delete the original and rename the filtered file to be the same as the original.
Before encoding any tracks, you'll want a listing of the artist name, album name and the title of every track. You can save some typing by searching freedb.org. If your album is found, click on the IDs link above the first track title, then save the page that comes up as a text file. If you prefer, simply copy the listing from this xmcd page and paste it into a text editor, ignoring any lines starting with #. Be sure to save the file as plain text into the directory where your wav files are, and name it to match. For our example, that would be where.xmcd. In either case, all we'll be using are DTITLE and TTITLE lines. For obscure LPs, I keep a copy of an xmcd file with only DTITLE= and TTITLE0= thru TTITLE10= in my home directory. It only takes a minute to copy it with a name to match the current LP, then type in the titles from the album jacket. Notice that the track listings start with zero. Here's a partial sample:
DTITLE=Dory Previn / On My Way To Where TTITLE0=Scared To Be Alone TTITLE1=I Ain't His Child
Our task now is to split each side into individual songs. Straight gramofile users can choose Locate tracks from the menu, then choose side one (where1.wav), click Next, click Start computation and wait for the song count to come up. If the count is not correct, try again but adjust one or more of the options before Start computation. Try reducing intertrack silence to 12 or less. Repeat for side two. When you're happy with the track counts, choose Process the audio signal; choose the side one wav file again; click Next; then, tab through to the “Next” screen if you want to use the default click filter. To use no filter, stop at the Available filters box, highlight Copy only and press the Enter key. Now tab to the Selected filters box, highlight Conditional Median Filter II and press the R key to remove it. Use the same procedure to choose a different (or additional) filter, but you must select either a filter or Copy only to process the files. Incidentally, pressing the Enter key while a filter is highlighted in the Selected filters box allows you to change specific filter settings. Finally, tab to Start and press Enter. When it completes, you should have a wav file for each track, ready for test listening and then burning.
xmcd2make users should exit gramofile, as xmcd2make's findtracks script is a wrapper around gramofile's findtracks function. Run findtracks where1.wav from the prompt to scan album side one, then compare its output with the official track listing. Type less *.tracks, and you'll see a plain-text file with start and stop timings for each track. If you see two tracks lumped together, go back to the prompt and try again with one or more of the parameters adjusted, for example:
findtracks where1.wav --min-silence-blocks 12
It's possible, though tedious, to split the songs manually. A crude alternative is to burn the whole side as a single track. In this case, use gramofile's filter, but choose Copy only (as explained above but unchecking the Split tracks option), which would do no filtering but would add timing information to the wav file, so the CD burner would know the true running time. If you find a song split in two, it's easy to edit the tracks file to merge the two, then renumber the rest of the tracks on that side and edit the Number_of_tracks= line to match. Finally, repeat the whole process for side 2.
Now, we're ready to create a Makefile, which automates the rest of the process:
xmcd2make --basename where --counts 5,5 > Makefile
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide