Free packetshaper 7500 software for linux

Audio::MPEG is a Perl module for encoding and decoding of MPEG Audio (MP3).

SYNOPSIS

use Audio::MPEG;

Audio::MPEG is a Perl interface to the LAME and MAD MPEG audio Layers I, II, and III encoding and decoding libraries.

Rationale

I have been building a fairly extensive MP3 library, and decided to write some software to help manage the collection. Its turned out to be a rather cool piece of software (incidentally, I will be releasing it under the GPL shortly), with both a web and command line interface, good searching, integrated ripping, archive statistics, etc.

However, I also wanted to be able to stream audio, and verify the integrity of files in the archive. It is certainly possible to stream audio (even with re-encoding at a different bitrate) without resorting to writing interface glue like this module, but verification of the files was clumsy at best (e.g. scanning stdout/err for strings), and useless at worst.
Thus, Audio::MPEG was born.

LAME

This is arguably the best quality MPEG encoder available (certainly the best GPL encoder). Portions of the code have been optimized to take advantage of some of the advanced features for Intel/AMD processors, but even on non-optimized machines, such as the PowerPC, it performs quite well (faster than real-time on late 90s (and later) machines).

MAD

This is a relatively new MPEG decoding library. I chose it after struggling to clean up the MPEG decoding library included with LAME (which is based on Michael Hipps mpg123(1) implementation). In the end, I was very pleased with the results. MAD performs its decoding with an internal precision of 24 bits (pro-level quality) with fixed-point arithmetic. The code is very clean, and seems rock-solid. Although it may seem that it should be faster than the mpg123(1) library due to the use of fixed-point arithmetic, it is in fact about 60% or so of the speed (due to the higher resolution audio). However, the ease of coding against MAD, and the higher precision of the output more than makes up for the slower decoding.

Audio::MPEG can export the data at its highest precision for programs that wish to manipulate the data at the higher resolution.

Operating System Environment

I have only tested this on a Linux 2.4.x system so far, but I see no reason why it should not work on any Un*x variant. In fact, it may actually even work on a Windoze box (the underlying LAME and MAD libraries apparently compile somehow on them). I am doing no special magic with the interface, so presumably it will work under Windows. As you can probably tell, I dont really care if it does (Ill may start caring if M$ releases the source code to Windows under GPL, BSD, or Artistic licenses...). But, for you poor, misguided souls that insist upon running Windows, I expect that there should be little problem getting it to work.

Performance

You would think that with encoding/decoding audio, which is quite a compute-intensive task, Perl would be much slower than the equivalent pure C programs. Surprise... it is only about 3% slower (!) Even with the mechanism I use here (Perl->C->Perl for every frame, Perl 5.6.1 and Linux 2.4.4 (PowerPC 7500) performs just fantastic. So, the moral of this paragraph is to run your own performance tests, but theres no need to think of your own Perl encoder/decoder will be inferior to a pure C/C++ implementation. The only drawback is that, depending upon how much buffer space you use for reading, memory usage will be at least 3 times as much (eh... RAM is cheap...)

The SFSU Penaltybox is a solution for high network traffic in residence halls. It implements a bandwidth quota, penalizing the users who cause most of the network congestion.

When users go over their bandwidth quota in a time period their traffic is limited using a Packeteer PacketShaper for a certain period of time before they are let out from the penalty box.

The users will be blocked immediatly when they exceed their limit, and they will be blocked from that point on for how ever long you set your time period. (eg we have a 10 gb/week limit, so if they go over on day 3, they will be limited to 64kbps until day 10, they will be blocked for an entire week after they have exceed their limit).