geek

Oct 17, 2007 ∞

Yam No More

Back in my Amiga-using days, I had an email program called YAM. It was excellent and ubiquitous; almost everyone used it. It had three unique features:

• You could configure it to embed small bits of personal information in outgoing emails, such as your birthday.
• When it saw these bits in email that other people sent to you, it could add the information to your address book.
• It had an option to automatically send a “happy birthday” email to everyone in your address book on their birthday.

I was active on a lot of mailing lists, so my address book was pretty full with people I’d hardly met. I sent them happy birthday emails each year, and on my birthday, it was fun to get flooded with a few hundred little messages from well-wishers I didn’t know except maybe from some obscure discussion group.

I had the sad realization a few days ago that for the first time ever since I started using YAM, I didn’t receive a single email from it this year. Not one of my old friends still does this. While it’s not very big in the scheme of this, it still marks the sad end to a happy era.

Sep 24, 2007 ∞

Becoming Unrooted

So, I forgot my root password. For non-technical types, that’s pretty much the key to the kingdom when you need to get full access to a computer, or install new software, or to make backups, or to fix something in an emergency. I use this little program called “sudo” all the time that lets you do most of the same things except with your own password. I guess it’d been so long since I’d actually needed that root password that it just slipped my mind. Still, I felt pretty dumb and resigned myself to coming up with a new one and resetting it on all the computers I use.

So, this morning something came up where I really needed that password, and without thinking I picked up a keyboard and mashed it out. It worked. “Oh joy,” I though. “I’ll just do it again and pay attention to what I’m typing.” Except that try as I might, I just can’t type that password if I’m consciously thinking about it.

This has not improved my outlook on an upcoming birthday in the slightest.

Sep 5, 2007 ∞

baby.lisp

In our household, a baby just ain’t a baby without an appropriately geeky birth announcement. And since Nick is mostly functional — I mean, he can’t exactly type yet — this one is in Lisp. Share and enjoy!

; This program forks().  That should be plenty for a few years' entertainment
; Copyright (C) 2007 Kirk & Jennifer Strauser

; This program is free software: you can redistribute it and/or modify
; it under the terms of the GNU General Public License as published by
; the Free Software Foundation, either version 3 of the License, or
; (at your option) any later version.

; However, the output of this particular instance shall remain
; exclusively licensed to the authors for a period of up to eighteen
; years.

; $Id: baby.lisp 4 2007-09-05 23:18:12Z kirk $


(require :sb-posix)

(defvar *birthtime* (encode-universal-time 0 20 1 1 9 2007))

(defvar *age* (- (get-universal-time) *birthtime*))

(defun hello ()
  (format t "Hello, world!  My name is Nicholas Arthur Strauser and this is ~
my ~:r day!~%" (ceiling (/ *age* 86400))))

(defun labor ()
  (cond
   ((zerop (sb-posix:fork)) (format t "Ouch!~%"))
   (t (hello))))

(defun wait ()
  (cond
   ((< *age* 0)
    (sleep (- *age*))
    (setf *age* 0)
    (labor))
   (t (hello))))

(wait)

Jul 14, 2007 ∞

Negotiations With Western Digital

We bought a Western Digital external hard drive for Jen’s computer while we were in Omaha. I hooked it up when we got home and it was dead on arrival. I called for an RMA (“return material authorization” — basically permission to return it to the manufacturer) and got the replacement a few days later. Unfortunately, they didn’t include a pre-paid shipping label to return the defective part, and the customer service guy wasn’t too keen on giving me one. I wasn’t asking for anything unreasonable or that they just justifiably deny, and here’s how I got one anyway:

CS guy: It’s not our policy to give out shipping labels. It’s the customer’s responsibility to pay for shipping.

Me: It’s not this customer’s policy to pay for shipping products that were dead on arrival.

CS guy: I see your point, but that’s not something we normally do.

Me: OK, but I’d sure appreciate it. I mean, I did you a favor by calling you instead of returning this to the store. I didn’t know I’d have to pay for it.

CS guy: Well, we don’t do a very good job of telling you that on our website. I can ask my supervisor, but I don’t think he’ll do it.

Me: I’ll hold.

[5 minutes go by]

CS guy: Sir, this isn’t something we do, but since these are special circumstances, we’ll do it just this one time. You’ll get it within a week.

Me: Thanks! Oh, and can you extend my deadline for returning the broken one by a few days since I don’t have the shipping label yet?

CS guy: (sighs) Yeah, OK. You can have an extra 10 days.

Note two important things: first, I was polite; second, I was assertive. Failure on either of those would have wrecked the whole deal.

Jul 14, 2007 ∞

Electronic Survival Kit

So, you’ve made a survival kit to keep you alive until the good guys come to rescue you. Well, now you’re starting life over in a new place. These are some of the things you might want to bring along.

References

• <ask.slashdot.org/comments….>

How To Carry It

Electronically

Our primary goal is to make our data as easy to access as possible. This is critically important when you don’t know what kind of machine you may have to use to access your data. You might have a beautiful Mac or Unix workstation at home, but if you were at home and could use your computer, then the rest of this would be pointless. Regardless of what you normally use, expect to be using a Windows box to access it.

First, I highly recommend that you combine your files into a single Zip file. That’s because it’s much easier to manage one file than 100.

Second, and this is critically important, use an encryption program to put as password on the zip file! You’re going to be putting a lot of sensitive information in there, so don’t leave it out for any twit to find if you misplace your copy. I highly, highly recommend GNU Privacy Guard, or GPG. A package of it for Windows is available from http://www.gpg4win.org. Under no circumstances should you trust the lame “encryption” (bah!) that comes with some storage media like USB keychain drives, or such as is built into WinZip. I mean it! Use a stand-alone encryption program.

Don’t forget to put a copy of the installer on your backup media so that you’ll be able to unlock your data when you need it!

Third — and this is very important — create the zip file on your computer’s hard drive, then encrypt it, and finally move the encrypted file onto your backup media. You should never copy the unencrypted data onto that media! Even if you delete it afterward, it may be possible to recover the information.

By the same token, don’t decrypt the zipfile onto your backup media. Copy it onto the hard drive of the computer you’re using to access it, then decrypt it and unzip it from there. Of course, if you’re using a very public computer such as a rental at an Internet cafe, then that may actually be the worse option. Trust your own judgment, and let rampant paranoia be your guide.

Physically

A floppy ain’t gonna cut it. Your encrypted zipfile will probably be much larger than will fit on a floppy disk, unless your life is so simple that this is just an academic exercise. Your four main options, in the order I’d recommend them, are:

1. USB “keychain” drive
   • Pros: they’re durable and can be reused thousands of times. They’re also much smaller than a CD-R.
   • Cons: fewer computers have USB slots than CD-ROM drives, although that’s changing as old machines are replaced — almost all new computers have them.
2. CD-R
   • Pros: blank CD-Rs are cheap, most people have a CD burner (so you probably already have the equipment to make one), and almost every computer has a CD-ROM device to read it. Also, CD-Rs can hold a relatively huge amount of data for pennies.
   • Cons: every time you update your data, you have to throw away the old copy or risk packing away the wrong one. CD-Rs are relatively fragile; one fat scratch and your data is lost.
3. DVD-R
   • Same pros and cons as CD-R, except they hold much more data but are not as widely available as USB slots.
4. Free webmail account (Yahoo! Mail, Gmail, Hotmail, etc.)
   • Pros: access your data from any computer with Internet access. No physical media to lose or destroy.
   • Cons: it can take a long time to store or retrieve your data. Not every computer has Internet access. Your files may be larger than your webmail account can hold. If your webmail company is also destroyed in the disaster, you’re out of luck.

Remember, don’t forget to store a copy of the encryption program you’re using along with the encrypted data itself! Although you can always download another copy off the Internet, that may be inconvenient (especially if you don’t remember what it’s called because you just watched your house burn down and you’re under extreme duress).

Also, nothing says you can’t use more than one option. Just don’t forget to update all of them whenever you add more information.

Whichever you choose, it’s not a bad idea to store any physical media with your regular survival kit. If disaster strikes, you’re more likely to remember to grab your knife and matches than a CD-R or keychain drive.

The List

Store small amounts of information in a text file using an editor like Notepad (on Windows). Do not store it in a Word document! Believe it or not, many computers don’t have an office suite installed on them, and you’d be seriously limiting your access options at a time when you can least afford it.

When scanning documents, set the resolution to at least 125DPI (200 is preferable); greyscale (instead of color) is fine and will use less space). Use at least 300 for photos. Don’t just blindly turn your scanner to its highest setting, though, or you’ll never get all of your documents to fit onto your media.

• Employment
  • Current resume
  • Examples of your work
  • High school and/or college diplomas
  • Letters of recommendation
  • References
• Financial
  • Bank/investment accounts
  • Credit card numbers and expiration dates
  • Loan accounts
  • Insurance policy numbers
  • Contact numbers for all of the companies above!
• Identification
  • Baptism/dedication certificates
  • Birth certificates
  • Driver’s license
  • Family photos (also important for morale!)
  • Fingerprints
  • Marriage certificate
  • Passport
  • Tax returns
  • Voice recordings
• Medical
  • Dental records
  • Disease records
  • Immunization records
  • X-rays
• Property
  • Deeds and titles
  • Wills
• Contact information for lots of friends and relatives, preferably spread over a large geographical area so that they’re not all affected by the same disaster you’re fleeing

Summary

That list is pretty long and odds are you’ll never need it. However, if you do, won’t you wish you’d taken the time to get all this information together? Once you’ve managed to gather it, maintenance should be a snap — just make a new zip archive, encrypt it, and replace your old copy with the new one.

Just remember the basics:

• Pick one or two of the most durable media that can hold all of your information.
• Don’t trust the built in Zip encryption.
• Don’t trust the built-in USB keychain drive encryption.
• Don’t ever put your unencrypted data onto your backup media unless you have to.
• Include an (unencrypted) copy of your encryption program’s installer, or a standalone version that can be run directly from your storage media.
• Also include a copy of WinZip or another file extraction utility. Older versions of Windows don’t have that functionality built in.
• Keep current!

If you do happen to be affected by a local disaster, this information could be incredibly useful. Think about how impressed an interviewer would be to find out that you brought your resume and work samples with you. Imagine how glad the police would be to get a high-quality picture of missing family members. You buy insurance for your house and cars, right? Think of this as cheap insurance for your way of life.

Jul 3, 2005 ∞

Filtering Spam With Postfix

If you are responsible for maintaining an internet-connected mail-server, then you have, no doubt, come to hate spam and the waste of resources which comes with it. When I first decided to lock down my own mail-server, I found many resources that helped in dealing with these unwanted messages. Each of them contained a trick or two, however very few of them were presented in the context of running a real server, and none of them demonstrated an entire filtering framework. In the end I created my own set of rules from the bits and pieces I found, and months of experimentation and fine-tuning resulted in the system detailed in this article.

This article will show you how to configure a Postfix mail-server in order to reject the wide majority of unwanted incoming “junk email”, whether they contain unsolicited commercial email (UCE), viruses, or worms. Although my examples are specific to Postfix, the concepts are generic and can be applied to any system that can be configured at this level of detail.

For a real world example, I’ll use my server’s configuration details:

Hostname	kanga.honeypot.net
Public address	208.162.254.122
Postfix configuration path	/usr/local/etc/postfix

Goals

This configuration was written with two primary rules in mind:

1. Safety is important above all else. That is, I would much rather incorrectly allow an unwanted message through my system than reject a legitimate message.
2. The system had to scale well. A perfect system that uses all of my server’s processing power at moderate workloads is not useful.

To these ends, several checks — that may have reduced the number of “false negatives” (messages that should have been rejected but were not) at the cost of increasing the number of “false positives” (legitimate messages that were incorrectly rejected) — were avoided. The more resource-intensive tests were moved toward the end of the configuration. This way, the quick checks at the beginning eliminated the majority of UCE so that the longer tests had a relatively small amount of traffic to examine.

HELO restrictions

When a client system connects to a mail-server, it’s required to identity itself using the SMTP HELO command. Many viruses and spammers skip this step altogether, either by sending impossibly invalid information, or lying and saying that they are one of your own trusted systems — in the hopes that they will be granted undeserved access. The first step in the filtering pipeline, then, is to reject connections from clients that are severely mis-configured or that are deliberately attempting to circumvent your security. Given their simplicity, these tests are far more effective than might be imagined, and they were implemented in my main.cf file with this settings block:

1  smtpd_delay_reject = yes
2  smtpd_helo_required = yes
3  smtpd_helo_restrictions =
4     permit_mynetworks,
5     check_helo_access hash:/usr/local/etc/postfix/helo_access,
6     reject_non_fqdn_hostname,
7     reject_invalid_hostname,
8     permit

Line 1 is a fix for certain broken (but popular) clients, and is required in able to use HELO filtering at all. The second line rejects mail from any system that fails to identify itself. Line 4 tells Postfix to accept connections from any machines on my local network. The next line references an external hash table that contains a set of black- and whitelisted entries; mine looks like this:

woozle.honeypot.net     OK
honeypot.net            REJECT You are not me. Shoo!
208.162.254.122         REJECT You are not me. Shoo!

The first line in the table explicitly allows connections from my laptop so that I can send mail when connected through an external network. At this point Postfix has already been told to accept connections from all of my local machines and my short list of remote machines, so any other computer in the world that identifies itself as one of my systems is lying. Since I’m not particularly interested in mail from deceptive systems, those connections were flatly rejected.

Lines 6 through 8 complete this stage by rejecting connections from hosts that identify themselves in blatantly incorrect ways, such as “MAILSERVER” and “HOST@192.168!aol.com”.

Some administrators also use the reject_unknown_hostname option to ignore servers whose hostnames can’t be resolved, but in my experience this causes too many false positives from legitimate systems with transient DNS problems or other harmless issues.

You can test the effect of these rules, without activating them on a live system, by using the warn_if_reject option to cause Postfix to send debugging information to your maillog without actually processing them. For example, line 6 could be replaced with:

warn_if_reject,
   reject_non_fqdn_hostname,

This way the results can be observed without the risk of inadvertently getting false positives.

Sender restrictions

The next step is to reject invalid senders with these options:

9  smtpd_sender_restrictions =
10    permit_sasl_authenticated,
11    permit_mynetworks,
12    reject_non_fqdn_sender,
13    reject_unknown_sender_domain,
14    permit

Lines 10 and 11 allow clients that have authenticated with a username and password or Kerberos ticket, or who are hosts on my local network, to continue onward. Lines 12 and 13 work similarly lines 6 and 7 in the “HELO restrictions” section; if the sender’s email address is malformed or provably nonexistent, then there’s no reason to accept mail from them. The next line allows every other message to move on to the next phase of filtering.

Recipient restrictions and expensive tests

By this time, it’s clear that the client machine isn’t completely mis-configured and that the sender stands a reasonable chance of being legitimate. The final step is to see that the client has permission to send to the given recipient and to apply the remaining “expensive” tests to the small number of messages that have made it this far. Here’s how I do it:

15 smtpd_recipient_restrictions =
16   reject_unauth_pipelining,
17   reject_non_fqdn_recipient,
18   reject_unknown_recipient_domain,
19   permit_mynetworks,
20   permit_sasl_authenticated,
21   reject_unauth_destination,
22   check_sender_access hash:/usr/local/etc/postfix/sender_access,
23   check_recipient_access hash:/usr/local/etc/postfix/recipient_access,
24   check_helo_access hash:/usr/local/etc/postfix/secondary_mx_access,
25   reject_rbl_client relays.ordb.org,
26   reject_rbl_client list.dsbl.org,
27   reject_rbl_client sbl-xbl.spamhaus.org,
28   check_policy_service unix:private/spfpolicy
29   check_policy_service inet:127.0.0.1:10023
30   permit

Many spammers send a series of commands without waiting for authorization, in order to deliver their messages as quickly as possible. Line 16 rejects messages from those attempting to do this.

Options like lines 17 and 18 are probably becoming familiar now, and they work in this case by rejecting mail targeted at domains that don’t exist (or can’t exist). Just as in the “Sender restrictions” section, lines 19 and 20 allow local or authenticated users to proceed — which here means that their messages will not go through any more checks. Line 21 is critically important because it tells Postfix not to accept messages with recipients at domains not hosted locally or that we serve as a backup mail server for; without this line, the server would be an open relay!

The next line defines an access file named sender_access that can be used as a black- or whitelist. I use this to list my consulting clients’ mail-servers so that none of the remaining tests can inadvertently drop important requests from them. I added line 23, which creates a similar blacklist called recipient_access for recipient addresses, as an emergency response to a “joe job”. Once in 2003, a spammer forged an email address from my domain onto several million UCE messages and I was getting deluged with bounce messages to “michelle@honeypot.net”. I was able to reject these by adding an entry like:

michelle@honeypot.net REJECT This is a forged account.

Although the event was annoying, this allowed my server to continue normal operation until the storm had passed.

Line 24 is the last of the “inexpensive” checks. It compares the name that the remote system sent earlier via the HELO command to the list of my secondary mail servers and permits mail filtered through those systems to be delivered without further testing. This is the weak link in my filtering system, because if a spammer were clever enough to claim that they were one of my backup servers then my mail server would cheerfully deliver any message sent to it. In practice, though, I’ve never seen a spammer that crafty and this line could be removed without side effects should the need arise.

Lines 25 through 27 are somewhat more controversial than most of my techniques, in that they consult external DNS blackhole lists in order to selectively reject messages based on the IP address of the sender. Each of these lists have been chosen because of their good reputation and very conservative policies toward adding new entries, but you should evaluate each list for yourself before using their databases to drop messages.

SPF and greylisting

Lines 28 and 29 add Sender Policy Framework (SPF) and greylisting filtering respectively. SPF works by attempting to look up a DNS record, that domains can publish, which gives the list of addresses allowed to send email for that domain. For example, webtv.net’s SPF record is currently “v=spf1 ip4:209.240.192.0/19 -all”, which means that a message claiming to be from joeuser@webtv.net sent from the IP address 64.4.32.7 is forged and can be safely rejected.

Greylists are pure gold when it comes to rejecting junk email. Whenever a client attempts to send mail to a particular recipient, the greylist server will attempt to find that client’s address and the recipient’s address in its database. If there is no such entry then one will be created, and Postfix will use a standard SMTP error message to tell the client that the recipient’s mailbox is temporarily unavailable and to try again later. It will then continue to reject similar attempts until the timestamp is of a certain age (mine is set to five minutes). The theory behind this is that almost no special-purpose spam sending software will actually attempt to re-send the message, but almost every legitimate mail server in existence will gladly comply and send the queued message a short time later. This simple addition cut my incoming junk email load by over 99% at the small cost of having to wait an extra five minutes to receive email for the first time from a new contact. It has worked flawlessly with the many mailing lists that my clients and I subscribe to and has not caused any collateral problems that I am aware of. If you take nothing else from this article, let it be that greylisting is a Good Thing and your customers will love you for using it.

I use the smtpd-policy.pl script that ships with Postfix to handle SPF, and Postgrey as an add-on greylisting policy server. They’re defined in my master.cf file as:

spfpolicy  unix  -       n       n       -       -       spawn
  user=nobody argv=/usr/bin/perl /usr/local/libexec/postfix/smtpd-policy.pl
greypolicy  unix  -       n       n       -       -       spawn
  user=nobody argv=/usr/bin/perl /usr/local/libexec/postfix/greylist.pl

Content filtering

The messages remaining at this point are very likely to be legitimate, although all that Postfix has actually done so far is enforce SMTP rules and reject known spammers. Their final hurdle on the way from their senders to my users’ mailboxes is to pass through a spam filter and an antivirus program. The easiest way to do this with Postfix is to install AMaViS, SpamAssasin, and ClamAV and then configure Postfix to send messages to AMaViS (which acts as a wrapper around the other two) before delivering them, and line 31 does exactly that:

31 content_filter = smtp-amavis:127.0.0.1:10024

SpamAssassin is fantastic at identifying spam correctly. Its “hit rate” while used in this system will be much lower than if it were receiving an unfiltered stream, as most of the easy targets have already been removed. I recommend setting AMaViS to reject only the messages with the highest spam scores; I arbitrarily picked a score of 10.0 on my systems. Then, tag the rest with headers that your users can use to sort mail into junk folders.

ClamAV has proven itself to be an effective and trustworthy antivirus filter, and I now discard any message that it identifies as having a viral payload.

Unfortunately, the configuration of these systems is more complicated than I could hope to cover in this article, as it depends heavily on the setup of the rest of your email system. The good news is that literally less than 1% of junk email makes it this far into my system, and I’ve actually gone for several days without realizing that SpamAssassin or ClamAV hadn’t been restarted after an upgrade. Still, these extra filters are very good at catching those last few messages that make it through the cracks.

Other possibilities

If you want more aggressive filtering and can accept the increased risk of false positives, consider some of the other less-conservative blackhole lists such as the ones run by SPEWS or the various lists of blocks of dynamic IP addresses. You may also consider using the reject_unknown_hostname option mentioned in the “HELO restrictions” section, but you can expect a small, measurable increase in false positives.

The ruleset described above should be sufficient on its own to eliminate the vast majority of junk email, so your time would probably be better spent implementing and adjusting it before testing other measures.

Conclusion

None of the techniques I use are particularly difficult to implement, but I faced quite a challenge in assembling them into a coherent system from the scraps I found laying about in various web pages and mailing lists.

The most important thing I learned from the process was that it’s easy to experiment with Postfix, and it can be customized to your level of comfort. When used in my configuration, the most effective filters are:

• Greylisting
• DNS blackhole lists
• HELO enforcement

Greylisting has proven to be an excellent filter and I’ve deployed it successfully on several networks with nothing but positive feedback from their owners. Even the basic HELO filtering, though, can visibly decrease spam loads and should be completely safe. It can be difficult to find a good compromise between safety and effectiveness, but I believe I’ve found a solid combination that should work in almost any situation. Don’t be afraid to test these ideas on your own and make them a part of your own anti-spam system!

Notes and resources

• Postfix Configuration — UCE Controls
• SPF: Sender Policy Framework
• Greylisting.org — a great weapon against spammers
• Postgrey — Postfix Greylisting Policy Server
• AMaViS — A Mail Virus Scanner
• The Apache SpamAssassin Project
• Clam AntiVirus

Copyright information

This article is made available under the “Attribution-Sharealike” Creative Commons License 2.5 available from http://creativecommons.org/licenses/by-sa/2.5/.

Reprint information

This article was originally published in Free Software Magazine. I’m reposting it here for backup purposes.

Aug 14, 2002 ∞

The Amiga Alternative Audio Page

Note: This is an exact snapshot of the page as it was last modified by CISC back in 2002. I hadn’t bothered importing the page into the new site until I saw a gazillion 404 errors in the logs. Y’all really want your Amiga MP3 encoders, don’t you? That’s OK. I’ll keep the lights on for my friends on their wonderful older systems.

---

This is the new combined RealAudio-and-Lame home page. Much of the information was redundant, so this made a lot more sense.

Updated! (14.08.2002)

This time we have yet another newcomer .. Ogg Vorbis, the audio codec that will conquer the world (“What are we going to do tonight Brain? The same thing we do every night Pinky .. Conquer The World!”)…

Ahwell, maybe, maybe not, time will tell .. in the meantime you can atleast play around abit with it yourself … Enjoy…

Ogg Vorbis is quite a resource hog though, so only 060 (barely usable on my 060/50) and MorphOS binaries included (ixemul required)…

Finally, the encoder works! Updated all the binaries with some minor fixes from CVS, and changed some options for slight speedup.

For more info on Ogg Vorbis, check out Ogg Vorbis homepage…

New! (19.05.2002)

RAPlay v3.1 finally hit Aminet!

News for v3.1:

• Fixed stereo output.
• Updated liba52.
• Minor cleanup.

News for v3.0:

• RealAudio v3.0 support!
• Support for RealMedia files. ¹
• Added AIFF argument-switch.
• Added VERBOSE argument-switch.
• Major cleanup and code improvements.

¹) only the supported codec (v1/2/3) streams.

New! (25.04.2002)

New LAME non-beta version 3.92!

Sorry for the delay, but my A4k died recently, so I’ve been kinda out of touch with the world, however I’ve managed to borrow one, which enabled me to make this release for you, enjoy…

As usual, read the history to see what’s new…

New! (21.12.2001)

StreamRA updated!

The new RAPlay doesn’t really work with AUDIO: anymore, so the StreamRA script had to be updated to use the new (and better) RAPlay arguments .. also it now makes sure to supply sufficient stack for RAPlay…

New! (22.10.2001)

((23.10.2001) Ooops, forgot to set the rights on madplay.lzx, sorry to all you who tried to download it earlier)

Today we have a brand new port-release for you .. madplay, the best mpeg-audio player out there .. this will make a nice complement to the LAME encoder…

The archive comes with binaries for 68040 and MorphOS…

Please read the included amiga.readme for special instructions on usage!

From the MAD README:

MAD has the following special features:

• 24-bit PCM output
• 100% fixed-point (integer) computation
• completely new implementation based on the ISO/IEC standards
• distributed under the terms of the GNU General Public License (GPL)

Because MAD provides full 24-bit PCM output, applications using MAD are able to produce high quality audio. Even when the output device supports only 16-bit PCM, applications can use the extra resolution to increase the audible dynamic range through the use of dithering or noise shaping.

Because MAD uses integer computation rather than floating point, it is well suited for architectures without a floating point unit. All calculations are performed with a 32-bit fixed-point integer representation.

Because MAD is a new implementation of the ISO/IEC standards, it is unencumbered by the errors and copyrights of other implementations. MAD is NOT a derivation of the ISO reference source or any other code. Considerable effort has been expended to ensure a correct implementation, even in cases where the standards are ambiguous or misleading.

Note: If you have problems downloading, press the shift key while you click the link.

Link	Size	Description
		Ogg Vorbis
vorbis-tools.lzx	1100KB	Ogg Vorbis 1.0 Binaries (060/MOS)Updated!
		MAD (Mpeg Audio Decoder)
madplay.lzx	220KB	MAD 0.14.0b madplay Binaries Updated!
		LAME MP3 Encoder
LAMEbeta.lzx	550KB	Beta version 3.89 Binaries
LAMEbin.lzx	640KB	Version 3.92 Binaries (020/NoFPU/040/060/PPC)Updated!
LAMEdoc.lzx	38KB	Documentation Updated!
LAMEsrc.lzx	280KB	Source code for the latest release version Updated!
		BladeEnc
BladeEnc.lzx	405KB	An alternative to LAME
		RealAudio
		Combined RA and RA2 decoders:
RAPlay.lha	380KB	Multi-format (RealAudio v1/2/3) player (020, 881, 040, 060, PPC) v3.1 Updated!
RA-PPC-Both.lha	242KB	WarpUp and PowerUp (SAS/C and GCC/EGCS)
RAPlayer.lha	182KB	Multi-format (RA and RA2) player (040, 060, PPC) v1.3
StreamRA.lha	3KB	CISC’s streaming program. Get this to listen to (some) streamed audio. Updated!
		Old single-mode RA decoders:
RA2.lha	89KB	This is the main RA decoder, plus docs and sample AREXX script.
RA2upd.lha	16KB	These are just the files that have changed since the last release.
GeekGadgets archive	Big!	Get the file called “ixemul-some number-bin.tgz”.
UnTGZ	10KB	Use this to uncompress the ixemul archive.
		Plus, you’ll need one of these:
Play16	177KB	Command-line sample player. You should have this anyway; it’s great!
AHI	287KB	Amiga’s retargetable audio system - think CyberGraphX for sound.
		CPU-specific builds:
RA2-000.lha	9KB	68000 - no FPU, 2:12.15
RA2-020.lha	9KB	68020 - no FPU, 2:12.83
RA2-040.lha	9KB	68040 - no FPU, 20.15
RA2-020-FPU.lha	8KB	68020 with FPU, 22.44
RA2-040-FPU.lha	9KB	68040 with FPU, 14.93
RA2-PPC-PuP1.lha or RA2-PPC-PuP2.lha	109KB or 25KB	PPC (PowerUp), both versions or PPC (PowerUp), RA2 only, 6.35
RA2-020-FPU-libnix.lha	10 KB	68020 with FPU and libnix, 21.89
RA2-040-FPU-libnix.lha	10 KB	68040 with FPU and libnix, 14.81
		SoX Sound Format Converter
SoX.lzx	388KB	Convert those sounds!

FAQ

What is RA?

It is a command-line based decoder for RealAudio data streams. It takes a .ra input file and converts it into an easy-to-play raw sample.

Will it run on my Amiga?

Yes, it should, assuming you have a decently modern version of the OS. Folks, a bit of honesty here: if you’re using less than 3.0, please don’t submit bug reports. I won’t attempt to support older versions. Also note that while the base archive includes only the plain 68000 executables, you’ll really want to get one of the CPU-specific archives for reasonable performance.

Will it play all RealAudio files?

No. A lot of files will work, a lot won’t. Please don’t report non-working files to me - in all likelihood, I won’t be able to do a thing about it.

Where can I find some of these files?

The same places you’ve run across them before with Netscape or MSIE. One of the more interesting sites is Art Bell’s home page. Some other files are on the Gold Tooth page.

What does “streaming” mean?

Streaming means that you can process a file as it’s being transferred. In this case, it means that it is possible to play back the RealAudio file while it is being downloaded.

So?

This gives you the distinct advantage of not actually having to store the file on your hard drive. Plus, it’s kinda cool. :)

What is rastream.rexx?

It’s a program to demonstrate streaming. Ignore it, and use CISC’s great StreamRA! rastream.rexx was just a little toy that I spent about 3 minutes writing as a proof-of-concept.

What are these .ram files (notice the “m” at the end)? Why doesn’t RA decode them?

An employee at RealNetworks pointed me to their Attaching RealAudio Files To Web Pages page.

What is Play16?

Play16 is an Amiga sample player. Quite simply, it’s absolutely brilliant. To make Play16 play RA’s output files, use the arguments RAW, FREQ, and BITS like so:

Play16 RAoutputfile RAW FREQ 8000 BITS 16

What is AHI?

AHI is a retargetable audio system. It provides programmers with a common API to play sounds back on any supported audio hardware. For example, if a programmer makes his project AHI-compatible, it can automatically use the Amiga’s native Paula output or any of the sound cards that AHI has drivers for. It’s the audio equivalent of CyberGraphX, if that helps.

Why do you use AHI?

It does some really neat stuff. For example, you can calibrate your Amiga’s built-in sound hardware, so that sounds played back through AHI sound as good as physically possible. Also, it provides a nifty AUDIO: device that you can copy samples to for real-time playback.

Did you write RA?

I wish I could take credit, but I can’t. The source code archive came from a Usenet posting, as did patches and recommendations for improvement. Hence the credit line in the version string; this is a group collaborative, not an individual effort.

Why is RA significant?

Mainly because we were told that it couldn’t be done. RealAudio’s authors repeatedly chose to ignore our requests to port RealAudio to the Amiga, ostensibly because our beloved computer couldn’t handle the computing demands. RA, if nothing else, proves this to be total BS.

Is RA being ported to other platforms?

Yes, it is. I have to admit that this surprised me. However, RealNetworks seems to be ignoring several platforms, not just AmigaOS. Known ports can be found for:

• MS-DOS
• OS/2

If you know of any other ports, please let me know. I’ll be happy to cross-link any sites.

Thanks for 28.8! How did v2.0 come about anyway?

Boy, isn’t that a story and a half! That’s all you get to know.

The Amiga RealAudio mailing list has been cancelled due to lack of interest.

For LAME correspondence, write to lame@honeypot.net.

RealAudio questions and comments should be addressed to ra@honeypot.net.