Free digital transcription machine software for linux

Digital Room Correction project is a program used to generate correction filters for acoustic compensation of HiFi and audio systems in general, including listening room compensation.
DRC generates just the FIR correction filters, which can be used with a real time or offline convolver to provide real time or offline correction. DRC doesnt provide convolution features, and provides only some simplified, although really accurate, measuring tools.
For further informations see the documentation section, which includes the full manual of the current version of DRC and a complete set of measurements showing the effect of the DRC correction in a real life situation.
DRC is available for free and is released under the terms of the GNU General Public License. See the documentation for details.
Enhancements:
- A new feature for replacing command line parameters has been introduced.
- The dip and peak limiting procedures have been improved in order to avoid numerical instabilities.
- A new wavelet-based analysis graph has been added to the sample results.
- Many performance improvements have been introduced.
- A new optional parameter used to define the base directory for all files has been added.

Virtual Drum Machine is a simple drum machine.
It works for little endian/linux kind of machines. You may let it work on others machines, but you probably will get troubles with it.
You definitely need oss (or maybe alsa) for sound output, and a posix-like operating system. To let it work on a big endian machine should be painful.
You write a rhythm, then you compile it, then you are able to play it to your sound card or save it to a file.
The Virtual Drum Machine is made of
- the Rhythm Compiler,
- the runtime library.
The Virtual Drum Machine is in the public domain. Who needs a license? money makers? Protection against robbery? let me laugh... Read any text of law, you will see where the robbers reside.
A simple file would look like :
void main_rhythm(void)
{
tempo = 120;
- a
. b
. b
.
- a
.b
- a
.
. b
. b
- a c
. b
}
Install:
Do a "./configure" in the drums directory, then "make", then "make install", it should be alright. You can listen to some examples in the examples/ directory.
Who yo use it?
Write a rhythm. Compile it with "rc". Run the produced program. You are done.
See the examples/ directory to get the point.
When you run an example, try "-h" to get the available options.
It should be self-explanatory.
The rhythm compiler has several options. By running "rc --help", all should be clear.
Technical Details:
The compiler will parse the input file line by line.
If a line starts with "*" or "." (not counting leading white spaces), the whole line is seen as a rhythm line, and is transformed into C code. If not, it is passed as is to the C file.
Beware! You MUST NOT start any C code line by "*" or "."!
You can create as much functions as you want, write any C code you want. But remember that a line starting by "*" or "." is seen as a rhythm line and is translated by "rc" into C code.
You must provide a "void main_rhythm(void)" function, that will be called by the library. It is the starting point of your rhythm. It can be "void main_rhythm(int argc, char *argv[])" too, with common meaning for those parameters (non-C coders will have trouble with the Virtual Drum Machine).
You can change the tempo (ex. "tempo=100;") or the volume (ex "vol=0.4;") at any time. Each sample comes with its own volume and panning (ex. "a.vol = 0.1;" "a.pan=-0.8;"). Volumes range from 0 to what you want. 1 is for the normal volume. Panning ranges from -1 (left) to 1 (right). 0 is center. All values are double. You can use "volume" instead of "vol", and "panning" instead of "pan". There is no global panning, if you want all left, set all samples to left.
To run in stereo mode, dont forget "-s" when running the generated program. It is mono by default.
You absolutely need to compile and run the examples, and read them to get the point out of it!
The "rc.conf" file contains configuration informations. You specify the sample by "sample" followed by its name (the one you will use in your rhythm files), then the file that will be played. The name of the sample must start by a letter, followed by letters and/or numbers (it must be a valid C identifier, without "_" though). The configuration file contains the install directory, used by "rc" to compile your rhythms. Take a look at the one that is provided to see how to use it.
The sound files are simple wav files. They all should be of the same rate, which can be specified to the generated program, using the "-f" option (44100 is the default). (The library only handles very basic wav files, if yours dont work, you probably will have to modify the library for the program to handle it.)
When you add a sample, you must modify "rc.conf" for the changes to appear. The samples are hard-linked to the produced program, so if you change "sample a /some/dir/file1.wav" by "sample a /one/other/dir/file2.wav" in the configuration file, the previously generated programs will still use "/some/dir/file1.wav". You will have to compile them again to take the changes into account.
Enhancements:
- The code has been modified to let gcc 4 compile it.

GNUdap is a project to build a userspace driver to interface Linux with proprietary-protocol USB MP3 players and mass storage devices. Currently GNUdap supports the CHIC MP10, CHIC MP30, CHIC Symphony from "Perstel,Inc." and the NGS Jogger from the NGS Technology.
GNUdap is also an experiment to test the advantages of a strongly-typed programming language and of the functional programming paradigm in hardware developing. In fact GNUdap is developed using the Objective Caml programming language.
To access the devices, we use camlusb, an ocaml binding to libusb, wich is an library which works in userspace to access usb devices.
A shell, which supports the main features of the player, is provided. Besides being done for linux, unlike the original program provided with the MP10, this software is interesting because it has additional features (like being able to transfer mp3s directly to the pc, and to change the playable status of a file on the DAP), not present in the official one. A graphical frontend and a filesystem interface are planned.
To find more informations about the protocol, the driver and the shell visit the Documentation Page
Enhancements:
- chic.sh: Corrected the DIR variable
- added documentation

High Level Virtual Machine is a toolkit for developing virtual machines for dynamic languages.
The High Level Virtual Machine is:
- Based on LLVM (Low Level Virtual Machine). LLVM is HLVMs sister project. HLVM gains tremendous capability from LLVM in the areas of code generation, bytecode storage, runtime execution, etc.
- Aimed at supporting dynamic languages such as Ruby, Python, Perl, Jython, Haskell, Prolog, etc.
- A complete compiler developers toolkit for creating new languages easily. To write a new compiler, language designers simply write a plugin that describes the language to HLVM and how to translate the grammar productions into HLVMs comprehensive Abstract Syntax Tree (AST). After that, HLVM handles all aspects of code generation, bytecode storage, XML translation, JIT execution or interpretation, and native compilation.
- A language interoperability framework. Because all front end compilers generate code in the same AST, they can interoperate. Use of the runtime library for common constructs (e.g. "string") allow even complex data types to be shared between languages. Users of HLVM can write complex programs in multiple languages and be assured the result can be executed efficiently.
- A code management system including code revisioning, interface versioning, automated recompilation, separation of workspaces, etc.
- Currently under development. Project started April 20th, 2006. Stay tuned to this web site for future developments.

Download Machine provides a noninteractive, nongraphical, pure Java batch file downloader.
Download Machine is pure Java daemon that watches queue files for changes. If a new entry is available, DM will download it. Queue files are just URL lists. DM fully supports the HTTP, FSP, and FTP protocols.
Main features:
- Design goals
- Non graphical
- Non interactive
- Relieable downloads
- Queued downloads
- Portability (uses Java)
- Simple to use
- Resume interrupted downloads
- Transports
- Support for HTTP/1.1 protocol
- Support for HTTP/1.0 protocol
- Support for FTP protocol
- Support for FSP protocol
- Custom headers
- Fake user-agent header
- Custom referer header, configurable per URL
- Custom cookie header, configurable per URL
- Other features
- Can check in different directories if we already have downloaded file (configurable by wildcard)
- Can move downloaded file to special directory (configurable by wildcard)

Wayback Machine is an open source java implementation of the The Internet Archive Wayback Machine.
The current production version of the Wayback Machine is implemented in perl, and lacks in maintainability and extensibility. Also, the code is not open source. Primary motivation for the new version is to address these three issues, enabling public distribution of the application, and easy experimentation with new features and access technologies.
The current Java version of the Wayback Machine supports two access, or replay modes of operation: "Archival Url" mode and "Proxy" mode.
Archival URL mode provides a user experience very close to the current production Wayback Machine. All query and replay access requests can be expressed as URLs.
In Archival Url replay mode, HTML documents are delivered with additional Javascript embedded in the page. This Javascript alters the document within the browser, attempting to make links and embedded content refer back to the Wayback Machine by rewriting them as Archival URLs.
Proxy URL mode allows replaying of archived documents within a client browser by configuring the browser to proxy all HTTP requests through the Wayback Machine. This has the strong advantage that no Javascript page markup is required to coerce the client browser to request additional URLs and embedded content from the Wayback Machine -- content just works as-is. One major disadvantage of this mode is that there is no way to forward temporal information with each replay request. Because of this limitation, only the most recently archived version of any resource is accessible thru the Wayback Machine in proxy Url mode.
Another limitation of the Proxy URL mode is that it requires special configuration of the client web browser to access the Wayback Service. This browser configuration is not complex, but it means that content cannot be accessed as a global URL.
See the User Manual to learn more about access modes.
The current Java version is intended to operate as a standalone webapp, maintaining an index on the machine hosting the webapp. This index contains records of the resources within a set of ARC files, which are also assumed to be stored on the same machine hosting the webapp.
This software includes the capability to scan for ARC files in a specified location, and to automatically index and serve content in newly discovered ARC files as they appear. Directing the Wayback Machine to look for ARC files in the directory where an instance of the Heritrix web crawler is writing ARC output should provide the capability to browse content archived by Heritrix as it is crawled.
Future versions of this software may integrate more tightly with the Heritrix web crawler application.
Enhancements:
- A sorted CDX flat file ResourceIndex implementation was added, allowing for much larger data sets.
- Support for ArchivalUrl Date-Range requests was added.
- Character set detection was improved so pages are not mangled when server side modification occurs.
- Several new command-line tools were added for generating and updating each ResourceIndex type.
- Indexing and merging processing were separated into different threads.
- Bugfixes were made to allow integration with NutchWax full-text searching.