[ The Internet Project ]

----------

Data Formats

Index

Introduction to compression

To compress something means that you have a piece of data and you decrease its size. There are different techniques who to do that and they all have advantages and disadvantges. One trick is to reduce reduntant information, meaning saving sometimes once instead of 6 times. Another one is to find out which parts of the data are not really important and just leave those away. Before you can use the data again, it must be decompressed. Using compressed data saves time, bandwidth and disc space and the Internet we know wouldn't be possible without compression.

| Back to Top |

Loseless compression

How can you recognize loseless compression? Very easy, you compress something and after you decompressed it again, it must be exactly the same piece of data it was before you compressed it. If only one BIT is different, it's not loseless compression.

The name loseless means "no data is lost", the data is only saved more efficiently in its compressed state, but nothing of it is removed. How can this be done? The simples way is called RLE (Run Length Encoding), what simply is: Instead of writing "aaaaaaaaa" to a file, you would write "aX9" (read as "a 9-times"). The first string used 9 bytes, the second one 3 bytes, 2/3 of bandwidth saved ^_^

A bit more efficient than that is LZW (an acronym built from the first letters of the names of its creators). When using LZW, a dictionary is made that can have single chars, but also whole strings of chars (without any limitations, strings up to 500 chars and above are possible). Instead of writing the strings itself to disc, only the dictionary entry numbers are written there. While this isn't helpful for single chars (as one char uses 8 BITs, while a dictionary entry uses 10, 12 and up to 14 BITs), it gets really useful when you can save a string of 10 chars (=80 Bits) with one dictionary entry. Pictures often have lot's of repeating data that can get compressed that way. The advantage of LZW is that you don't have to save the dictionary itself as the decompressor can "rebuild" it only with the compressed data itself.

The last one is Huffman-Coding (named after its inventor). It is as simply as effective: Every char is 8 BIT long on a PC system, but when interpreting the ASCII number of the chars in binary format as a binary tree (meaning a tree-like structure, where the leaves have the values of the chars), it's possible to give chars variable BIT-lengths. This means I can reduce the BIT-length of certain chars, but whenever I make one char smaller, I must therefor increase the length of one or more other chars. This needn't be a problem considering that chars don't show up in files with the same commonness. The chars that show up more often get short lengths that way and those that show up nearly never get longer lengths, summarizing this you can save a lot of space. Especially since you can alter this length-reassignment "on-the-fly" when necessary in case the commonness of the chars has changed dramatically. But unlike the LZW algorithm you have to save your altered binary-tree, as the decompressor can't rebuild it from the compressed data.

Usually compressors make use of all three compression methods. First long, repeating strings of single chars are removed with RLE, then LZW removes repeating strings of various chars and last but not least, Huffman-Coding assigns the 10 to 14 BIT long dictionary entries new BIT lengths according to their commonness. Only in this combination it will produces good results.

| Back to Top |

Losy compression

When you compress a program file and only one BIT would change, it may not run anymore (or have other errors), so here you would use loseless compression, but when you compress data, it isn't always necessary to get everything across. If I alter a single BIT of a picture or an audio file, nobody will ever recognize this error.

Losy compression bases on the assumption that our current data files save more information than human beings can "perceive". An example is a true-color picture; it contains up to 16.7 millions colors, but in fact our eyes can't distinguish a amount of half that many colors. We save audio-files with 16 BITs, but most people can't distinguish between 12 and 16 Bits anymore, not to mention that a human ear can hear frequencies from 20 Hz to 20 kHz, but only very few at once, nevertheless we save all of them at the same time when they occur.

When I save data losy, decompress it again and compare it to the original data (with a file comperator) I can easily see that it's not the same piece of data anymore, it got several errors. Nevertheless, if I used a good compressor, those errors are neither see/hear-able when I listen to/view the file. Sometimes you are also willing to accept view/hear-able errors if you therefor get a lot better compression results.

Most losy compression methods use a combination of both, losy and loseless compression. First data is removed and the rest is than compressed loseless. Because of the removal before, the data is not only smaller but will usually be more "redundant", meaning the loseless compression methods can save it a lot efficiently than without this removal. Usually losy compressors produce a lot smaller files than loseless compressors and sometimes their usage is unavoidable.

An important rule for people working with losy compression formats:
When the data is compressed, parts of it is removed and errors are placed inside the file. When you decompress it (e.g. to alter it) and then compress it again, data will be removed for a second time and additional errors will be added for a second time. If then somebody else does the same it will happen for a third time and so on. This means the quality of the data will be worse and worse until pictures look horribly smeared and instead of music only noise is left!!! So try to avoid saving data from a losy format into another losy format.

Usually you would only save original data in a losy format and if you would decompress it to alter it, you would choose a loseless format for archiving. Because the fact that the compressor was good enough to hide its errors after compressing it for the first time, doesn't mean that it will still be able to achieve such a good result for a second time, because the compressor can't know that the data was already compressed before. losy compressors always "believe" that you are providing them with uncompressed, new data which is now compressed losy for the first time! That's the way they are built.

| Back to Top |

Compression Formats

Compressors are programs that compress data. Since losy compressors base on a certain file types only (picture, music, video, etc.), I will only mention loseless here as they are able to compress any kind of data. Later on, when I'm talking about losy data formats, I'm going to mention some compressors that allow you to save data into that format.

Every format will have a table at its end that is summarizing its abilities. Here is the explanation of what was tested:

Speed
A large test file was compressed and this is the subjective impression of the compression speed (subjective as I didn't take a watch to exactly measure the time).

Compression ratio
A relative comparison of the different file sizes once the file was compressed.

Platform support
What OSes and non-x86 PCs can read this file type. Not all people work on Windows or Linux, some don't even use a normal PC, but a Power, AlphaPC with an operating system like Solaris, IRIX or BeOS. The more platforms can read this file type, the better.

User friendliness
Here I looked at questions like: How much options do you need to know for configuration? Does it have an easy to use GUI (User Graphics Interface)? Can you use drag'n drop?

Error tolerance
What happens in case of an error within the file (because it wasn't received correctly by your PC or it was saved at a bad sector of your disc)? Can the file be repaired, is all data lost or can at least some files be saved?

Security
Can you lock up the file with a password? How secure is this password? Can it easily be cracked?

| Back to Top |

ZIP

The most favorite compressor for Windows based systems is ZIP (although it's not the best one!). ZIP creates archives, meaning not every file is compressed on it's own, all files are summarized into one large file and this file is then compressed. Linux/Unix like systems often can read ZIPs as well (using "unzip" as shell command), but many of them can't create new ZIP files.

On Windows systems there is only one really good application for ZIP, being WinZIP. It has a very easy to use GUI, supports drag'n drop and it can also read most other common compression formats. While ZIP is fast, it's certainly not the best compressor that exists, neither is it very secure.

ZIP
Speed Very fast
Compression ratio Medium
Platform support Good
User friendliness Very good
Error tolerance Low
Security Low

| Back to Top |

Rar

Rar also creates archives, but other than ZIP it can create solid archive, meaning all files are first put into an archive before they get compressed (ZIP compresses every file and then add it to the archive), this options makes RAR files less error tolerant, but it improves the compression ratio.

Further RAR let you choose the size of the dictionary, the more the better is the compression result. The highlight of RAR is the "Multimedia Compression", that is able to reduce WAV, BMP or similar files by 40% while ZIP hardly can compress those files at all. When you enable multimedia compression, solid archives, use 1024 dictionary size and choose maximum compression, there is no compressor that is only nearly as good as RAR!

RAR also supports multiple volumes, parting a big archive into several small ones, what is very good for transferring them over a network as only broken parts must be resent instead of the whole file. The password protection is a lot better than the one of ZIP. If you want very error tolerant files (that can still be repaired when several blocks are broken), you should turn of solid archive and enable "Put error recovery record", this will increase file-size (it will still be smaller than ZIP), but therefor even multiple errors in a file can be repaired without data loss.

Unfortunately RAR is very slow and uses a very much CPU resources, but only for compressing, decompressing is as fast as ZIP. For windows you should use WinRAR, that has a similar GUI than WinZIP. There is a version for Linux as well, but not for any other OS. Nevertheless RAR is the winner of this test and my personal favorite.

RAR
Speed Slow
Compression ratio Very high
Platform support Poor
User friendliness Okay
Error tolerance High
Security High

| Back to Top |

TAR

Actually TAR doesn't belong here at all as it can't compress data. You will ask, what is it good for then? It creates archives. It reads several single files and saves the result in one big archive. TAR is often used in combination with compressors that are not able to create archives themselves. Those compressors would compress every single file on it's own and the result would still consist of several files, what is quite hard to transfer over a network. TAR is a command line utility and available for nearly every system.

TAR
Speed Fast
Compression ratio NONE
Platform support Very good
User friendliness Poor
Error tolerance NONE
Security NONE

| Back to Top |

GZIP (GZ)

GZIP is the standard compressor on Unix/Linux systems. It's just a command line tool where you can choice between 9 different compression levels. It can't create archives, it compresses every file on it's own. Usually you would first put all files into one big TAR archive and then compress this archive with GZIP. I don't know what else I should say about it as this program really has no features (except that it is available for every OS), just look at the table.

GZIP
Speed Slow
Compression ratio Poor
Platform support Very good
User friendliness Poor
Error tolerance Poor
Security NONE

| Back to Top |

BZIP2 (BZ2)

BZIP2 will become the new compressor of Unix/Linux. It's faster and compresses a lot better. It sill can't make own archives (you still need TAR for that), but therefor it is even better than ZIP. When just looking at the "bare" compression strength, it's the best compressor in the test. The only reason why RAR can win sometimes is RAR's Multimedia Compression (when you disable it, BZIP2 is creating smaller files!).

In a compression test with only HTML files (RAR's Multimedia Compression isn't useful as it doesn't improve the result when being used with HTML files) BZIP2 could easily beat RAR. In fact that's not because BZIP2 uses a new compression method, it just uses something revolutionary, a sorting algorithm. Instead of seeing data as stream, it looks at data in blocks, sorts those blocks with a very interesting sorting algorithm and *then* compresses it (now it compresses a lot better than without this sorting).

I think the best compressor would combine both, the dictionary/multimedia/solid-archive settings of RAR and the sorting algorithm of BZIP2, together they will beat every other compressor in this test easily.

BZIP2
Speed Medium
Compression ratio Very good
Platform support Very good
User friendliness Poor
Error tolerance Poor
Security NONE

| Back to Top |

ACE

ACE is still a nobody and nearly only supported on Windows. It's very similiar to RAR and achieves similar compression results. While sometimes RAR produces smaller results, ACE is usually a lot faster than RAR. For Windows WinACE has a WinZIP like GUI being very easy to use.

ACE doesn't let you change as many options as RAR and it's also not as good when it comes to security or error tolerance, but therefor it always produces good results. I don't know if it is ported to other OSes than Windows and DOS, but I wouldn't be surprised to see it for Linux. Just like RAR it can multiple volume archives, also helpful for saving huge data files on smaller backup media.

ACE
Speed Okay
Compression ratio Very good
Platform support Poor
User friendliness Very good
Error tolerance Okay
Security Okay

| Back to Top |

LZH, LHA, ARJ, ARC, UC2

LZH used to be Japan's whole proud, meanwhile it's only history. Some applications still use it (mainly Japanese ones), but you don't need a compressor, they will decompress data on their own when needed. In case you want to look inside the files, just use WinZIP.

LHA is similar to LZH and actually still in use. It can create very small self-extracting EXE files and once a while data that I download is still made with LHA.

ARJ is a command line tool with the abilities of RAR/ACE. Not only that it had better compression ratios than ZIP, it also supported multiple volumes archives and was very error tolerant, but other than RAR/ACE it was lightning fast. It's not in use anymore.

ARC (what also is still in use once a while) is a poor command line compressor, you could say another ZIP clone. Although it has been ported to Windows (and obstinately refuses to die out! ^_-), I say: Let it die in peace.

UC2 (Ultra Compressor 2) used to be a revolutionary command line compressor that first analyzes files before compressing them and it achieved good compression results that way. It also was very fast. I haven't seen it in use for an eternity.

| Back to Top |

Picture Formats

We are now taking a look at some of the more common picture formats that you can find on the Internet. Before we start, we first have to differ between 256 color and true-color pictures. After that I'll compare picture formats just like I compared compressor formats, only this time other aspects will be tested:

Losy
If the picture format can compress pictures using a losy method (creating the smallest file sizes possible)

Non-losy
If the picture format can can compress pictures using a loseless method (won't create that small file sizes, therefor pictures don't losy quality).

256 Color
If the picture format has a support for palette based pictures

True-color
If the picture format supports also true-color pictures

Losy Quality-Size Rating
What is the quality-size ratio of this picture, good means it saves a lot space without loosing too much quality, bad means that it loses a lot of quality while saving only very little space.

Non-losy Compression Ratio
How good is the compression of data when using a loseless compression method.

Application Support
Whether this format can be displayed by most applications (picture viewer, browsers, e-mail clients, news clients, etc.) or not.

| Back to Top |

256-Color VS True-Color

There are three basic methods to save graphical data and we will have a look at two of them. The third one is vector graphic, that doesn't save every individual pixel, but it saves objects like squares, circles, lines and so on, where they are placed, what's their color, how thick is their border, etc. It creates very small files and can be re-rendered on different display types (e.g. it doesn't lose quality when being resized, it'll never get "blocky" after zooming), but it can only be used for saving certain kind of pictures and thus it's very limited. Theoretically you could save every kind of pictures as it also knows an object named point (being a pixel), but if you save pictures that way, you lose the advantages of this format. The other two methods can store any kind of pictures.

One method is using a palette to do so. This palette has 256 entries and every entry describes a color, it's saved on top of a file. The picture data consists of pixels where every pixel has a number pointing to a palette entry, so your viewer software knows how to render this pixel. As 256 numbers can be saved in one byte, the picture will use one byte for every pixel inside the picture. This isn't a lot, so file sizes are quite acceptable. The disadvantage is that you don't have a lot of colors, only 256 what is a bit too little for certain kind of pictures (mainly photos). You can use dithering to virtually enhance the amount of colors, but this effect has it's limits.

Dithered pictures look to your eyes as they have more colors as they really do. That's because the pixels are sometimes placed very close together and sometimes with larger spaces, that way you get the impression that an array is darker while another one is brighter. On the other hand, for many drawn pictures, 256 are easily enough. Some drawing pictures already look great with only 16 colors (when only using 16 colors, one byte can save two pixels at once). Most pictures on TGOS.org are only saved with 256 colors or less for bandwidth reasons.

True-color pictures have no palette, every pixel needs 3 bytes for it's RGB values (Red Green Blue value). A value of 255, 255, 255 is white (meaning all three colors shall shine with maximum brightness) and 0, 0, 0 is black. You can mix nearly all in-between colors with only those three basic colors (in fact you can't mix all of them, but all that your monitor can display. Although many people don't know it, but PC monitors can't display all possible colors that exist, that's why a picture on such a monitor will never look like reality. Even normal photos can display more colors than a PC monitor, that's why a picture will never look as good as it looked before you scanned it)

True-color pictures are certainly bigger in size, therefor they offer you 16.7 million of colors, the question only is, how much of those do you really use? If less than 256, it may be a good idea to rather change the picture to a palette using format.

| Back to Top |

BMP

BMP is the standard picture format of Windows. It's usually uncompressed, but it can have a simple RLE compression. BMP files support any amount of color and can be read by nearly every application. The format is free and very simple to implement for programmers.

When you copy a picture to Window's clipboard, it'll usually be placed there as BMP, since all applications can import it that way. Pictures which are currently stored in RAM are also stored as BMP in Windows (pictures are usually stored uncompressed in RAM for fast access).

BMP
Losy Not supported
Non-losy Supported
256-color Supported
True-color Supported
Losy Quality-Size Rating N/A
Non-losy Compression Ratio Very poor
Application Support Good

| Back to Top |

GIF

GIF is a format owned by CompuServer (meanwhile owned by AOL, IIRC) that's quite popular on the Internet. You will often see it on WEB pages and on Newsgroups. It's very limited and not up-to-date anymore, therefore it still has certain advantages: It supports transparent areas (not all format support that) and it supports animation.

A GIF animation are several GIF images saved into a single file that will be shown in the viewer one after the other (with customizable delay times in-between them). It's the cheapest and easiest way to do an animation.

GIF only supports palette based pictures and uses a simple RLE/LZW compression for them. A losy compression method doesn't exist. Because of it's heavy license fees programmers have to pay for it (it's no free format) and because of it's limited functionality, it may get replaced by PNG for many things in the near future. I don't know what gives stand for, something like Graphics Interchange Format or so ^.^

GIF
Losy Not supported
Non-losy Supported
256-color Supported
True-color Not supported
Losy Quality-Size Rating N/A
Non-losy Compression Ratio Medium
Application Support Very good

| Back to Top |

PNG

PNG (Portable Network Graphic) is a license free format (isn't owned by a single company) that supports lot's of interesting features. It supports transparent areas, but other than GIF, it supports alpha transparency. In GIF a pixel is either transparent or it isn't, in PNG you can choose how many percent it is transparent (100% means invisible, 0% means not transparent at all).

Unfortunately it doesn't support animations. Therefor it also supports True-color pictures and has a lot better compression method. It's support by most applications, all the latest browsers and many E-mail/Usenet clients. It can't save pictures losy, but it's loseless compression is already very good, so you might use it as standard loseless format for your artwork. While it can't beat JPG for true-color pictures (or LWF), it can easily beat GIF for 256-color pictures, always 5 to 50% smaller!

PNG
Losy Not supported
Non-losy Supported
256-color Supported
True-color Supported
Losy Quality-Size Rating N/A
Non-losy Compression Ratio Very good
Application Support Good

| Back to Top |

JPG

JPG (or JPEG) is a picture format that also is company independent. It was created to save true-color pictures as small as possible, that's why it uses a losy compression method. It doesn't support animations, palette based pictures, a loseless compression method or transparency. Nevertheless it became on of the most distributed standards accross the Net.

If you choose a weak compression, you can shrink true-color pictures dramtically without any quality lose, but if you go too far, the pictures gets blocky or unclear, further it lose more and more of its color richness.

Just like GIF shall be replaced by PNG, JPG shall be replaced by JPEG2000, a similiar format that is desinged to achieve better compression results while keeping the quality of the picture. Right now it only exists on paper, but who knows...

JPG
Losy Supported
Non-losy Not supported
256-color Not supported
True-color Supported
Losy Quality-Size Rating Medium
Non-losy Compression Ratio N/A
Application Support Very good

| Back to Top |

LWF

A relatively new format is LWF (Lura Wave Format). Unfortunately it's owned by a single company (Lura-Tech) and so, being no official standard, it's support is very limited. Nevertheless I see more and more application offering support for it.

LWF is what JPEG2000 supposed to be (see JPG), it offers a lot better compression ratio and also supports loseless compression. Further it offers a special feature, you choose the size of the resulting picture and the LWF compressor will achieve it (at JPG, you only can choose a quality setting between 0 and 100), so you can use LWF if you must create pictures with exactly a certain size. The compressor will do its best to keep as much quality as possible. But you can also enter a percentage setting (similar to JPG) or a ratio (e.g. 10:1 compression) instead.

In general, LWF pictures look better than JPG when both have the same size, that's because LWF filters the data more efficiency and avoids creating "fragments" in pictures. Browser can display LWF thanks to a free-plugin from the LWF page, many other clients can't display it at all (although some freeware pictures viewers also support it via plug-in).

When saving data loseless, it's slightly better than PNG, but it only supports true-color pictures, 256-color pictures must first be converted and the result will be bigger than with PNG. If you must save lot's of true-color pictures onto a smaller HD you should think about using LWF.

LWF
Losy Supported
Non-losy Supported
256-color Not supported
True-color Supported
Losy Quality-Size Rating Good
Non-losy Compression Ratio Very Good
Application Support Poor
(only very little applications,
browsers only with plug-in)

| Back to Top |

Sound Formats

Unlike pictures, sound and music can hardly be compressed loseless. Most sound compression formats base on losy compression, but that's not a disadvantage. It's a lot easier to remove non-hearable data than to remove non-seeable data, I think that's because our ears aren't as complex as our eyes. For sound formats I will only check four properties:

Supports losy compression
If the sound format uses losy compression or if it is only uncompressed.

Quality to Size Ratio
How much does quality decrease when you increase compression.

Supported BIT Rates
How many BIT per second are supported by this format (the less BIT/s the smaller the files get, together with the Quality to Size Ration you get an impression how much quality suffers when decreasing the BIT/s rate)

Application support
How many applications support this format and on how many platforms you can find those applications.

| Back to Top |

WAV

WAV is the standard sound format of Windows. WAV itself is an uncompressed format that only saves plain audio data. WAV is for sound what BMP is for graphics. Unlike BMP, WAV supports CODEC filters (COding/DECoding).

CODEC filters must be installed into the Windows directory and into the Windows registry to work and they are some kind of plug-ins for ALL players of Windows. When a player opens a WAV file, it first determines whether this is an uncompressed file (so it can be played directly) or a compressed one. If it is a compressed one, the player will search for a suitable CODEC filter to decode the file. If one exists, it'll be used otherwise you get an error message or a box telling you were you might find a suitable CODEC.

CODECs can do both, encoding AND decoding, so your recording software can also use them for compressing data in a certain way. Windows already has some standard CODECs installed and the WEB is full of other CODECs. There are even MP3 CODECs, meaning you can put MP3 data into a WAV file and all Windows player will be able to play that.

The problem is, not all CODECs are free and there are not CODECs for every CPU or operation system! For that reason I will ignore the existing of CODECs in the comparison table below. The best Windows application to play WAV files is WinAMP.

WAV
Supports losy compression No (only via external CODEC)
Quality to Size Ratio N/A
Supported BIT Rates 88.2 KBit/s
(11025 Hz, 8 BIT, Mono)
to
1411.2 KBit/s
(44100 Hz, 16 BIT, Stereo)
Application Support Good
(but only when NO CODECS are used!)

| Back to Top |

RA

RA files are Real Audio files, a file format created for streaming audio data over the Internet. You can use it to listen to radio in real-time as it's broadcast over the Internet. RA files are small, they are the smallest files format that I know. Of course their quality is not overwhelming, but most of the time acceptable considering their small size.

RA uses a losy compression method to get rid of not hearable frequencies. A simple example of that would be: If you talk to another person, there shouldn't be any communication problems. When you do that same at an airport while airplanes fly over your head, you will have a problem ^_- The quiet frequencies of your voice will be "covered" by the loud frequencies of the airplane. Music is a mixtures of multiple frequencies and most of them will either be covered by another frequency that is louder or they will be covered by another frequency that is too close to this one. Your ears can hear more than one frequency at once, but to hear two frequencies, they must at least be a few Hz different, otherwise the louder of both will swallow the other one.

To play you'll need the RealPlayer, as only a hand full of other applications support this format, but non as good as the RealPlayer. Since the RealPlayer isn't existing for all applications and for all CPUs and OSes, RA is mainly used for Windows. Since they implemented a system named G2, the quality is a lot closer to MP3 than before (it still can't reach it though).

RA
Supports losy compression Yes
Quality to Size Ratio Medium (good for very low BIT rates)
Supported BIT Rates

96 KBit/s
(44100 Hz, 16 BIT, Stereo, radio quality)

There is no limit for lower BIT rates,
but below 32 KBit/s will mostly produce crap.
(unless you want to record speech only)

Application Support Bad

| Back to Top |

MP3

MP3 was actually developed as audio layer to the video format named MPEG (MP3 means MPEG Audio Layer 3), but because of its excellent compression properties it became the Internet standard format for music. It has a similar compression method than RA, but it's better at higher rates, therefor a lot worse at lower rates. It also removes unhearable frequencies (that's why it IS a losy compression format), what is left over is then converted to a certain format and saved using a loseless compression.

MP3 is platform independent, so it runs on every machine. The best player for it on Windows systems is WinAMP (by Nullsoft). The quality of MP3 files only depends on the encoder, the decoder will only convert them to WAV data and send it to the soundcard. Some encoders used to only encode frequencies below 16 kHz in the assumption that above it is nothing of interest for modern music, but this is plain wrong! Don't use such an encoder (e.g. older version of the Xing Encoder).

Maybe in a few years MP3 will be replaced by MPEG AAC (Advance Audio Coding), which promise to even produce better quality with lower BIT rates. It supports lots of different BIT rates, I'm just showing you some examples in the table below, not all BIT rates are included there. The best encoders are VBR encoders (Variable Bit Rate encoders) that alter the bit rate dynamically - they increase bit rate when necessary and they decrease it to save bandwidth whenever possible. Most encoders allow you to choose a relative quality factor: higher factors lead to better quality, but also increase file size. Unfortunately even if it switch to highest bandwidth possible, the encoder sometimes has to throw away some frequencies that you would be able to hear and that leads to annoying artifacts once a while.

MP3
Supports losy compression Yes
Quality to Size Ratio Very good
Supported BIT Rates

24 KBit/s
(11025 Hz, 16 BIT, Mono)

32 KBit/s
(11025 Hz, 16 BIT, Stereo)

56 KBit/s
(22050 Hz, 16 BIT, Stereo)

96 KBit/s
(44100 Hz, 16 BIT, Stereo, poor radio quality)

128 KBit/s
(44100 Hz, 16 BIT, Stereo, good radio quality)

160 KBit/s
(44100 Hz, 16 BIT, Stereo, *real* CD quality)

384 KBit/s
(44100 Hz, 16 BIT, Stereo, studio quality)

768 KBit/s
(44100 Hz, 16 BIT, Stereo, high studio quality)

Application Support Good

| Back to Top |

MP+

Many people think MP+ is an improved version of MP3, but that's completely wrong. MP3 and MP+ are both improvements of the MP2 standard (which itself is an improvement of the MP1 standard). Both took the already existing MP2 standard and improved the psychoacoustic model and the compression scheme. MP3 goes a different way here than MP+ (and the way of MP3 often cause undesirable artifacts after filtering), but both have the same aim: Reducing data size as much as possible, while retaining as much quality as possible.

And if you ask me which standard is better, there's only one answer you will get: MP+! There are MP3s where I can hear the difference between MP3 and original CD, even though I was using 320 KBit/s, while this was never the case when using MP+. MP+ always encodes files using VBR (Variable Bit Length) and unlike MP3, all frequencies that the human ear can hear are also stored to the MP+ file. In case of MP3 only as many frequencies as the current KBit/s rate allows are stored. There are also VBR MP3 encoders, but even when using best quality possible, VBR MP3 encoders sometimes have to drop important frequencies.

So when encoding MP3 files, you always have to "guess" what quality you have to use. In case of normal encoders you must choose a KBit/s rate and in case of VBR encoders the quality factor. The problem is: You never know for sure how much you really need and even if you may not hear the difference, other people may, because they might hear better than you or because they have better equipment (soundcard, amplifier, etc.).

In case of MP+ that's never a question, as it will always use the correct bit rate for the current file. You only choose between "standard" (good enough for 95% of all files), "extreme" (only pays off for 5% of the files) and "insane" (already beyond studio quality!) and the encoder will analyze the file and then choose the start bit rate accordingly, which will be altered throughout the file as necessary (e.g. if there a 5 seconds silence in the middle of the file, the bit rate will drop down to 3 KBit/s and might immediately raise to over 200 KBit/s again when necessary).

When encoding or playing the file, you will only see the average bit rate on your screen, but even if it looks pretty low to you, that doesn't mean anything. An average bit rate of 128 KBit/s could mean that the majority of the file is encoded with approximately 120 KBit/s and some peaks are encoded with 312 Kbit/s. In case your MP3 is encoded with 128 KBit/s, it's really only encoded with 128 KBit/s and those problematic peaks simply got lost.

Currently there only command line MP+ tools (encoder/decoder) for Windows and Linux/Unix. Those are Freeware and even though they are command line tools, they are pretty easy to use. The only player that can play MP+ directly is WinAMP, but you have to install a small plug-in first (download-able from WinAMP.com). If you use WinAMP, it's a MUST to install this plug-in.

MP3
Supports losy compression Yes
Quality to Size Ratio Perfect
Supported BIT Rates

MP+ only supports VBR encoding (Variable Bit Rate)
Bit rates can vary between 3 KBit/s
and 1.2 Mbit/s (=1,200 KBit/s !!!).

The encoder will always use as many KBit/s
as necessary to not lose any hear-able frequencies.

The average bit rates for normal music are
160 - 180 KBit/s (Pop/Rock/Techno) and a bit
higher for classical music or complicated sound effects.

With 160 KBit/s MP+ can already sound better
than MP3 with 192 KBit/s.

Standard audio format is "44100 Hz, 16 Bit, Stereo",
but it's possible to reduce frequency spectrum to
less than 44100 Hz.

Application Support Poor

| Back to Top |

 

Video Formats

Videos are nothing more than lot's of pictures with some sound being played parallel to showing the pictures. Neverthless you can compress videos better than just single pictures and sound, that's because very often there isn't a lot difference between the single pictures of a video, so instead of saving any individual picture, only the difference to the last picture is saved.

All videos are saved using losy compression. For video formats I looked a the following properties:

Quality to Size Ratio
How much decreases the video quality when increasing the compression.

Subjective Quality Impression
How good the average video of this kind looks and sounds when simply viewing it.

Application support
How many applications on how many platforms can play the format.

| Back to Top |

AVI

AVI (Audio Video Interleave) is another of Microsofts formats (just like BMP and WAV). It actually itself has no compression unless you use CODECs again. So it's uncompressed without any codecs and that make it unusable as only Windows supports CODECs for many compression methods.

BTW AVI is a mixture of audio and video data and both can use another CODEC, so the audio data needn't be compressed with the same CODEC as the video data.

AVI
Quality to Size Ratio Horrible
(as usually uncompressed without CODECs)
Subjective Quality Impression Poor
Application Support Okay
(if no CODECS are used, otherwise bad)

| Back to Top |

MPG

MPG (or MPEG) is a platform-, system independent format that isn't only used by computers, but also by video CD players. It uses MPEG Audio Layers for saving audio data (like MP3 described in the sound section of this document, but usually it's only MP2, what isn't as effective as MP3 and offers worse quality, therefor it's support by more players).

The video pictures are compressed with JPG (or JPEG, see the picture section of this document), but also making use of motion compression, were only the difference of two pictures is saved, not the pictures themselves.

MPG
Quality to Size Ratio Medium
Subjective Quality Impression Good
Application Support Very good

| Back to Top |

QT

QT (Quick Time) is the standard video format of Macintosh computer systems, nevertheless most other platforms can play it as well. It is similar to MPG, but rather optimized for lower BIT rates. It's a bit hard to get a encoder for it (harder than MPG, a lot harder than AVI) and I'm afraid it'll never play an important role on the Internet, but recently more and more pages make use of it.

QT
Quality to Size Ratio Medium
Subjective Quality Impression Good
Application Support Medium

| Back to Top |

RM

RM (Real Media) files are similar to RA (Real Audio) files, but they can contain animations and videos. Just like for RA you actually can only play it with the RealPlayer (despite a few other applications that support it more or less). It's great for real-time streaming videos, e.g. watching TV over the Internet.

When you only have very little bandwidth or space and you need the best available quality on very low BIT rates, there is no alternative to RM, as on very low BIT rates it still produces acceptable quality (all the other formats would only produce crap at those BIT rates). You can store a whole DVD movie easily onto a single CD, sometimes two movies and the quality is still as good as VHS video in full screen.

And yes, at rates of 450 KBit/s and below, it even beats the famouse DivX CODEC (aka MPEG 4) in sound and picture quality, DivX needs between 20-50% higher rates to produce results as good as RealMedia. Therefor RealProducer can't make files with better quality than 450 KBit/s, while DivX can and if VHS quality isn't enough for you and you want rather real DVD quality, DivX may be the right CODEC for you (but then the movie will take the whole CD, sometimes even more than one CD).

RM
Quality to Size Ratio Good
Subjective Quality Impression Good
(at low BIT rates the best
you can get, at higher ones, it's not
always that convincing )
Application Support Poor

| Back to Top |

Other Formats

Here I'll add some other formats that I might think are important. They are not rated with a rating system like before.

| Back to Top |

MID

MID (or MIDI) files are music files for keyboards, but most soundcards can play them as well. Instead of recorded music, they contain data sheets describing the instruments, where to place them in a stereo room, how their sound is modulated and what notes they shall play. Your soundcard uses this information to produce the music. Depending on your soundcard MIDI files can sound awesome, okay, bearable or only poor.

| Back to Top |

----------

If your browser doesn't support frames, click here to return to project index.

If you miss the navigation frame to your left, click here to get it back.

----------


Fatal error: Call to undefined function: get_sidebar() in /homepages/4/d100517071/htdocs/tgos/bot.inc on line 1