Ports Search

The audio part of the MPEG standard specifies three layers, whereat each layer specifies its own file format. All three layers are using similar audio coding techniques, but they vary in efficiency and complexity. Layer I needs the fewest calculation time for en-/decoding a stream, layer III the most. But a layer I MPEG audio stream is bigger than a layer III stream at the same quality. This program is able to decode and play only layer I and II streams, layer III is not supported (yet?!?). The maplay decodes layer I and layer II MPEG audio streams and plays them using a CD-quality audio device or sends the to stdout normally as 16 bit signed PCM values, interleaved for stereo streams. This player supports all modes, which are single channel, stereo, joint stereo and dual channel, and all bitrates except free mode. The missing free mode support should not be a problem for now, because I haven't seen such a stream yet. LICENSE: GPL2 or later

VorbisGain is a utility that uses a psychoacoustic method to correct the volume of an Ogg Vorbis file to a predefined standardized loudness. It is meant as a replacement for the normalization that is commonly used before encoding. Although normalization will ensure that each song has the same peak volume, this unfortunately does not say anything about the apparent loudness of the music, with the end result being that many normalized files still don't sound equally loud. VorbisGain uses psychoacoustics to address this deficiency. Moreover, unlike normalization, it's a lossless procedure which works by adding tags to the file. Additionally, it will add hints that can be used to prevent clipping on playback. It is based upon the ReplayGain technology. The end result is that the file ends up with superior playback quality compared to a non-VorbisGain'ed file. It needs player support to work. Non-supporting players will play back the files without problems, but you'll miss out on the benefits.

SDR-J (formerly Jsdr) is a suite of four programs provided under a LGPL open source license for playing around with sdr (software defined radio). The software can be used directly with the PM-SDR kit and RTL2832U based dongles, and in the 32 bits Windows version with other kits as well. The suite contains four programs: - a full blown "short wave" receiver, which provides tuning in the range of 100K .. 165M using the PM-SDR (although above 55 M with reduced performance) and from app 55 MHz to app 900 Mhz or above using an RTL2832U based dongle. The receiver provides quite a number of decoders for amateur modes. - am/fm receiver covering the same frequency bands as the sw receiver, however, with am bandwidths selectable, with fm mono and stereo decoding as well as with rds decoding. - spectrum viewer for use with the RTL2832U based dongles, showing spectra of up to 3 Mhz bandwidth. - mini receiver, a stripped version of the fm receiver, a gadget for listening to WFM using DAB sticks.

Sqitch is a database change management application. What makes it different from your typical migration-style approaches? A few things: ## No opinions Sqitch is not integrated with any framework, ORM, or platform. Rather, it is a standalone change management system with no opinions about your database engine, application framework, or development environment. ## Native scripting Changes are implemented as scripts native to your selected database engine. Writing a PostgreSQL application? Write SQL scripts for psql. Writing a MySQL-backed app? Write SQL scripts for mysql. ## Dependency resolution Database changes may declare dependencies on other changes -- even on changes from other Sqitch projects. This ensures proper order of execution, even when you've committed changes to your VCS out-of-order. ## No numbering Change deployment is managed by maintaining a plan file. As such, there is no need to number your changes, although you can if you want. Sqitch doesn't much care how you name your changes. ## Iterative development Up until you tag and release your application, you can modify your change deployment scripts as often as you like. They're not locked in just because they've been committed to your VCS. This allows you to take an iterative approach to developing your database schema. Or, better, you can do test-driven database development.

The T2 module is a base for the refactoring of the now quite stable Tangram Object-Relational mapper. In a nutshell, it lets you store objects - which have to be described to a similar level that you would describe a database to store them - into any SQL store. Currently, this is tested on PostgreSQL, MySQL, Oracle and Sybase a lot, though in general database-specific extensions to SQL, such as triggers, stored procedures, etc are avoided. So, if DBI installs and tests successfully with your database, there is a good chance that T2 will work with it too. The only current requirement is that objects that have tables associated with them are implemented via hashes. You also have to be able to describe all of the fields for those root objects. Individual fields of stored objects may be arbitrarily complex. If you are familiar with DBI, it is somewhat similar to bless'ing the structures returned by $dbh->fetchrow_hashref, except that references and collections to other objects in the store are loaded `on demand' (aka Lazy-loading).

This module provides perl access to Glib and GLib's GObject libraries. GLib is a portability and utility library; GObject provides a generic type system with inheritance and a powerful signal system. Together these libraries are used as the foundation for many of the libraries that make up the Gnome environment, and are used in many unrelated projects. This wrapper attempts to provide a perlish interface while remaining as true as possible to the underlying C API, so that any reference materials you can find on using GLib may still apply to using the libraries from perl. Where GLib's functionality overlaps perl's, perl's is favored; for example, you will find perl lists and arrays in place of GSList or GList objects. Some concepts have been eliminated; you need never worry about reference-counting on GObjects or GBoxed structures. Other concepts have been converted to a perlish analogy; the GType id will never be seen in perl, as the package name serves that purpose. [FIXME link to a document describing this stuff in detail.]

Luka is an exception handling and reporting framework. It's useful to look at it as an event handling framework. It comes from operational understanding of networks. Scenario that Luka is addressing is following: on a network with multiple hosts running multiple applications, it is very difficult to track operational status of all the functionality that those applications and hosts are meant to deliver. In order to make it easier, we decided to specify the error handling and reporting data model that each component delivering functionality has to conform to. What is a component? In most cases, it is a script, often run from cronjob, in some cases it is a class in an application. In all cases, a component has to successfully complete a task on which functionality of an application, or entire network, relies on. It is common practice that programmers choose their way of handling errors and reporting. Luka is an attempt to standardize that process. Its primary goal is to make it easier for smaller number of people to keep larger number of applications and networks running.

Test::Command intends to bridge the gap between the well tested functions and objects you choose and their usage in your programs. By examining the exit status, terminating signal, STDOUT and STDERR of your program you can determine if it is behaving as expected. This includes testing the various combinations and permutations of options and arguments as well as the interactions between the various functions and objects that make up your program. The various test functions below can accept either a command string or an array reference for the first argument. If the command is expressed as a string it is passed to system as is. If the command is expressed as an array reference it is dereferenced and passed to system as a list. The final argument for the test functions, $name, is optional. By default the $name is a concatenation of the test function name, the command string and the expected value. This construction is generally sufficient for identifying a failing test, but you may always specify your own $name if desired. Any of the test functions can be used as instance methods on a Test::Command object. This is done by dropping the initial $cmd argument and instead using arrow notation.

Skip test scripts if modules are not available. The requested modules will be loaded, and optionally have their versions checked. If the module is missing, the test script will be skipped. Modules that are found but fail to compile will exit with an error rather than skip. If used in a subtest, the remainder of the subtest will be skipped. Skipping will work even if some tests have already been run, or if a plan has been declared. Versions are checked via a $module->VERSION($wanted_version) call. Versions must be provided in a format that will be accepted. No extra processing is done on them. If perl is used as a module, the version is checked against the running perl version ($]). The version can be specified as a number, dotted-decimal string, v-string, or version object. If the RELEASE_TESTING environment variable is set, the tests will fail rather than skip. Subtests will be aborted, but the test script will continue running after that point.

Pyro is short for PYthon Remote Objects. It is an advanced and powerful Distributed Object Technology system written entirely in Python, that is designed to be very easy to use. Never worry about writing network communication code again, when using Pyro you just write your Python objects like you would normally. With only a few lines of extra code, Pyro takes care of the network communication between your objects once you split them over different machines on the network. All the gory socket programming details are taken care of, you just call a method on a remote object as if it were a local object! Pyro provides an object-oriented form of RPC. You can use Pyro within a single system but also use it for IPC. For those that are familiar with Java, Pyro resembles Java's Remote Method Invocation (RMI). It is less similar to CORBA - which is a system- and language independent Distributed Object Technology and has much more to offer than Pyro or RMI. But Pyro is small, simple and free!