Free crc software for linux

BladeEnc is a freeware MP3 encoder. It is based on the same ISO compression routines as mpegEnc, so you can expect roughly the same, or better, quality . The main difference is the appearance and speed.
BladeEnc doesnt have a nice, user-friendly interface like mpegEnc, but it is more than three times faster, and it works with several popular front-end graphical user interfaces.
BladeEncs output quality is one of those rare subjects that completely divides the world in two parts. Either you love it or you hate it, there never seems to be an opinion inbetween. Different audiophiles and mp3 experts tends to come to completely different conclusions depending on their methods and testsamples.
The reason for this is of course that BladeEnc is a very different mp3 encoder (compared to Fraunhofer, LAME etc) with a very unique approach to mp3 encoding.
In order to compress sound to an mp3 file, you need to make certain sacrifices in quality. Taking into account how we percieve sound, the mp3 encoder tries to remove the details that it believes us to be least likely to notice. How much that needs to be removed depends on the bitrate and the encoder often has the choice of doing different kinds of sacrifices.
It can remove low volume tones that are "shadowed" by high volume tones of similar frequencies, remove the high frequency part of the sound spectrum, cut down the stereo effect (so called joint stereo) and simply decrease the samplerate. What approach is the best depends on a lot of things, like the style of music and the selected bitrate.
Main features:
- Sourcecode available under the LGPL-license!
- Stereo or Mono output. Can downmix to Mono on the fly.
- Supports the following bitrates: 32, 40, 48, 56, 64, 80, 96, 112, 128, 160, 192, 224, 256 and 320 kBit/s. However, for bitrates lower than 128 kBit we seriously recommend you to use another encoder.
- Flags like Private, Original and Copyright can be set.
- Input samples can be in either 32, 44.1 or 48 kHz.
- Both 8 and 16-bit samples are supported.
- Working CRC checksum generation (since 0.80). The ISO reference code had broken CRC calculations, which has been inherited into every ISO based encoder that havent added a fix for it.
- Can be plugged directly into many popular 3rd party products, giving them integrated mp3 encoding abilities.
- Encodes chunks of data from memory to memory, no need to use files or pipes.
- Can be compiled for nearly any operating system still in use.
- Commandline based, makes it easy to include BladeEnc into BAT files and shell scripts.
- Only mp3 encoder that supports gapless encoding.
- Reads standard uncompressed WAV- and AIFF-files as well as well as RAW PCM-data.
- Batch encoding. Can encode any number of samples in a row.
- Wildcards supported. You can for example encode all WAV-files in a directory by typing *.WAV".
- Input samples can be automatically deleted after encoding.
- Large selection of graphical frontends available.
- Task priority can be set from the commandline and is by default set to LOWEST so that you still can use your computer effectively while encoding (Windows & OS/2 only).
- Full support for pipes and redirection (stdin and stdout).
- Textbased configuration file where you can change default settings.

Convert::BinHex can extract data from Macintosh BinHex files.

ALPHA WARNING: this code is currently in its Alpha release. Things may change drastically until the interface is hammered out: if you have suggestions or objections, please speak up now!

SYNOPSIS

Simple functions:

use Convert::BinHex qw(binhex_crc macbinary_crc);

# Compute HQX7-style CRC for data, pumping in old CRC if desired:
$crc = binhex_crc($data, $crc);

# Compute the MacBinary-II-style CRC for the data:
$crc = macbinary_crc($data, $crc);

Hex to bin, low-level interface. Conversion is actually done via an object ("Convert::BinHex::Hex2Bin") which keeps internal conversion state:
# Create and use a "translator" object:
my $H2B = Convert::BinHex->hex2bin; # get a converter object
while (< STDIN >) {
print $STDOUT $H2B->next($_); # convert some more input
}
print $STDOUT $H2B->done; # no more input: finish up

Hex to bin, OO interface. The following operations must be done in the order shown!
# Read data in piecemeal:
$HQX = Convert::BinHex->open(FH=>*STDIN) || die "open: $!";
$HQX->read_header; # read header info
@data = $HQX->read_data; # read in all the data
@rsrc = $HQX->read_resource; # read in all the resource

Bin to hex, low-level interface. Conversion is actually done via an object ("Convert::BinHex::Bin2Hex") which keeps internal conversion state:
# Create and use a "translator" object:
my $B2H = Convert::BinHex->bin2hex; # get a converter object
while (< STDIN >) {
print $STDOUT $B2H->next($_); # convert some more input
}
print $STDOUT $B2H->done; # no more input: finish up

Bin to hex, file interface. Yes, you can convert to BinHex as well as from it!
# Create new, empty object:
my $HQX = Convert::BinHex->new;

# Set header attributes:
$HQX->filename("logo.gif");
$HQX->type("GIFA");
$HQX->creator("CNVS");

# Give it the data and resource forks (either can be absent):
$HQX->data(Path => "/path/to/data"); # here, data is on disk
$HQX->resource(Data => $resourcefork); # here, resource is in core

# Output as a BinHex stream, complete with leading comment:
$HQX->encode(*STDOUT);

PLANNED!!!! Bin to hex, "CAP" interface. Thanks to Ken Lunde for suggesting this.
# Create new, empty object from CAP tree:
my $HQX = Convert::BinHex->from_cap("/path/to/root/file");
$HQX->encode(*STDOUT);

BinHex is a format used by Macintosh for transporting Mac files safely through electronic mail, as short-lined, 7-bit, semi-compressed data streams. Ths module provides a means of converting those data streams back into into binary data.

cfv is a utility to both test and create .sfv, .csv, .crc, .md5(sfv-like), md5sum, bsd md5, sha1sum, and .torrent files. These files are commonly used to ensure the correct retrieval or storage of data.
cfv is written in python, and as such should run on all platforms python supports. Currently, it has been verified to work on linux, freebsd, openbsd, netbsd, solaris, macosx, and windows.
Main features:
- supports testing and creating of .sfv, .csv(2, 3, and 4 field variants), .crc, sfvmd5(sfv file using md5 instead of crc32), md5sum, bsd md5, sha1sum, and BitTorrent file formats
- test-only support for PAR and PAR2 files
- automatic checksum file naming ability in create mode
- recursive operation
- show unverified files option
- ignore case and fix path seperator options for cross platform use
- transparent gzip support for checksum files
- configurable renaming of bad files (with testing against previous bad files, to save only unique differing copies)
- searching for/fixing of misnamed files
- raw listing of files of specified type (bad, missing, etc)
- test suite to ensure correct operation

Hardware::iButton is a Perl module that allows to talk to DalSemi iButtons via a DS2480 serial widget.

SYNOPSIS

use Hardware::iButton::Connection;
$c = new Hardware::iButton::Connection "/dev/ttyS0";
@b = $c->scan();
foreach $b (@b) {
print "family: ",$b->family(), "serial number: ", $b->serial(),"n";
print "id: ",$b->id(),"n"; # id = family . serial . crc
print "reg0: ",$b->readreg(0),"n";
}

This module talks to iButtons via the "active" serial interface (anything using the DS2480, including the DS1411k and the DS 9097U). It builds up a list of devices available, lets you read and write their registers, etc.

The connection object is an Hardware::iButton::Connection. The main user-visible purpose of it is to provide a list of Hardware::iButton::Device objects. These can be subclassed once their family codes are known to provide specialized methods unique to the capabilities of that device. Those devices will then be Hardware::iButton::Device::DS1920, etc.

iButtons and solder-mount Touch Memory devices are each identified with a unique 64-bit number. This is broken up into 8 bits of a "family code", which specifies the part number (and consequently the capabilities), then 48 bits of device ID (which Dallas insures is globally unique), then 8 bits of CRC. When you pass these IDs to and from this package, use hex strings like "0123456789ab".

Forth Foundation Library, in short FFL is a Forth library. It gives you a collection of words written in (ANS) forth which are useful in areas such as data types, collections, interfaces, development support, and compound modules.
The modules in the library are grouped in five clusters:
- Data types - char
- Collections - single linked list
- Interfaces - crc-32
- Development - struct, unit test
- Compound - nothing yet.
Enhancements:
- This release adds four new features to the library, including an n-tree with an iterator, a SHA-256 module, and a regular expressions module.
- The library will now also run on MinForth.

Mp3Wrap is a free independent alternative to AlbumWrap. Its a command-line utility that wraps quickly two or more mp3 files in one single large playable mp3, without losing filenames and ID3 informations (and without need of decoding/encoding).
Also it has the possibility of including other non mp3 files, such as PlayLists, info files, cover images, inside the mp3. This means that you obtain a large mp3 that you can split in any moment just using mp3splt and in few seconds you have all original files again! Its useful because files created with Mp3Wrap are easy to download. Infact who downloads has not to know each single song name and easy to play and even if you dont have mp3splt to split file, you can listen to it anyway. MP3Wrap the Free AlbumWrap.
Main features:
- Mp3Wrap is completely FREE and Open Source (under GPL License)
- Mp3Wrap files dont need ID3 to work. You can remove it, and still works
- Mp3Wrap index is always 1/10 sized than AlbumWrap (1 KB vs. 10 KB, with less probability of damage)
- Mp3Wrap is faster because you have not to select each file one at a time
- Mp3Wrap can include path info and other non mp3 files such as playlists
Enhancements:
- new important feature added: CRC introduced. Now wrapped files contain a CRC information to guarantee integrity of index and mp3data.
- new feature added: Verbose option introduced. Now -l option gives only list of filenames, -lv complete infos.
- new feature added: added a config file. User will write his customizations inside this file.
- new feature added: extension can be specified in config file as "EXT=my extension.mp3"
- feature improved: like mp3splt, now searches for index for 16384 bytes. This should be enough.
- bug fixed: file existence error is now correct.
- bug fixed: when an invalid option is specified, now program exits
- now sources are separated by functions for easy mantainance.
- added configure script to autodetect install and man directories for Linux version.

CGI::Application::Plugin::Authentication::Store::Cookie is a Cookie based Store.

SYNOPSIS

use base qw(CGI::Application);
use CGI::Application::Plugin::Session;
use CGI::Application::Plugin::Authentication;

__PACKAGE__->authen->config(
STORE => [Cookie, SECRET => "Shhh, dont tell anyone", NAME => CAPAUTH_DATA, EXPIRY => +1y],
);

This module uses a cookie to store authentication information across multiple requests. It works by creating a cookie that contains the information we would like to store (like the name of the user that is currently authenticated), and then base64 encoding the data. In order to ensure that the information is not manipulated by the end-user, we include a CRC checksum that is generated along with our secret. Since the user does not know the value of the secret, they will not be able to recreate the checksum if they change some of the values, so we will be able to tell if the information in the cookie has been manipulated.

3D Spatialization of Sound is a Linux/X11 port of the 3D spatializer library from the CRC.

This program creates "directional" stereo sound from mono source. CRC folks told me I shouldnt have raised the sampling frequency without adjusting other stuff.

Oh well. This was a proof-of-concept type project anyway. I think to get correct 3D effect, you need to drop sampling rate back to 11025.

To Build the X11 implementation:

1. make
2. cp audio-filter /usr/local/bin
3. mpg123 -m -s some_music.mp3 | audio-filter | aplay -S -s 44100 -f s16l -

audio-filter is implemented as a filter, it reads signed 16 bit mono input at 44100 khz from stdin, and outputs signed 16 bit stereo, 44100 khz output to stdout. You can replace mpg123 with any sound source generating signed 16 bit 44100 khz mono signal. "aplay" is a sound player utility which comes with ALSA linux sound driver. You can use "play" from the sox package, or "ampctl", or any other sound player that would read 44100 khz, signed 16 bit stereo raw data from stdin. For "sox" play script, you would replace "aplay" command line with "play -c 2 -f s -r 44100 -s w -t raw -"

If everything is good, a 640x480 window will come up, with some cryptic writing on the top, a filled circle with an arrow pointing right, and a empty circle slightly to the right of the circle with arrow.

NOTE, that just like in the original Windows implementation, the axiss are reversed. The arrow on the "head" is pointing "forward". So, in the default startup configuration, the sound is located in front of the listener. Moving the sound source "up" moves it to the left of the listener, and "down", to the right. You can visualize this well if you turn your monitor 90 degrees counter
clock wise.

The filled circle with an arrow is your "head"
The empty circle is the "sound source"

You can move the "sound source" around by clicking the mouse at any position in the window, or by clicking on the "sound source" circle, and dragging it to the desired position. Soundfield will be dynamically updated as you do this.

You can move the "head" by moving the mouse to desired position, and right-clicking. The "head" icon will move to the new position and soundfield will be updated.