So I have been thinking and reading - there is a new start-up working on file specific compression algorithms - so AVI has a special algo, PDF special too, and maybe even txt, rtf, doc, docx, etc?

We could use a file compressor when we grab the file from disk and then transfer via standard protocols (FTP, HTTPS, HTTP, RSS, ya whatever) and then decompress on the other side but this way we use algos that are faster and do much more than the standard zip library option right - vendor says 40-80% whopping right!  But thats only a derivative of our answer #2 not too satisfying.  So what if we could bring those babys down into the OS?  At I/O we are getting a compressed file vs up in our software, so maybe an appliance concept where we transfer and move these files in really an unusable state by and end user but nice tight and small as we can get - bandwidth is better used, disk is more free, processor doesn't choke when it hydrates XML etc.  We have our little appliance right where the user will use the file in the desktop or browser.  We can even use it as a security option by making our compressor application or key aware - i.e. file only is decompress-able by the algo for the file type and with our application or user crypto key.  But we always fall into a trap any time we use some neat functionality to address a security issue which is better handled in a direct manner than a byproduct.

Instalasi ZLIB Compression Library

Langkah pertama, silahkan Anda download ZLIB Compression Library di sini. Kemudian ekstraklah ke sebuah folder, misalnya di C:\ZlibEx. Selanjutnya tambahkan folder C:\ZlibEx ke Library Path Delphi melalui menu Tools>Environment Options. Pada dialog yang muncul, klik tab Library, dan klik tombol elipsis di samping kanan combobox Library path. Dialog Directories akan muncul.

Klik tombol elipsis yang dilingkari, pilih folder C:\ZlibEx di mana Anda meletakkan ZLIB Compression Library hasil ekstraksi. Tombol Add akan menjadi aktif. Klik Tombol Add, kemudian klik OK. Kembali ke dialog Environment Options. Klik OK lagi.

Mengimplementasikan ZLIB dalam kode

Kita lanjut dengan pembuatan aplikasi kompresi file.

1.    Buat sebuah aplikasi baru. Simpanlah file-file aplikasi dalam satu folder.
2.    Pada form utama, tambahkan dua buah editbox, dua buah label dan 3 buah button. Tambahkan juga sebuah OpenDialog dan sebuah SaveDialog.
Sebagai perbandingan, berikut rancangan form saya.

3.    Pindah ke kode (F12). Untuk menggunakan ZLIB, Anda harus menambahkan unit ZlibEx.pas ke klausa uses.

[sourcecode language='delphi']
implementation
{$R *.dfm}

uses ZlibEX;
[/sourcecode]

4.    Kini kita masukkan kode untuk memilih file yang akan dikompres dan memasukkannya ke Edit1. Demikian juga dengan file target di mana hasil kompresi akan disimpan.

[sourcecode language='delphi']
procedure TFMain.BitBtn1Click(Sender: TObject);
begin
  if opendialog1.Execute then
    Edit1.Text:=opendialog1.FileName;
end;

procedure TFMain.BitBtn2Click(Sender: TObject);
begin
  if Savedialog1.Execute then
    Edit2.Text:=SaveDialog1.FileName;
end;
[/sourcecode]

5.    Terakhir, kita buat kode untuk mengompres file sumber dan menyimpan hasilnya ke file target.

[sourcecode language='delphi']
procedure TFMain.SpeedButton1Click(Sender: TObject);
var
  F1: TFileStream;
  sz1, sz2: Integer;
  p1, p2: Pointer;
  ratio: real;
begin
  //baca file sumber ke memori
  f1:=TFileStream.Create(edit1.Text, fmOpenRead);
  sz1:=f1.Size;
  Getmem(p1,sz1);
  f1.Seek(0, soFromBeginning);
  f1.Read(p1^, sz1);
  f1.Free;
  //mulai dengan kompresi
  p2:=nil;
  ZCompress(p1, sz1, p2, sz2, zcMax);
  Freemem(P1, sz1);
  //Simpan hasil kompresi ke File target
  F1:=TFileStream.Create(Edit2.Text, fmCreate);
  f1.Write(p2^, sz2);
  f1.Free;
  FreeMem(p2, sz2);
  //hitung perbandingan ukuran file
  ratio:= ((sz1 - sz2)/sz1) * 100;
  lblResult.Caption:=
        'Ukuran File Sumber:'#13+IntToStr(sz1)+'Bytes.'#13+
        'Ukuran File Target (hasil kompresi):'#13+IntToStr(sz2)+'Bytes.'#13+
        'Rasio Kompresi:'#13+FormatFloat('0.00', ratio)+'%.'#13#13+
        'Kompresi selesai.';
end;
[/sourcecode]

6.    Save projek Anda dan jalankan dengan menekan F9. Jika semuanya beres, tampilan aplikasi Anda akan seperti ini:

Dan berikut, snapshot ketika kompresi telah selesai.

Kode Selengkapnya

[sourcecode language='delphi']
unit umain;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ExtCtrls, StdCtrls, Buttons;

type
  TFMain = class(TForm)
    Shape1: TShape;
    Bevel1: TBevel;
    Label1: TLabel;
    Label2: TLabel;
    Image1: TImage;
    Label3: TLabel;
    Edit1: TEdit;
    Label4: TLabel;
    Edit2: TEdit;
    BitBtn1: TBitBtn;
    BitBtn2: TBitBtn;
    SpeedButton1: TSpeedButton;
    GroupBox1: TGroupBox;
    lblResult: TLabel;
    OpenDialog1: TOpenDialog;
    SaveDialog1: TSaveDialog;
    Label5: TLabel;
    Label6: TLabel;
    procedure BitBtn1Click(Sender: TObject);
    procedure BitBtn2Click(Sender: TObject);
    procedure Edit1Change(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure SpeedButton1Click(Sender: TObject);
    procedure Label6Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  FMain: TFMain;

implementation

{$R *.dfm}

uses ZlibEX, ShellAPI;

procedure TFMain.BitBtn1Click(Sender: TObject);
begin
  if opendialog1.Execute then
    Edit1.Text:=opendialog1.FileName;
end;

procedure TFMain.BitBtn2Click(Sender: TObject);
begin
  if Savedialog1.Execute then
    Edit2.Text:=SaveDialog1.FileName;
end;

procedure TFMain.Edit1Change(Sender: TObject);
begin
  SpeedButton1.Enabled:=FileExists(edit1.Text);
  if SpeedButton1.Enabled then
    Edit2.Text:=ChangeFileExt(edit1.Text, '.zlib')
  else
    Edit2.Text:='Pilih Target File Hasil kompresi...';
end;

procedure TFMain.FormCreate(Sender: TObject);
begin
  Edit1.Text:='Pilih File Yang Akan Dikompress...';
end;

procedure TFMain.SpeedButton1Click(Sender: TObject);
var
  F1: TFileStream;
  sz1, sz2: Integer;
  p1, p2: Pointer;
  ratio: real;
begin
  //baca file sumber ke memori
  f1:=TFileStream.Create(edit1.Text, fmOpenRead);
  sz1:=f1.Size;
  Getmem(p1,sz1);
  f1.Seek(0, soFromBeginning);
  f1.Read(p1^, sz1);
  f1.Free;
  //mulai dengan kompresi
  p2:=nil;
  ZCompress(p1, sz1, p2, sz2, zcMax);
  Freemem(P1, sz1);
  //Simpan hasil kompresi ke File target
  F1:=TFileStream.Create(Edit2.Text, fmCreate);
  f1.Write(p2^, sz2);
  f1.Free;
  FreeMem(p2, sz2);
  //hitung perbandingan ukuran file
  ratio:= ((sz1 - sz2)/sz1) * 100;
  lblResult.Caption:=
        'Ukuran File Sumber:'#13+IntToStr(sz1)+'Bytes.'#13+
        'Ukuran File Target (hasil kompresi):'#13+IntToStr(sz2)+'Bytes.'#13+
        'Rasio Kompresi:'#13+FormatFloat('0.00', ratio)+'%.'#13#13+
        'Kompresi selesai.';
end;

procedure TFMain.Label6Click(Sender: TObject);
begin
  ShellExecute(handle, 'open', PChar(TLabel(Sender).caption),nil, nil, SW_SHOW)
end;

end.
[/sourcecode]

Download

Download contoh aplikasi 332KB [ sudah menyertakan ZLIB Compression Library]

Dan seperti biasa, Anda harus mengubah ekstensi file hasil download dari .PPT ke .ZIP. Pastikan Anda terhindar dari ancaman virus, trojan dan sebagainya. Silahkan pindai dulu file-file hasil download dengan antivirus sebelum dijalankan.

To me, the book is special mainly because it does not recycle the old familiar - and let's admit it: boring - stuff that you can find in thousands of other books about XML, but it focuses on more advanced topics, some of which were not covered in this way before, or at least not in such depth. Among other things, the book deals with such topics as advanced XML schemas, XQuery, XML in databases, XML modeling, or - XML compression, which, by the way, is the section I wrote.

The accompanying web page with downloadable examples from the book can be found here: http://kocour.ms.mff.cuni.cz/~necasky/bk/technologiexml/.

The book is already in the shops, so don't hesitate and get your copy before it is sold out :) You can also order it directly from the publisher: http://www.grada.cz/katalog/kniha/xml-technologie/.

The - inevitable - official review that comes with the book (in Czech) follows:

"Kniha je - a možná nejen v českém prostředí - unikátním počinem představujícím v kompaktní formě prakticky všechny podstatné standardy a technologie související s XML, včetně těch nejnovějších. Autorům se na relativně malém prostoru podařilo představit takřka vše, s čím se potká student, vývojář i výzkumník. Světová literatura nabízí k dílčím tématům dostatek zdrojů, zde se však českému či slovenskému čtenáři předkládá vše na jednom místě a výklad jde přímo k jádru věci.

V mnoha ohledech se museli autoři pohybovat mezi Scyllou a Charybdou stylistických protikladů - psát pragmaticky pro vývojáře jdoucí mnohdy po povrchu technologií a využívající zbytečně malou podmnožinu možností, nebo být akademicky vyčerpávající - v dobrém i špatném smyslu? Myslím, že není chybou, když přesnější, akademičtější styl výkladu jdoucí do hloubky a neopomíjející zajímavé detaily dostal přednost. Dnešní internet je plný kusých informací, rad, tipů a dílčích výkladů ke studovaným technologiím, v předkládané knize máme však záruku kvality, přesnosti a do značné míry i úplnosti.

Přeji čtenářům ať jim je kniha užitečná nejen při každodenní vývojářské práci, ale třeba i jako brána k obecnějšímu zamyšlení nad souvislostmi moderních informačních technologií. Pro mě studnicí takového poučení je.

Tomáš Pitner

(recenzent se XML technologiemi zabývá od jejich zrodu a od roku 2002 je vyučuje na Masarykově univerzitě)"

I've written this tutorial for anyone who uses adobe premiere pro and wants to find out the best way to compress a video using "Windows Media Video".

I cover things like what bitrate to use with what resolution and frame rate aswell as what a few of the different settings do and mean. Find out for yourself and take a read...

(not you will need to copy and paste image url's in to your browser)

Getting to Adobe Media Encoder

1. Render all unrendered footage if you haven’t done so already in premiere pro

2. Now go, File >> Export >> Adobe Media Encoder

3. Select “Windows Media” from the format drop down list

4. Then, from the preset drop down list, select something like “WMV9 720 25p” (doesn’t really matter what you choose)

Video Settings

1. Select “Video” on the left hand side of the Adobe Media Encoder

2. Under Video, make sure…

Select “Windows Media Video 9” as the codec
Leave “Allow Interlaced Processing” Unticked
Under Bitrate Settings, Select “Two” encoding passes and make sure the mode is “Variable Constrained”. This offers way better results compared to a single encoding pass

Image: fullvoltage.com.au/index.php?action=dlattach;topic=333.0;id=29;image

Audio Settings

1. Select “Audio” on the left hand side of the Adobe Media Encoder

2. Under Audio, make sure…

Select “Windows Media Audio 9.1” as the audio codecUnder Bitrate Settings, Select “Two” encoding passes and make sure the mode is “Constant”. This will make sure the audio quality stays the same the whole way through the video

Image: fullvoltage.com.au/index.php?action=dlattach;topic=333.0;id=30;image

Audience Settings

1. Select “Audiences” on the left hand side of the Adobe Media Encoder

2. Audiences is the most important part as this is where you actually set the quality and the file size

3. Now, select your desired frame rate, it’s usually best to keep it at its original level. But, say you’re original level is 50 frames a second, reduce it to 25. If you’re going for a really small file, then you’d want to bring your fps down to 20 or 15, but 25 will always enhance the footage as it will appear a lot smoother.

4. For Pixel Aspect Ratio, set it to however you’re original footage is set. If you’re editing footage shot on the computer, then square pixels will give you the best results.

5. Frame Width and Frame Height is a big factor for when considering image quality with file size. You kind of need to match them both up. In theory, for simple scenes like a close up of a human face “1 bit” per 200 pixels will offer good results,you may even want to try 250 pixels per bit. But with a more complex scene which includes maybe scenery and shrubs or a fast action video.etc, you’d want to aim around “1 bit” per 100 pixels (no where over 140 pixels per bit). To work this out, simply look at all the scenes in your video. If your scenes vary a lot in terms of colour and complexity, then you want lesser pixels per bit, this will increase file size (or reduce image size) but will offer way better results otherwise. On the other hand, if you’re video contains long interviews with a still background. Then the compressor will be able to produce good results with a high pixel per bit rate.

6. Now, moving down to the basic audio settings, if you’re video contains a lot of sound and the sound is really important in the video. Then you wont want to go under 96kb/s, but I usually prefer to use 160kb/s or 128kb/s as if you compare the 160kb/s bitrate of the audio to the say 5000 bitrate of the video, you can see that the audio isn’t going to effect file size much in this case. The higher your video bitrate, the lesser the impact the audio will have on the filesize. Use CBR audio, not (A/V) CBR audio. Use stereo if your sound differs from channel to channel (most music does).

7. Back to the Video now, Set Decoder Complexity to Auto

8. For key frame interval, if you have a high action video with complex scenes, set this to about 1 or 2. On the other hand, if you have not so complex scenes like an interview with a still background, then you can raise this up to about 10.

9. Leave buffer size as default

10. Now, here is the good bit. Because earlier on, we set a Video Encoding mode to a Two pass encode with a variable but constrained bitrate. This means we can now give a maximum and average bitrate. It will use the maximum bitrate in the more complex scenes and will use the average bitrate for normal scenes. Now, setting your bitrate is important. This is basically, where we shove all our resolution and other data, in to a tightly packaged file. If you package your file to tight, bits of data start oozing out the corners which is why it’s important to package your video tight, but not too tight. Let’s say we have a rather complex video which is fairly fast paced with lots of different colours and scenes. We set our resolution to 1024x768 with a frame rate of 25 and we want excellent quality, but a small file size.

Ok, let’s put what we learnt in to play. Ok, 1024 multiplied by 768 gives us 786000 pixels. That means that every single frame will contain 786000 pixels. If our video is running at 25fps, that’s 19.2 million pixels a second. The way compressors work, is they look for similarities across multiple frames and they try and share the data. Sometimes, when you set the bitrate too low, it just can’t deal with that data so it needs to throw away some pixels. The lower the bitrate, the more pixels get thrown around or ripped up.

11. Now, we need to set the bitrate. So, seeing our scene is fairly complex, and we want good quality, I think 130 pixels per bit will be fine. So, lets divide 786000 by 130. This gives us 6040 bits. So, 6000 bits a second is what we need. We’ll set 6000 as the peak and 5000 as the average. Now, 5000 bits a second will produce a fairly large file in terms of the internet, but remember, we are using a resolution of 1024x768 which is very big in terms of the net, but we want viewers to see “all” the work we have put in to it.

12. Now, once the bitrate is set, we have our buffer size, the larger your bit rate, the larger you want your buffer size. In this case, a buffer of 20/25 will be fine (buffer usually doesn’t effect anything).

Image: fullvoltage.com.au/index.php?action=dlattach;topic=333.0;id=31;image

Saving

1. Now, save the preset buy hitting the floppy disk icon up the top of the Adobe Encoder Window. But, before you do that, place a comment for the preset if you want.

2. Now, hit ok at the bottom of the window which will then prompt you for a location to save it. It will also give an estimated file size based on your video length and you’re peak data rate (for both the video and audio). But seeing we are using a variable bit rate, this estimate is usually higher than the end result.

3. Let it render out, then enjoy.

Tips

It’s usually good to set your work area to a length of 5 seconds over a complex part of your video, that way, you can do test renders to find the best bit rate
If you get errors while exporting and you use a hyperthreading processor or a dual core processor, visit this site to fix the problem. If you don’t get this problem, it may still be a good idea to visit the site and get the new adobe media encoder. http://www.adobe.com/support/techdocs/330380.html

I hope you learnt something from this tutorial Smiley

Cheers! http://www.fullvoltage.com.au

Article Source: http://EzineArticles.com/?expert=Tom_Wardrop http://EzineArticles.com/?Windows-Media-Video-Compression-Using-Adobe-Premiere-Pro&id=169377

I thought I try out LFE a bit more, implementing huffman coding. It is a algorithm used to compress data. It's simple and beautiful. I think it shows the power of algorithms. The power of doing the right thing in the right order.

Thoughts:

• I used my debug macro all the time. Insanely useful!
• I never used my cl-like trace macro. I'm surprised. It looked like a nice tool.
• I like to write test first, passing working code up and finished test down. It's like the file grows in the middle. It works great.
• Worked with tuples as data structure for my huffman trees. It's working. Not sure if it's the best type to use. 

Demo

Is it working? Yepp. Here is the script.

$ erl
Erlang (BEAM) emulator version 5.6.3 [source] [smp:2] [async-threads:0] [kernel-poll:false]

Eshell V5.6.3  (abort with ^G)
1> demo:compressfile("big").  
{ok,46.81262785425997}
2> halt().
$ ls -al big*
-rw-r--r--  1 default  staff  18087  3 Okt 08:50 big
-rw-r--r--  1 default  staff   9979  3 Okt 10:18 big.huffed

Half the size. Yes!

Code

And here is the result. demo.lfe

Huffman-tree is the main function. This function creates a tree placing frequently used characters near the root. Characters used a lot get a short bit sequence. A short bit sequence save space. 

;; Create huffman tree from frequency list
;; 1. sort
;; 2. create tree using two first elements in list
;; 3. goto 1
;; (#(a 2) #(b 4)) => {a,b}
(defun huffman-tree (unsorted)
  (let ((len (length unsorted)))
    (if (== 1 len)
      ;; Unusual case, make huff tree of one char.
      (case (car unsorted) ((tuple ch freq) (tuple ch)))
      (let* ((sorted (sort (fun sort-on-count 2) unsorted))
             ((tuple tree1 freq1) (car sorted))        ; first
             ((tuple tree2 freq2) (car (cdr sorted)))) ; second
        (if (== 2 len)
          (tuple tree1 tree2)		; Exit
          ;; create new tree of first and second element
          ;; add frequency then call self again.
          ;; but with two elements smaller list.
          (huffman-tree
           (cons (tuple (tuple tree1 tree2) (+ freq1 freq2))
                 (cdr (cdr sorted)))))))))

Huffman codning

Nobody Move! Nobody Move! (or » tu es calme! « as Mr. White would say)

Lately we get bored of all the distortion and overdrive. I mean - mmh...do you know somebody with as much overdrive attitude here?

Us neither.

So we decided to check out the fx case of our favorite guitarist and what do we found?

An original Colorsound Tonebender! Awesome!

Now you know why we build the ITC Loup Garou for him. But that's not the story of what we found - it's about what we did not found. He has pretty everything, also an huge plastic insertion tool. A plug, so to say... But there was no compressor at all.

The next days we spend at local dealers and checked some of the standard stomp box-compressors, also bass compressors. We weren’t that much impressed...blablabla...if you already into the comp chapter, you know what's the problem of nearly 90% of the not-19'-compressors. Back home we did some net research and we found some interesting articles about the Dan Armstrong Orange Squeeze.

» Looks like THE THING, guys...remember Soho, the fantastic four? « Mr. Foster pointed out. Long story short: We called up Mark in Berlin (a great source for old stomp boxes! Thx again, pal) to send us the OS over to cologne, made some benchmarking and blablabla and drum roll and...

Check out the ITC ORANGE THING That's what we call Instant Vintage Compression. That's an compressor you will hear breath and pump. Like the original, it adds a nice smooth and warm attitude to your sound with a little bit vintage tubish sound.

The ITC ORANGE THING is a killer together with an valve amp. It's not just a booster, it's compression! What? Yes - that's a difference! It really kicks the right sound and you will be impressed how cool your own little practise amp could sound.

By the way - it's equipped with an selected 4558 chip, like these nice and most wanted green overdrives out there.

We changed some of the layout for more bass response, true bypass as usual and put the adjustments from the inside trim pots to the top, so that you can adjust your amount of squeezing, just as you like it. But we conserved this special sound and sweetness only a squeezer can produce.

With the additional filter mod’s it's also very good for bass recordings, especially for fretless basses.

• handcrafted in Germany

• equipped with matched transistors

• true bypass as usual

• standard housing by Hammond

• Alpha pots

• Switchcraft jacks

• powered by battery or dc

• high- quality switches

• equipped with an selected 4558 chip

Tease - Set your volume (boost) level

Squeeze - Adjust the compression. [Note: Set it once, and then forget it until you'll change basses/guitars]

Filter 1/2 - Two tiny switches, great enhancement! (Only ITC ORANGE THING IVC)

NOTE: The ITC ORANGE THING and ORANGE THING IVC are discontinued since summer 2008 and replaced by:

THE ITC PUNISHER series:

There are three versions coming up: 1. true vintage compression 2. fuzzed up and compressed 3. optical compression

Independent Tone Control is a collaboration of two cologne session musicians from the independent music scene together with an electronics specialist and with the intention to get the unique sounds and stomp boxes of the sixties and seventies back on track. Long time unaccounted sounds combined with handcrafted quality and a true bypass switch - made for daily studio work and rough live situations and way ahead back to the time when a good sound was analog and Zappa was still alive.

No further reproduction, usage and copying of the text without permission of the author. Commercial use is strictly prohibited!

It just goes to show what not all video sharing sites are the same.

And while YouTube is by far the most popular, you can see in his post that Chow realized higher quality compression of his video sample at Vimeo.

I've noticed the same drop in compression of my videos. I prefer keeping most of mine on YouTube, not only because of its popularity but because its videos are easily embeddable in a variety of blog platforms and Web sites.

I like Vimeo, but I also have been using Viddler a lot more recently because they allow you to embed a logo in the bottom right corner of their player.

Because after all, it's your video right? It's not YouTube's.

Dr. Narendra Singh - 2008 Interview from Minosa Films on Vimeo.

I edited the film using CyberLink BD Solution PowerDirector Express. The text images were made in Inkscape.

The opening title is too long, I could add music to the intro/end text, and the file size is larger than optimal, but unless it causes problems or I feel highly necessary, I may leave this video as the final version.

I would re-encode it with a greater compression, but may have to do that later (hardware complication.)

Thanks!

-b

P.S. If the video loads too slowly, try turning off HD (hover over the Vimeo video) or let me know via a comment or e-mail!  If it is too difficult for people to view I will endeavor to re-encode it (with some tweaks on the video as well, while I'm at it,) for you.

P.P.S. Sorry, Wordpress can't embed Vimeo videos. :( Oh well... :D
EDIT: fixed it! Check out what dalas verdugo has to say here: http://www.vimeo.com/forums/topic:1221

Meanwhile on Wikipedia: Charlieplexing, Monte Cazzaza, RE/Search

Good car maintenance is always advised. Keeping your car in tip top shape can do wonders to your mileage.  For example, low tire pressure can eventually lead to higher fuel costs. That is why tire pressure should regularly be inspected. Under-inflated tires require more energy to begin its movement and to uphold its speed and rotation. In addition, having an oil change every now and then can certainly help the engine perform at peak levels and improve gas mileage.

A study conducted by a British automotive consultancy revealed that controlled acceleration is actually better and more fuel efficient than normal conservative driving. According to the study, the key for saving that much fuel is to accelerate hard until the engine reaches 2000 rpm, move up a gear, then push on the pedals until the same rate is reached. In fact, an engine running at 2000 rpm is at its most efficient. So turning it up won’t be a bad idea after all.

Finally, practicality and common sense should always come into mind. When buying an automobile, considerer the car’s engine specifications. Automobiles that run on 2.0L and 1.6L 4-cylinder engines are ideal for gas savings. These vehicles can also be considered as “gas saving cars.” They have relatively high compression ratios for a powerful, yet effective engine performance. By performing all these simple and practical ways and tips to save gas, having better fuel economy can be achieved.

Elsewhere, this blog from Wired founder Kevin Kelly is also a good read. He talks about how the long tail operates for creative types - all you need to make a living from your music/films/books/whatever is 1,000 of what he calls 'true fans', defined thus:

'A True Fan is defined as someone who will purchase anything and everything you produce. They will drive 200 miles to see you sing. They will buy the super deluxe re-issued hi-res box set of your stuff even though they have the low-res version. They have a Google Alert set for your name. They bookmark the eBay page where your out-of-print editions show up. They come to your openings. They have you sign their copies. They buy the t-shirt, and the mug, and the hat. They can't wait till you issue your next work. They are true fans.'

An interesting thought that one could become a self-sufficient micro-celebrity with just 1,000 die-hards behind you, famous enough to sell out a major music venue (just one, if they all came), but anonymous enough to walk down the street unnoticed. It's an achievable aim, and one that means you don't need to try for Scouting For Girls-style vacuous lowest common denominator drivel to make a living for yourself. Of course, he doesn't mention whether it's subsistence or mansion living - I would suspect the former - and it depends on the value per item of your output (sculptures vs. sticker packs), and how prolific your output is. But still.

Hey, we have over 700 listeners on last.fm. It might still happen.

In this particular instance, I have to thank American Music Club for repeatedly putting out CDs of demo versions of songs once an album has been released - with Demos Before Love Songs, and now with The Mercury Band Sessions and Everclear Band Rehearsals 1990. I love the idea that a song is never, ever finished, and that the album version just captures the way the song was on that particular run-through on that particular day, rather than requiring 100 takes to nail the exact and only appropriate version. It depends on how the band were feeling, what was on the singer's mind, where they were, maybe even what the weather outside was like. Where's the boundary between not having finished a song and still being in the process of writing it, and pretty much having it complete, but leaving yourself enough room to play with it within fairly broad confines? Truth is, maybe there isn't one, and shouldn't be one.

Take these two versions of 'Miracle on 8th Street' by AMC by way of example - one a pre-album band rehearsal, the other the final studio version with all the tweaks and studio effects. The lyrics go through a few changes, and what I previously thought was the absolute heart of the song (the closing repetition of 'I loved you more than that'), perhaps even what it was built around, looks like it was a last-minute addition, and it makes the song for me. But then I also love the bear-shouting-in-the-woods emoting in the demo that's just wiped from the final version. But most noticeable is the decision to change the whole phrasing and tone of the song changes from something passionate and furious (and yeah, a bit emo) to despondent and bleak.

American Music Club - Miracle on 8th Street (demo version)

American Music Club - Miracle on 8th Street (album version)

On a related but not exactly similar note, Metallica have reopened the years-old debate about compression on albums to make them sound louder on crap stereos, reducing the dynamic range so they sound horrible on anything that's not a pair of crappy headphones. Having seen them at work - as everyone else has - in SKOM, you just know that every last drum hit and note was trimmed down to perfection in ProTools, nothing left to chance (except the lyrics, which I assume were once again done by random word association or written by Myles Ulrich), and then mastered so it would be LOUDER THAN ANY OTHER ROCK RELEASE OF 2008. Quality of the songs aside, given the fluidity of musicianship and songwriting in these two processes, which do you reckon is the best for showing off the freedom of artistic expression? Yeah, me too.

Next time out: direct parallels between Red House Painters and Anthrax.

Why have engineers been doing this? Partly because people perceive louder things to sound better. Also, because a vicious cycle has been developing... one engineer pushes their group's levels up, so another engineer goes one level up, then another engineer goes even higher and so on. The result is that every new CD that comes out has its dynamic range further squashed. It's gotten ridiculous. Check out this example of The Beatles' song Something over the last 25 years:

Thanks to Wikipedia for this image. It's a great illustration of this trend toward higher volume levels and lower dynamic ranges. Check out the "Loudness war" Wikipedia entry to find out more about the history of this issue.

I hope this blog can serve as a warning to audio content providers for games. With games, volume is even more of an issue. With sound effects, voice, and music all needing the player's attention it's tempting to just squash the music's dynamic range so it's more easily controllable. But with proper planning and attention to context, that shouldn't be necessary. Orchestrate the music correctly. For mellow scenes or levels, go quiet. For action-packed scenes and levels, write loud. This is common sense of course. And we're talking about averages. It's ok if the music isn't always completely audible. The player can deal with that. If they miss a particular section of the music during a loud explosion or gunfire, they'll hear it again next time the music loops. It's ok. A large portion of today music engineers may think that is heresy, but they have forgotten one simple idea:

When everything is loud, nothing is loud.

I'm not sure who originally said this, but it's absolutely true. What makes music interesting is, at a very basic level, contrast. Loud vs. soft, high vs. low, quick vs. slow, simple vs. complicated. Abusing compression effectively kills the possibility for contrast between loud and soft. And, frankly, it starts to tire the ears. And things end up sounding not quite right, especially in orchestral music. A solo bassoon should not sound as loud as an entire orchestra. The listener should have to listen a little more attentively. They're not going necessarily to hear the bassoon's keyclicks or the player's breaths. Unfortunately, with compression they might hear that sort of thing.

So, let's not fall into the trap that the recording industry has fallen into. With them, they want it all to be super loud on the radio and over the internet. They have succumbed to the "louder is better" philosophy of music, using loudness as the main criterion for goodness. Louder is, in reality, just... louder. And probably worse... unnatural and tiring. Don't be afraid to let your music breathe and flow as you compose it. And then don't squash all the life out of it when you mix and master it. Trust that, if you have done your job correctly as a composer and a sound designer, the music will work just fine in your game.

So how do you choose the proper compressor?  There is no single best algorithm, many have different strengths and weaknesses and are useful in different situations.  We'll investigate a few different compression algorithms and more importantly evaluate what to look for when deciding on how to compress your data.

I've done some simple benchmarking using a couple of freely available libraries: zlib (which I demonstrated in my load time article), 7-zip (A.K.A LZMA), LZO and BCL.  I chose these due to their variety, free availability and ease of use. BCL has a number of compression algorithms, I've only shown results from Huffman encoding, since Huffman compression is such a textbook compression algorithm it's worth comparing against.

To start let's look at the compression ratios of our algorithm using two sample test files - a large text file and a large RLE-encoded targa image file.  The graphs show compression percentage vs block size, with the largest block size begin the entire file.  The reason I'm looking at block sizes is to reduce the memory overhead required to decompress a file, since we can then decompress data in nice fixed-sized blocks reducing high watermarks. A lower value represents better compression.

Not surprisingly text compresses pretty well, even the basic Huffman algorithm doing quite well.  LZMA does very well, at 1/3 the original size.  We can see that the larger the block size is the better the compression ratio is.  Most algorithms tend to flatten at larger block sizes, however LZMA does seem to not flatten nearly as much as the others and clearly has the best compression ratio.

This TGA file already uses a primitive run-length-encoded compression scheme, so unlike the raw text file some redundant data has already been removed.  The trend of better compression with larger block sizes continues.  However we can see that Huffman doesn't do very well with binary data, and even does worse as the block size increases.  Also, the compression ration of the TGA is not as good as the text file, but LZMA still reduces it by over 50% at larger block sizes.  So we can see that the compression algorithm has a large impact on the compression ratio. With LZMA achieving the best compression in all cases.

As important as the compression ratio is - since smaller files directly lead to less time reading files - it's not the only factor we should examine when selecting a compression algorithm.  How long it takes to decompress data is also very important.  If it takes longer to decompress a file than the time it takes to read it uncompressed, we haven't gained anything.  So lets look at the how long it took to decompress.

We can see that LZMA is much slower than the other algorithms, over 5 times insome cases.  We can also see a clear trend where LZMA clearly has a high per-block cost, with Zlib and LZO being fairly constant.  So we can now see that the increased compression of LZMA comes at a cost in decompression time.

The time to decompress is interesting, what we really want to know is how much faster will a given compression format make our data reads.  To figure out this, we need to look at the total time it takes to read and decompress the compressed data.  This is a better comparison since it shows the advantage of using slower, high-compression algorithms because they read less data.

The next chart compares our compressed data versus a 10MB/s read device.  We compute

(time to read compressed data + time to decompress data)
         / (time to read uncompressed data)

Which give us the next chart

Now we can actually see what load time improvement we'd get with different compression algorithms.  Any algorithm with a ratio greater than 1.0 will be slower than uncompressed data.  So we can now see that LZMA, which compresses data really well, would slow down our load times for a single file.  ZLib we can see is over twice as fast as an uncompressed read.

The previous test really only shows single threaded, single file load time improvements.  If our game is heavily threaded, on a platform with enough processors, we may be able to mostly ignore decompression time by simply using enough multiprocessing.  In this case we may simply want the algorithm with the best compression ratio.

However some platforms, like the PS3, have somewhat limited processors.  While SPUs are fast processors, they have only 256kB of memory.  This means for the PS3, if you want to decompress data on the SPU you'll need to use smaller blocks so they fit in RAM.  Or customize your decompressor to understand the memory limitations of the SPU and stream data properly.

This also brings up the question of how much memory do you need to decompress data?  Some algorithms can require very large look up tables or other working memory which can make them unsuitable or impractical for console games.

You can't simply choose a compression algorithm based on the load time savings.  The algorithm needs to fit within the confines of a console game.  So when considering how to compress your data, take these key points into consideration:

• Total load time reduction provided by the algorithm.  As discussed above, this is the total reduction of load time by reducing data read and time taken by decompression.  Of course depending on platform and CPU resources you many not care about decompression time unless it is extremely slow.
• How much memory is used by decompression.  Some algorithms need substantial working memory, some need almost none.  You need to take this into account, especially if the working memory is too large for your target platform (e.g. PS3's SPU)
• Can you decompress in-place? Does the algorithm work in fixed sized blocks?  Can it decompress a stream of data efficiently?  These are important questions to ask.  LZO for example can be decompressed in place - meaning you can decompress data into the same buffer as the compressed data, without needing temporary memory, which is really nice for low-memory conditions and memory fragmentation.  The trade off is LZO doesn't have a great compression ratio.
• How long does it take to compress the data?  Generally not a large problem, but some algorithms, especially ones not well optimized can be very slow.  This is a concern when you try to compress gigabytes of data.
• Last but certainly not least, what license does the software use?  This is a question you must ask of any external source or library, you need to make sure the distribution license works for you.  You can't rely on a GPL library for a professional console game, but if you're making a freeware game, releasing the source may not be an issue.

I'm not endorsing any of the particular algorithms or libraries we looked at, they were chosen because their contrasts made for good talking points.  Also, often console platforms will provide their own compression API too, which are usually worth evaluating, since they are optimized for the target platform and can be quite fast.

I hope this article give you some insight into compression of game data, and while we haven't chosen a best algorithm, we now know how to compare various compressors and know how to make informed decisions.

The other day I was handed a bunch of ASF files.  Knowing I would have to convert these to quicktimes for editing in FCP, I went on a long painful journey to find out how to convert them.  Of course the first thing I tried was playing them in Quicktime.  Audio played but the video was very scrambled.

I then tried our tried and true MPEG Streamclip knowing that almost everything plays in MPEG Streamclip but I got the same results as with Quicktime.  What to do. VLC played the files but not in sync and I'm still not certain how to convert/stream out of VLC.  What is an ASF file anyway?  According to Wikipedia ASF stands for Advanced Systems Format and it's a Microsoft proprietary digital media container specifically meant for streaming media.  Okay...so I thought I could probably plays these files on a PC so I fired up my copy of  Windows using VMWare Fusion on my MacBook Pro.  The files played fine of course and I looked for free software downloads that would help me to convert these files to any format I could play.  Well of course I didn't have enough room on my Windows partition to convert any files so I decided to dig around the forums a little more and that's when I came upon a posting on the Apple forums recommending VisualHub.  I already had a copy of VisualHub but never purchased it so I'm restricted to converting the first 30 seconds of any clip.  So I load in an ASF file and set it to convert to a DV for for use in Final Cut Pro and voila!  Now why VisualHub can  play these files and not quicktime I don't understand.  I had always thought of VisualHub as more of a consumer software program great for converting you files to formats to play on your iPod, iPhone or PSP or something.  Well now I new found respect for this little app and will make it a part of my arsenal for tackling tricky file conversions.  You should too!  It's only $23.32 to enable full functionality and if you have to use it once I think it's worth it.

Apresentação da empresa:Fusão, uma história dedicada à vida.

A FUSÃO surgiu com intuito principal de colaborar na melhoria da qualidade de vida do ser humano, utilizando-se de pesquisas e buscando no mercado interno e externo, e nos diversos centros de pesquisa, o que de melhor possa assegurar no atendimento das necessidades médico-cirúrgicas.

Missão:
Oferecer aos nossos pacientes alta qualidade em materiais médicos-hospitalares , investindo em desenvolvimento e tecnologia, otimizando custos e trazendo lucratividade para os acionistas e parceiros de negócio, com ética e responsabilidade social.

Visão:
Ser líder de mercado no segmento de implantes de coluna e crânio, fixando a marca Fusão na memória de nossos clientes, com o intuito de disponibilizar soluções inovadoras para os cirurgiões, tendo como objetivo maior gerar o bem-estar final ao paciente.

Valores:
Tudo é fruto da colaboração e junção de idéias, propósitos e vontade. É assim que o trabalho da Fusão se desenvolve, com comprometimento no atendimento ao cliente, integridade, iniciativa e responsabilidade.

Destaque para o produto: Cifoplastia com Balão

A Cifoplastia com Balão é um tratamento minimamente invasivo para tratamento de  fraturas vertebrais por compressão.

Balões ortopédicos sãousados para restaurar osfragmentos dos ossos e recolocá-los na posição correta.

Esta técnica é inédita no Brasil, sendo seu procedimento já amplamente reconhecido no exterior desde 1998.

Aproximadamente 8.000 médicos já foram treinados pela Kyphon nos Estados Unidos, Europa e Ásia-Pacífico e,
Cerca de 190.000 pacientes  em 220.000 fraturas da coluna já foram realizadas até o final de 2005.

Normalmente, o procedimento leva menos de uma hora por fratura tratada e pode exigir a permanência no hospital por uma noite.

O uso da Cifoplastia com Balão é indicado  principalmente  para:

- fratura de vértebra
- correção de cifose
- osteoporose primária
- osteoporose secundária
- lesões osteolíticas

Tags: & co,adresse,adria alimentos,adria alimentos do brasil,adria alimentos do brasil ltda,adultos,advamed code of ethics,ag,aktiengesellschaft,alimentos,alimentos do brasil,alimentos no brasil,alltel cash merger,aluminium,aluplast,angioma,aortica,articulacion,articulaciones,articular,artrodesis,artrosis,back,back pain,back surgery,balon,balones,balón,basilar,bone,brillant,brugmann,cadera,cement,cervical,cifosis,cirugia,closed,co,codo,collapsed,columna,columna vertebral,colunna,compressed,compression,compression fracture of the spine,compression fracture thoracic spine,con,congenita,congénita,corse,corsé,cuello,cuidados,depuy spine,deutsche,deutschland,disco,dolor,dorsal,duramatrix,eigenschaften,ejercicios,en el,end plate,endplate,enfermedad,enfermeria,enfermería,escoliosis,esguince,fenster,fisioterapia,fraction,fractur,fractura,fracturas,fracture,fracture treatment,fractured,fractures,frankfurt,gelan,gmbh,gruppe,hamburg,hemangioma,hemangiomas,hernia,hernia discal,hersteller,hertel,hof,holding,hombro,hueso,huesos,hydrotec,idiopatica,idiopática,industrie,injection,injury,insufficiency,jobst,juegos,kbe,kft,kommerling,konzern,kornwestheim,kunststoff,kyphon,kyphon medtronic,kyphoplasty,kyphosis,l1,la mano,lanzamiento,lesion,lesiones,ligamentos,lumbar,lumbar spine,magerl,manejo,mano,medicinal,methylmethacrylate,mitarbeiter,morhange,muscular,muñeca,münchen,non spinal fractures,okna,operacion,osteolytic,osteomyelitis,osteoporose graficos,osteoporosis,osteoporosis fracture,osteoporosis symptoms,osteoporosis treatment,osteoporotic,paciente,pacientes,pain,paleopathology,pc,pcware,pedicular,pie,pierna,plasty,plustec,polymethylmethacrylate,prisionero,profil,profile,profine,protesis,protocolo,protocolos,pvc,rehabilitacion,rehau,rodilla,rotura,s730,salamander,schuhe,schweiz,sip,spinal,spinal column,spinal compression fracture,spinal fracture surgery,spine,spine fracture,spine injury,spine pain,spine trauma,stahl,strunz,surgery,surgery spine,t12,tendinitis,thoracic,thoracic spine,thoracolumbar,tobillo,tratamiento,tratamientos,traumatologia,treatment,trocal,umsatz,unternehmen,usually,veka,vertebra,vertebrae,vertebral,vertebral body,vertebral column,vertebro,vertebroplastia,vertebroplasty,visbek,von,vorstand,vértebras,wagner,ware,wedge,wedging,zimmer,zimmer careers,zimmer catalog,zimmer holdings,zimmer jobs,zimmer medical devices,zimmer online catalog,zimmer spine inc,zimmer usa,österreich,

Full article on Wired

People have been griping about the so-called "Loudness War" since the early 90's.  I'm not going to go into the details - I don't remember my sophomore year DSP classes that well anyway - but this IEEE Spectrum article explains things pretty clearly.  The basics are that a recording engineer can make a record sound louder at the expense of the dynamic range by compressing the audio signal (not the same thing as compressing a file to make it smaller, by the way).  In the early 90's, audio engineers started compressing the audio on rock albums, which made the songs sound louder and more immediate, giving them an edge when played side-by-side with their less compressed competitors.  With each passing year, however, the level of compression necessary to achieve that "edge" has increased (since everyone else are compressing their albums, too), resulting in a steady increase in compression levels over the past twenty years - hence, the "war".

If you don't believe it, put in a major label rock CD from 1988, 1998, and 2008, and compare how loud they sound.  At first glance, it doesn't seem like a big deal - hell, the louder stuff sounds better - but the actual audio quality is quite a bit lower.  And whereas you can compress an audio signal yourself to increase the loudness, if that's your cup of tea (many radio stations and car stereos do so, for example), you can't uncompress a file to restore the dynamic range.

Anyway, this state of affairs sucks.  I used to look forward to remastered re-releases of old favorites - especially records from the 80's or earlier, many of which had haphazard, poor transfers on their initial CD releases - but I've largely stopped bothering.  What's the point, if I'm going to actually get something with poorer audio quality?  I'm hoping that some day we'll see a movement to re-release albums remastered with their levels restored to something a little more tolerable.  Until then, though, don't necessarily assume that that new re-issue of that classic 60's album sounds better than the 1995 issue.