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
display. 


INSTALLATION

The file gramofile-1.6.tar.gz, available at

    http://www.opensourcepartners.nl/~costar/gramofile

contains the complete C source code of the GramoFile program. To unzip it,
type

    tar xzvf gramofile-1.6.tar.gz

or, alternatively,

    gunzip 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

    make

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

    gramofile


USAGE NOTES

General:
 - 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:
    http://www.fokus.gmd.de/nthp/employees/schilling/cdb.html

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
    code...
 - 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
    instead.
 - 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:
    ftp://ftp.gwdg.de/pub/linux/misc/cdda2wav
    Alternatively, you can try the cdparanoia(1) program:
    http://www.mit.edu/afs/sipb/user/xiphmont/cdparanoia/

Track location: 
 - 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
    please. 
 - 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
    file.
 - 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
    the tempfile.
 - 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
    higher thresholds.
 - 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 
    details.
    
    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
    better.

BUGS

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
appreciated ;-) 


AUTHORS

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 costar@panic.et.tudelft.nl or
mcbzmr@dds.nl). But please understand that I'm a student with very limited
time to do the more pleasant things in life.

Have fun!


--
All mentioned trademarks and registered trademarks are the property of their
respective owners. 
