For those of you who don't know, I have a degree in EET which more or less means I'm a much bigger nerd than I appear and every once in a while I see things on the web that really spark my interest on the EE side and this is very much one of them.

A quick overview of how phones work -- you are given a certain frequency range (3k I believe) which runs on top of a larger pipe (T1).  Within this pipe is a given frequency range and 24 channels, each channel has a guard band and 3k in each direction giving you a total of 8k of space (3k + 3k + 1k guard + 1k guard).  If you do the calculations, you'll find out how a T1 = 1.544mb.  Anyway, a nasty thing that can happen is cross talk.  This is when a given channel starts to flux outside of its given range and past the guard bands -- and thats very bad, you can begin to hear others conversations (who needs wire tapping eh?).  Anyway, when its running perfectly (or close enough), you'll never experience this, but it can happen.  Slight tangent, each channel is 64k which is also 1 voice channel and one channel of an ISDN line, sometimes called "fractial T1" depending on how is packaged (...or priced) but how you only get 56k over a phone line?  Hint - guardbands.

Anyway, ADSL works on regular phone lines at different frequencies, more specifically higher frequencies but there's a limit.  Well, this guy in Australia has figured it out.  I'm guessing he's using some kind of codec (encoder, kind of like what you use to create MP3s and videos) to jam more info into the same space with a little overhead.  Allow me to explain how this would work.  Say you have a text file with ...250k of info.  You would like to submit this file over some medium (flash drive, cables, whatever) but your limit is 35k, no more.  How would you do this?  Oh, there's a magical thing called "zip" that compresses that info into a much smaller space using a set of calculations/rules to reduce the size.  Yay that works, it cuts your file size down to under 35k and off your data goes.  When the recipient recieves this package however, it must know how you reduced (assuming it needs to, or more importantly, IF if even needs to uncompress) the payload.  If this is the only way to transmit, this is no problem otherwise another piece of verification must take place somewhere within the system, typically at the endpoint. As with anything, there's a catch -- the overhead.  Obviously, you shouldn't use a heavy heavy codec because that takes processing time and can slow down a system instead of speed it up.  Say for instance you are converting a movie of you took of your little ones into a file on your desktop.  Lets say native comes out to be 4gb (you're cool, you got an HD camera).  If you run it though a codec with some loss and convert it to ...700mb.  A good file reduction but now the codec to run it takes up 85% cpu to run.  Hmm, not a good trade off.  Another codec offers 1.2gb but only a 15% cpu usage when you run it.  Of course, you will have to consider your expected end point (is it a CD or DVD for instance).