GramoFile - Gramophone records to CDs, Tick Reduction, Track Splitting
Copyright (C) 1998 J.A. Bezemer
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA.
INTRODUCTION / OVERVIEW
This is version 1.6 of GramoFile, released March 28, 2000. With this
program you can record audio of (for example) gramophone records, process
the signal and listen to the results. Because sound files of the
.WAV-format are used, it is possible to exchange the files with many other
programs. Cdrecord(1) can burn CD-Recordables of these, so you can make
CDs with the music of your favorite records. The user interface of
GramoFile has a windows-like look-and-feel, making it fairly easy to use.
One of the most important parts of GramoFile is the ability to process
digital audio signals. Through the application of several filters it is
possible to accomplish a significant reduction of disturbances like ticks
and scratches. These filters have been programmed in such a fashion that
they can be applied in a random order (and multiple times) in a single
run, thus evading the use of temporary files. There is a possibility of
adjusting the properties of each filter independently, so in every
situation an optimal result can be achieved.
Another interesting feature is the track splitting. Just make one .wav file
of an entire side of an record and GramoFile will detect where the individual
tracks are located. This happens fully automatically, without need to set
any options. More experienced users may fine-tune the algorithm, or change
the detected track starts and ends, but generally that will not be
necessary. Track-times are saved in an editable (plaintext) .tracks file,
that will be used during the signal processing to produce one processed
.wav file for each individual track.
To record and play .wav files, modified versions of brec(1) and bplay(1)
by David Monro are used. These programs provide buffered recording and
playback, so all will go well even on a highly loaded system. Both
programs have been supplied with the standard GramoFile user interface.
Brec also got a `graphical' peak level meter, and bplay a running time
The file gramofile-1.6.tar.gz, available at
contains the complete C source code of the GramoFile program. To unzip it,
tar xzvf gramofile-1.6.tar.gz
tar xvf gramofile-1.6.tar
Change the working directory to the newly created directory gramofile-1.6
and issue the command
to start the compilation process.
Note for all 64-bit systems: when your `long'-type vars are 64 bit, .wav
headers are not read/written correctly (=bug). If you replace every `long'
with an `int' (or other 32-bit type), everything should be fine.
Note for non-Linux systems (like IRIX): check the Makefile first, you
probably have to uncomment some lines. Also, you probably won't have sound
recording/playing capabilities. If you experience portability problems,
please fix them and send me a nice patch ;-)
Note for Solaris: there seem to be problems with the scandir() function
not being present. It might be in the "SunOS/BSD Compatibility Library"
(don't ask me...)
Update: there is a scandir replacement in sun_scandir.c. To use it, add it
to SRCS in the Makefile; also add a line
int alphasort(struct dirent **d1, struct dirent **d2);
in the beginning of dirfilemenu.c.
Note that the Makefile is written especially for use with GNU `make'
(sometimes called `gmake'). That `make' implementation regards #included
files as targets, enabling us to create and include dependency information
in the same run as compiling the program. That's also the reason why those
"file not found" messages appear: these files will be made and included
automatically. More information on the GNU programs may be acquired by
pointing your browser to http://www.gnu.org. If you don't have the GNU
version of `make', you can simply comment the `include' line out; it is
primarily useful during development activities.
To run the GramoFile program, issue the command
- The GramoFile program uses customized versions of `bplay' and `brec',
named `bplay_gramo' and `brec_gramo'. These programs are started
from within the `gramofile' program with just that names (no
directories). That means that they should be located in a directory
that is in your search path ($PATH), e.g. /usr/local/bin. But if
you don't want (or are not allowed) to put them there, add `.'
(current directory) to your search path, set your working directory to
the GramoFile directory and start the program with just `gramofile'
(the './' as in `./gramofile' should not be necessary). Note: this
is a known bug (if you like, send me a nice patch ;-).
- Information on CD burning issues may be found on:
Record an audio file:
- Use the `Mixer' button in the file selection screen to start
xmixer(1). Make sure the appropriate input (and no other) is selected
for recording. SoundBlaster(TM) owners: note that treble and bass
settings affect recording! I found SB16PnP works better with both
sliders at 50%, Richard Robinson reports his SB64Gold requires treble
65%, bass 45%.
- If you choose `Cancel' during the "Press Enter to start recording" box,
the selected audio file has already been created/truncated, and will
have zero length. So if you were overwriting a file, it was already
deleted before this dialog box appeared.
- The length as reported in the .wav header of the recorded file is not
correct. This is because brec doesn't update the header if the
recording was stopped prematurely (by pressing Enter). If you have
problems with this, simply process the sound file with the `Copy Only'
filter; the output file has the correct length in the .wav header.
Alternatively, you can make some additions to the bplay/brec source
- To get the best out of track location, you shouldn't record too much
silence before the first & after the last track. 3-5 seconds silence
will probably get the best results. Also, I don't recommend recording
two sides of a record in a single (long) sound file; make two files
- If you want to view the input signal level without recording to a
sound file, try recording to /dev/null ;-)
Copy audio from an audio-CD to a file:
- This option is not yet implemented. There are some plans to program a
uniform user interface to the cdda2wav(1) program here. You have to
use the bare program for this moment. More info:
Alternatively, you can try the cdparanoia(1) program:
- Track location information is saved in a plaintext file with the same
name as the audio file but appended with ".tracks", as in
"firaru_side1.wav.tracks". You may view/use/edit this file as you
- The ".tracks" file will be written in the same directory as the sound
file. If that directory is not writable, create a symlink to the
sound file from a directory like "/tmp/gramofile", and use that `new'
sound file instead.
- For more information on the algorithms used, and the procedure you
should follow to get optimal track location, see the Tracksplit2.txt
- If you want to view the (optionally generated) .med or .sor files with
gnuplot, you may use a gnuplot-command like:
plot '/dir/filename.wav.med' using 2 smooth unique
or to view only a certain interval:
plot [1000:2000] '/dir/filename.wav.med' using 2 smooth unique
Process the audio signal:
- If you choose to split tracks, numbered files will be created with the
`output filename' as base. If the `output filename' is entered as
"/tmp/test.wav", files like "/tmp/test01.wav", "/tmp/test02.wav", etc.
will be created. You will be warned if a file "/tmp/test.wav" exists,
although it will not be overwritten, but the 01, 02, etc. files will
be overwritten without your consent. Be warned! (This is also a bug.)
- You can also pipe the output data directly to some command that accepts
.wav-format input via stdin, when using a "filename" like
`|progname args outfile.ext'. Popular example: `|bladeenc -quiet STDIN
processed.mp3'. If track splitting is done, there _must_ be something
like a filename at the end of the line; e.g. the `.mp3' will be
replaced by `01.wav', `02.wav' etc. (Always `.wav', this is a bug.)
A new command is executed for each track. Note: 1) if the name can't
be the last item on the line, write a shell-script wrapper; 2) the
output file must be read once and in-order, which some programs (like
LAME!) can't do. Easily fixed with a script that first saves the data
to a .wav tempfile, then performs the wanted action, and finally removes
- For more information on some of the implemented filtering algorithms,
and the implementation of new filters, see the Signproc.txt file.
- Known problem: the algorithm for the Conditional Median Filter II is not
optimal. With certain musical instruments and tones, the sound might
get distorted by an annoying `shot noise'. This is because those
instruments produce sawtooth-like sound waves, containing lots of high
frequencies. The `normal' highpass filter used by the CMF II detects
these high frequencies as ticks. You can solve this problem in two
ways. First, you may try to increase the tick detection threshold
(second threshold) to for example 7000 or higher. Second, you can try
to use an alternative highpass filter, by #defineing either FOURTH_ORDER
or SIXTH_ORDER in signpr_cmf2.c. These highpasses enhance very high
frequencies, so real (short) ticks are detected better, even when using
- Hint: if you are doing mono 78's, it might be profitable to use a
convert-to-mono filter first. You'll still get a stereo output file,
but with both channels identical. Use sox(1) or the like to convert it
to a real mono file.
Write an audio CD:
- This option is not yet implemented. There are some plans to program a
uniform user interface to the wodim(1) program here. You have to
use the bare program for this moment. Try something like
wodim -v speed=2 dev=0,2,0 -audio -pad track01.wav track02.wav ...
Please check out the wodim package or the cdrkit-doc package for
You always can use a graphical front-end to write CD's, like the
xcdroast program. See the xcdroast package for details.
Play an audio file:
- Make sure the PCM and Master volumes are set high enough, and your
speakers are plugged in correctly and turned on ;-)
- I find the `Track' field to be extremely useful. If I've had located
tracks, I use one xterm with GramoFile, and another one with a editor
with the .tracks file. If I don't agree with the automatic detection,
I change the .tracks file, save it, and listen to the new beginning
and end in GramoFile. Note that the .tracks file is reread every time
you press B, E, F, A or Enter.
- To notice differences between filtered/non-filtered sound files, you've
got to have speakers that are fit for that purpose. I've found that big
speakers are quite `slow' and have a natural ability to reduce tick
volume, because they can't keep up with the speed. To be able to hear
the ticks as they are, little speakers are most useful, but small,
"low-quality" headphones (as used with cheap portable audio) are even
Plenty. Like max string lengths, un-free-d memory, bad error-handling. But
if you don't do too extraordinary things, you shouldn't notice anything.
The source code is definitely not portable (well, IRIX runs fine...).
There is no manpage. There are no commandline options - so why bother
about a manpage? Only text mode. Screensize is always 80x24. Only
CD-quality .wav files are accepted (well, that was the purpose, wasn't
it?). There are major language errors everywhere (please send me
corrections). `make install' doesn't work.
But I expect too have only very limited time to do something about all
them bugs. You may report bugs at any time, direct them to
J.A.Bezemer@ITS.TUDelft.NL. Completely worked out fixes are greatly
GramoFile was developed by Anne Bezemer and Ton Le, students of the
department of Information Technology and Systems (ITS), sub-department of
Electrical Engineering (ET) of the Delft University of Technology (TU
Delft). The first major part was written during the `Integraal Project
Practicum' (IPP) in the spring of 1998. However, development has continued
unofficially thereafter (so now we have track splitting operational :).
Total development time is about 7 weeks full-time.
The following persons have been very helpful and/or supportive during the
`official' part of the project: A.P. Thijssen, E.A. Hendriks, A. Redert,
J.A.H. Snelders, L. Meijs and R.J. de Gruijl. Other persons are mentioned
in the ChangeLog file.
Any questions, comments, suggestions and bugfixes may be mailed to
J.A.Bezemer@ITS.TUDelft.NL (or try email@example.com or
firstname.lastname@example.org). But please understand that I'm a student with very limited
time to do the more pleasant things in life.
All mentioned trademarks and registered trademarks are the property of their