~ubuntu-branches/ubuntu/jaunty/gramofile/jaunty

Things that could/should be done (random order) - but not by me: I've got

other things to do at the moment :(

 - Find and correct all bugs

 - Better error handling (malloc, file ops)

 - Support (user interface) for cdrecord, cdda2wav/cdparanoia

 - More / better filters  - pops/ticks/scratches

                          - hiss, broadband noise

                          - fade in/out at track start/end (see below)

                          - volume normalizing to put tracks from

                             various sources on one CD

                          - dynamic-range decompression (Keith Refson's idea)

 - Possibility for application of frequency domain filters (probably

    difficult to do in streaming processing)

 - Remember filter/track location settings within a single invocation

    (Also see patch from James Tappin on the webpage)

 - Make .wav reading/writing 64-bit clean (i.e. don't depend on sizeof's)

    (temporary workaround: change every `long' into `int', see README)

 - Compute average/maximal signal volume/power for info-screen after

    recording (sum of 1G shorts in a float) (see bplaysrc/shmbuf.c,

    shmrec())

 - Show number of nearly-clipped samples also _during_ recording, for

    easier adjustments of sound source (idea of Juergen Lock)

 - Copying, moving, deleting files; creating, deleting dirs from

    within user interface (?)

 - Automatic detection which of xmixer, xmix, aumix, ???mix to use

    (e.g. $DISPLAY ? or $MIXER ?)

 - Auto screensize (not always 80x24)

 - X user interface

 - Manpage

 - Support for non-CD-quality and non-.wav sound files;

    (for mono files, also see patch from James Tappin on the webpage)

 - Command line options (or via a options file)

 - Porting to other *UXes, Windows? First only Signproc/Tracksplit

    (IRIX and possibly others should work already. If you try, please mail

    me your experiences)

 - For webpage: example .wavs, example graph files (track location),

    screenshots of (un)processed .wavs

Fade in/out:

Paul Martin <pm@nowster.zetnet.co.uk> sent me the following:

-----quote-----

[...]

Here's a fragment of code that does a mono fade out. It's very

sub-optimal, but it does work. It implements a (1-x^2) fade (x = 0 -> 1). 

By changing the exponent you can change the type of fade from linear (x^1)

to highly logarithmic.

[...]

#include <math.h>

#include <stdlib.h>

#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <unistd.h>

const char inname[]="input.sw";

const char outname[]="output.sw";

signed short buff[441000];

main () {

 double frac,scaler;

 long i,size,max;

 int inp,oup;

 signed short tmp;

 if ((inp=open(inname,O_RDONLY))==-1) {

  perror("open('input.sw')");

  exit(1);

 }

 size = read(inp, buff, sizeof(buff));

 close(inp);

 max = (size/2);

 for (i=0; i<max; i++) {

  frac=(double) i / (double) max;

  scaler = 1.0 - (frac)*(frac); /* this is the important bit */

/* scaler = 1.0 - (1.0-frac)*(1.0-frac); /* fade in */

  tmp = (signed short) ( ( (double) buff[i]) * scaler);

/*  printf("%d %f %d %d\n", i, scaler, buff[i], tmp ); */

  buff[i]=tmp;

 }

 oup=creat(outname,0644);

 write(oup,buff,size);

 close(oup);

}

-----end of quote-----

Idea seems to be useable. Exponent may be settable in a Parameters screen

(then scaler=pow(frac,log_factor)), as well as the length of fade in and

fade out (in samples, or e.g. 1/100 sec?). But for correct implementation,

a current_sample_position has to be added to param_t, that is updated

every sample (in advance_current_pos() ?). Otherwise, the pre-reading of

the buffers will make it go all wrong (note that the fade in/out must be

placeable anywhere in the processing chain). Also, track_start/end

(samples or bytes) or tracktimes[] must be global vars.