I'm following a guide for converting MP4 to AVI using AutoGK and as part of it I need a copy of a very old program called avs2avi which is from around 2001 I think written by Hmage, which is NOT the same thing as avs2avi v1.39 by Moitah.
Try as I might I cannot find any working ive download links for this program anymore. Does anyone in here perhaps have a copy of this program in their archives they'd be willing to share with me please?
Thanks
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 1 to 30 of 52
Thread
-
-
Only that I'm new to having to handle MP4 videos because of having a TV that doesn't support reading them and an increasing lack of XviD sources for the videos I want to watch. I'm familiar with AutoGK, know how it works/how to use it to best advantage, already have it and all supplementary programs installed and because it was the first solution that came up when I went searching.
Originally Posted by El Heggunte
Thank you poisondeathray for the attachment. Downloaded, Cheers. -
I understand what you mean about AutoGK. It does the compression check and works out the best
resolution based on your target size, then does a 2-pass encode.
Not sure of any other program that does that - most offer CQ mode, great for quality, but you lose
some of the standalone compatibility, as well as predictable file size. -
To be honest with ya, I really don't need the predictable filesize at all anymore. I used to and that's what I'm using right now in my first experimental test encode, but I predict very shortly going forward I'll be using the CQ mode of AutoGK as well. As I get more proficient at it I dare say I'll probably do my own AC-3 or MP3 LAME encodes as well and just insert them into the final AVI as-is, but just for now until I get a handle on how it all works, it's just AUTO settings all the way until I'm sure the end result will actually play on my TV without problem.
-
Likewise, predictable file sizes not such an issue for me either. However, 2-pass with the compression
check was the main benefit to AutoGK as far as I could tell.
I installed AutoGK on one of my XP systems along with the
Xvid that comes with it. I've been using Virtualdub to do some encodes using that Xvid.
Got very results with CQ 4, even though Xvids CQ mode can create massive bitrate spikes in certain scenes of
high detail which can cause some standalones to stutter momentarily. By lowering the resolution a little
(I used 624 x ???) the overall bitrate was lower and the problem was solved. -
Here's another hint for converting MP4 to AVI using AutoGK. If you have the Haali splitter installed, try simply changing the MP4 file extension to AVI and opening it with AutoGK.
You'll need to deselect the audio before converting, otherwise AutoGK will try to demux it and give you an error, but otherwise it should convert the video okay and it should be quicker than doing it via avs2avi. Chances are you'll need to convert the existing audio to an AVI friendly format manually, but it'll be the same procedure to add it to the AVI AutoGK produces as it'd be to add it to the AVI created by avs2avi.
If you're going from high def to standard def and want to convert the colors correctly, and you have ffdshow doing the decoding, you can get ffdshow to send the video to AviSynth for color converting. Open the ffdshow video decoder configuration, and under the AviSynth filter there's a text box. Add the same color conversion there (including loading the plugin) as you'd add to your script when using avstoavi. In my case it'd be:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\ColorMatrix.dll")
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
Make sure "add ffdshow video source" is checked, then enable the AviSynth filter and hit "Apply". When you preview the encode using AutoGK, you can right click on the ffdshow icon and deselect/select the AviSynth filter. If all is working correctly, you should see the colors of the preview video change a little as you select/deselect the filter. It'll be most obvious if you're previewing a bright part of the video with lots of reds or blues.
Once you've finished converting, just change the extension of the source video back to MP4. And of course if you use avi2avs later on, don't add color conversion to both the script and ffdsshow all you'll convert the colors twice. I've had a few other people test this method for converting MP4s using AutoGK and it's worked for them. For some reason, unless I'm going slightly mad, I had the same method working for MKV files a couple of reformats ago, but after a reformat it stopped working for MKVs and I've never been able to get it to work again.
Lately, instead of using DirectShowSource to convert video using avi2avs and AutoGK, I've sometimes been using ffms2 instead. It generally works just as well, but if you want to edit the AVI created by avs2avi it tends to be more frame accurate when seeking than DirectShow. You'd need to download ffms2 and put it somewhere, then instead of creating a DirectShow script to open the MKV/MP4, you'd use ffms2 instead. So an AviSynthesizer template for creating the script might look something like this (including color conversion):
#ASYNTHER FFMS2 Colour Convert - No Audio
LoadPlugin("C:\Program Files\ffms2\ffms2.dll")
[FFVideoSource("%f")]
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\ColorMatrix.dll")
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
The first time you open the script or wrap it into an AVI, there'll be a pause of up to 30 seconds or so. That's normal. FFMS2 automatically creates an index file the first time you use it to open a video, so there's a pause until the indexing process is finished. -
On the subject of Xvid encoding and compression tests....
My basic understanding is Xvid's compression or quality is based on a percentage of the file size at maximum quality. A compression test simply tries to emulate that by encoding a smaller percentage of the video rather than the whole lot, but a single pass Q2 encode will produce a 100% quality encode (for Xvid) and the maximum file size. So if you obtain the 100% file size and run a 2 pass encode while specifying a file size 75% of it, you've got a 75% "quality" encode. 70% to 75% is supposed to be the optimum compression/quality ratio for Xvid.
Running a 75% "quality", single pass encode using AutoGK (which I think uses an Xvid quantizer of 2.67) will produce a file size which should give you close to 75% quality, as reported by AutoGK, when running 2 passes.
The above is based on the assumption the same Xvid settings are used each time. AutoGK does it a little differently. It adjusts Xvid's minimum and maximum quantizers according to the results of the compression test. So for a compression test result of around 70% or more, it'll set the maximum quantizers to 2 and the minimum quantizers to 3. If the compression test result is lower, it might set them to 3 and 4 respectively etc. I think the idea (someone here recently informed me) is to produce a kind of constant quantizer encode while running 2 passes. It means AutoGK calculates the quality a little differently, but it seems to be effective. I think that's one of the reasons why AutoGK produces good quality encodes. There seems to be less of a likelihood fast motion scenes will become too blocky when adjusting the minumum and maximum quantizers that way. -
Thanks for the info hello_hello - you know more about the internals than I do. I'm only going by what I see externally.
For example, for those selecting 2-pass and choosing a custom size it does something quite clever.
It uses the compressibility test, and assuming you pick auto-width, it selects the best resolution
to maintain quality at the chosen custom size.
It's the only program I'm aware of that does this. Quite often you see newbies encode 2-pass using Virtualdub
or similar, but the bit rate was too low for their chosen resolution and it looks like crap. -
Cheers for the tip. It's kinda 6 of one and half a dozen of the other though. You either mux the audio to the frameserve AVI beforehand (which take very little time) or mux it to the completed proper AVI after encoding (which takes a lot longer). Same end result.
I don't understand all this about colour correction and HD video yet. I'm just using a program called AVISynthesizer and makeAVIS to do it at the moment and it appears to have some templates that handle this bit I don't understand for me. That's good enough for me at this stage until I have the time to figure out what it all means.
One question I did have was about sharpening filters. If I wanted to use a sharpening filter (I like MSharpen by Donald Graft), then where would you recommend being the best place to employ this?
Where would it be most effective/least noisy to be applied? In the ffdshow decoding as a post-processing filter during decode of the MP4, in the AviSynth script being fed to AutoGK or somehow in the VDub encoding process? -
This is what I've started doing with AutoGK. Running it at the default 75% CQ setting. I'm processing the audio manually myself by encoding to AC3 at 192kbps and then just getting AutoGK to mux that directly to the XviD video it produces. Whilst the resulting filesizes are not that important to me, they are coming out a little larger than the traditional sizings you see. ie. a video that would normally be around 233MB has come out at 290MB. Not a big deal at all I know, but I'll drop the CQ setting back to 70% and keep testing.
Of course the audio is part of that size inflation. I'm using 192kbps whereas 128 or perhaps even less like 112 might be normal to see. I've limited the maximum horizontal resolution to 640 pixels too. That seems more than enough to me and greater than the majority of XviDs I see anyway. -
-
The main reason I offered the alternative is it generally appears to be a little faster when it comes to encoding than doing it via a script and wrapping it into an AVI, but yeah, the end result should be the same.
HD and SD use a slightly different method for converting video to RGB, and at some stage during playback the video is converted to RGB. If you take a HD video and simply re-encode it at a standard definition resolution, then because during playback the SD encode is converted to RGB using a different colorimetry, the colors can look a little "off", which generally equates to the video looking a little darker or people's faces looking a little "dark red" rather than "natural". It's usually easy to confirm if you have a HD video and re-encode it as SD without converting the colors. When you compare the two you'll generally see a difference.
In the templates you're using, this is the part which handles the color conversion:
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\ColorMatrix.dll")
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
Rec.709 is the HD colorimetry, while Rec.601 is the SD colorimetry, and the ColorMatrix plugin does the color converting.
One problem though, is apparently "scene" encoders don't convert the colors, so any of their SD AVIs/MP4s which were encoded using a HD source, which is pretty much all of them these days, will have been encoded without correcting the colors. Therefore, if you're converting a "scene" encode, whether it be HD or SD, you probably want to convert the colors in the process.
Often a "scene" SD encode will have BT.709 (HD colors) written to the video stream, and in a perfect world the player would make note of it and use HD colorimetry on playback, but I doubt this happens much in practice. It's probably better to convert the colors correctly when encoding in the first place.
I generally don't use much filtering so I'm probably not the best person to ask, but when it comes to converting HD to SD, if I'm going to add sharpening, after a bit of messing around with various sharpeners, I settled on asharp. Mind you as a rule I don't like sharpening, so if i do use it, I try to keep it "subtle".
I don't think it matters exactly where in the chain it goes, as long as you're not using other filters too... obviously if you're "denoising" you'd probably want to to that before sharpening, but the only other choice would be to sharpen before resizing or sharpen after resizing. If AutoGK is resizing then generally you'll be sharpening first (which I prefer anyway) but other than that, I can't think why it'd make a difference if the sharpening is added to the script or if ffdshow is doing it.
Being lazy, if I'm going to add filtering I generally try ffdshow first, before trying to work out how to manually add it to the script.
Give asharp a try while you're experimenting. I use an unsharp masking threshold of 0.9 and an adaptive sharping strength of 3 when going from HD to SD. If it's SD to SD you might want to bump the threshold up a bit.... but I find asharp can be quite effective without being "obvious". Personally I prefer video which looks a little blurry to one which has been obviously sharpened. -
You sound like the same chap whose guide I'm following from the Doom10 forum posted under the name yetanotherid.
Thanks for the info about colours. I did not realise any of that. FWIW despite having the big TV and all that, I just don't see the benefit in HD video for the kind of material I like to watch, so I tend to avoid it wherever possible anyway. If there's a choice, I always download the SD version, because for me, the quality gain in the HD version simply isn't worth the hassle with downloading & handling much bigger filesizes, but that's just my choice.
The AutoGK thing here is working well now and I've established a sort of 'system' I follow to do conversions in an almost batch fashion, which is good. I've sort of settled so far on a very mild MSharpen filter in the AviSynth script acting on the input decoded file before any other resizing but after any necessary cropping. I've reduced my maximum horizontal width down to 624 as another suggested, simply because 624x352 gets closest to the most common 16:9 DAR. To compensate for that, I've upped the target quality % back to 75 again, because the filesizes were coming out unusually small instead of slightly oversize at 75% & 640 width.
The audio I'm keeping with my current system of 192kbps AC3 @ 48kHz, which works well for me with no noticeable artifacting.
I am looking for is a media IDing type program that will tell without actually playing what the audio & video specs are for a file? Kinda like a AVIcodec or GSpot that works on MKV & MP4 files. Can you recommend me something that will do the trick?Last edited by DRP; 7th Aug 2012 at 23:26.
-
Yeah that's me. I actually used the same ID on this site a long time ago, but when I started posting in this forum recently, I completely forgot about it and signed up with a new ID.
I'd actually wondered if anyone had read/used that guide. At least now I know one person has....
MediaInfo. Works with just about any type of video/audio file. If you set it to open using HTML view (or change the view via the View menu) that'll give you the most detailed info.
MediaInfo "rounds" resolutions and frame rates. For instance it'll display 16:9 as the display aspect ratio for video which isn't exactly 16:9, and it'll display 23.976 as the frame rate even if it's really 23.974 or something like that. I'm not sure why. Everything else should be accurate. If I want to check the resolution/aspect ratio and frame rate exactly, I open the video with MPC-HC. -
I think you're dead right about this you describe above. I've watched a few videos now in SD resolution, but they appear slightly too dark. Everything in shadow or shade of normal lighting appears as jet black and you can't see any detail at all. Everything is just lost in the blackness.
So to correct this I can just use the color correction template in AviSynthesizer right? Even though it's already been encoded to another lossy format, I can still use this colour conversion template and it'll work?
Is there a way of knowing for sure, like with MediaInfo for example, what colourmetry it's actually been encoded with for sure, or is the only way by actually watching it and trying to tell by your own eyes whether is looks right or not? -
It's not so much a case of detail being lost or blacks being too black, more a case of the colors looking a little "off", but because of this the overall picture can look a little darker.
Here's an example of the color difference. I still had these saved from when I first started converting HD to SD and posted in another forum trying to work out what was going on. I think the first one is how the picture should look. When the colors aren't converted correctly, reds and blues tend to get darker, while green gets brighter (I think). Anyway, this is the sort of difference you might see. Try loading each pic in it's own browser tab and switching between them.
If you look at the guy's face, you'll see it looks a little darker in the second pic. It's not a huge difference in this case, but sometimes the effect can be quite pronounced. And yes, you can still use the color conversion template to correct the colors when re-encoding.
The overall black levels though don't really change, so if you've got a problem with blacks looking too black, it's possibly a levels issue. That's not normally something you have to worry about when encoding but sometimes you need to fix it on playback.
The story..... PCs use full range levels (0-255) while most video uses "limited" TV levels (16-235). What this means is when PC levels are used "0" is black, while for most video "16" is black. If you display video on a PC monitor without correcting the levels (converting from 16-235 to 0-255), it might look a bit washed out. Likewise if you send PC levels to a TV expecting TV levels, the picture will probably look too dark. As I said though, it's not something you generally have to worry about when encoding as pretty much all video uses 16-235, TV levels, and the color correction in the template doesn't effect that, however it might be something which needs to be fixed on playback. And keep in mind, if you're used to watching video on a PC monitor without correcting the levels, when you do correct them, the picture can look too dark until you get used to it.
I don't know if levels is your problem, or what you're using to play the video and what you're using for a monitor, but it's also possible some players will automatically correct the levels when playing some types of video but not others, so you can compare the source video to an encoded version on a PC and the black levels will look different even though they're actually the same.
In my case I use my PC as a media player and I have the video card set to always convert TV levels to PC levels, and I've set the PC HDMI input on the TV to expect PC levels so everything displays properly.
If you want to experiment with levels when converting, AviSynth will convert them. Just add this to the script:
ColorYUV(levels="TV->PC")
or
ColorYUV(levels="PC->TV")
But keep in mind you should almost never have to use either when encoding (although off the top of my head I know of a couple of examples where video has been converted to DVD using the wrong levels), so if it fixes the problem, you probably need to sort out your playback chain.
The video colorimetry can be written to the video steam. If it is, MediaInfo should display it for h264 video. Keep in mind though, it might be what's written to the stream but there's no guarantee that's the colorimetry which was actually used. It's just "info" which can be written to the stream when encoding. As a rule of thumb though, it's fairly safe to assume all high def video uses Rec.709 and all standard def video uses Rec.601, except of course for those "scene" encodes where they've failed to convert the colors correctly. I just checked a couple I have here and Rec.709 is actually written to the video stream. I guess the scene encoders assume the player will read that info and display the video with the correct colors, but I'd be willing to bet that virtually never happens. As far as I know, most players base the color conversion choice on the video's resolution.
Anyway.... if the colorimetry is written to the video stream MediaInfo will display it something like this:
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177
or this:
Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M -
PS If you are using a PC for playback here's how to determine if the correct levels are being used on playback. Play a video which contains black bars. The bars should be black, not dark grey. If you change the levels (whether you change what the player or video card is sending or change what the TV expects to receive) and the black bars get blacker, then the "blacker" version is using the correct levels.
If, when you change the levels, the black bars don't get any blacker but the picture gets darker, then the original levels were correct (as the black bars were already "black"). Likewise if you change the levels and the black bars get lighter, then the original levels were correct. -
Well I do have a partial answer to that question after experimenting a bit today with denoising filters. Both the filters I tried, adding them to the script really slowed the encoding process down. I'm not sure why.
I ran two test encodes using one filter, first adding it to the script which I then wrapped into an AVI, the second time adding it to ffdshow's AviSynth filter instead. I moved the AviSynth filter up so it was the first filter in the ffdshow filter chain. For whatever reason, when running a single pass encode using AutoGK, with the denoise filter added to the script encoding speed was around 35fps. With it added to ffdshow's AviSynth filter instead, encoding speed increased to around 72fps.
I'm sure the denoising was working either way, as the final file size was within a couple of MBs. Without any denoising, at the same quality the file size increased by about 55MB.
I have added sharpening to the script before and not noticed a major slowdown, so I can only assume it depends on the type of plugin/filtering being added to the script, but if I've got a choice from now on, I'll be adding it via ffdshow's AviSynth filter instead. -
Excellent answer thanks! I have just checked some encodes I've got going here in process and cancelled them when I checked MediaInfo and found the BT.709 line. I shall redo these with the colour correction now.
Another question now. I've noticed some problems sometimes with audio sync. The source files are AVC/AAC encodes so I'm extracting the audio with Goldwave and then converting that WAV to AC3. I'm using DVD-lab with the TMPGEnc AC-3 encoder for the conversion and DVD-lab includes an easy option of adding (or subtracting) time to the start of an AC-3 file to correct audio sync. How can I find out what audio pre-load or offset there may in the original AVC/AAC encode so I can allow for it in the subsequent AC3 file I create after the WAV extraction using Goldwave? -
How much is the audio out by?
If an audio delay is used, MediaInfo should display it, under the audio section. It'll be listed as "delay relative to video". If there's no "delay relative to video" then there should be no audio delay.
There can be circumstances where no audio delay is shown but there actually is one. Sometimes muxing programs add junk data to the beginning of an audio stream which becomes a "fake delay" although I think it generally only applies to AVI and MP3 audio. I've had quite a few ocassions though where I've had to include an audio delay after encoding and for the life of me have not been able to work out why. I just put it down to one of life's mysteries.
It might be easier to adjust the audio delay after encoding rather than try to compensate for it when encoding. When adding an audio stream to an AVI, or to adjust the audio delay of an existing AVI, you can open it with VirtualDubMod, then Streams/Streams List, right click and select Interleaving, specify a delay amount (it can be positive or negative) then re-save the AVI. For the record, AutoGK always sets the audio interleaving to every 2 video frames. The VirtualDubMod default is every one video frame. It's no big deal, but in case you wonder why when you adjust the audio delay of a file AutoGK produces and it gets slightly larger when you re-save it, it's the interleaving. If you set it to every 2 video frames the size of the AVI file shouldn't change.
Something else you could try.....
Every so often, you'll encode a constant frame rate video which has duplicate frames, or a frame gets dropped when encoding, or something along those lines. If the audio sync changes over the course of the video you could try a DirectShow script which looks like this:
DirectShowSource("E:\video.mkv", audio=false, fps=23.976, convertfps=true)
Naturally you'd change the frame rate according to the frame rate of the source video, but if the audio sync isn't consistent, or it's not consistently out by the same amount, the above will probably fix it. I'm actually re-encoding some old MKVs at the moment which require the above frame rate conversion to fix the audio sync.
Maybe one of the programs you're using is messing with the audio sync for some reason (Goldwave or DVD-Lab). At least they might be if the audio sync problem is a regular occurrence. If you've got a program which will display the length of an audio stream exactly (foobar2000 for example will tell you the length down to the ms as well as display the total number of samples in an audio stream) try comparing the original stream, the wave file and the AC3 version to ensure they're exactly the same length.Last edited by hello_hello; 12th Aug 2012 at 00:44.
-
Another thought, try adding the wave file to the AVI using VirtualDubMod, and then use VirtualDubMod to check if the audio is in sync. Try the same thing again with the AC3 version etc....
VirtualDubMod will also tell you the length of each when you add them to the AVI. I just converted a wave file to AC3 and there was a small difference, but only 9ms, and while I don't know why it's definitely not enough to be concerned about it.
Wow.... I'd forgotten how fast AC3 encoding is. Using the Aften encoder, the 25 minute stereo wave file I tried, encoded at around 480x real time, or took about 3 seconds to convert to a 192kbps AC3. Using LAME's default settings, a 128kbps MP3 encode happened at around 40x real time, or took about 36 seconds. I guess that's why AC3 needs a higher bitrate for a given quality. -
-
Not especially. I've got two PCs here, ones a dual core (E6750) and the other a quad Q9450), but for single core tasks they're pretty much the same, speed-wise.
I've got both of them busy encoding at the moment, and the longer the encoding jobs run the more motivated I'm getting to finally upgrade the dual core. Something I've been putting off for about a year.
I don't know why AC3 encoding is so fast. I just used foobar2000 to run the conversion using the AFTEN encoder. The command line is:
-readtoeof 1 -v 0 -b 192 - %d
MP3 encoding is usually slower than my example above when using most encoder GUIs, as for CBR MP3 encoding they generally use a -q2 quality setting. The default for LAME is -q3 which is what I used above and is definitely faster. I'd have to wait until the PC isn't busy to check, but I think a -q2 128k MP3 encode takes around twice as long as a -q3 128k MP3 encode.
I don't think there's a similar quality setting for AFTEN. Not that I can see, anyway.
http://aften.sourceforge.net/longhelp.html -
Thanks for the audio sync issue information. It hasn't become a major issue for me just yet, rather just something I've noticed.
Another new issue I've come up with:
I'm trying now to convert a very large resolution MP4 which my computer can't even render properly because the resolution is so ridiculously high and I don't have infinite RAM installed. The problem is that is it uses variable frame rate AVC/AAC encoding and when I extract the audio using GoldWave, it comes out being about a minute short in length, so there will be some serious audio sync issues there no doubt!
How do you deal with keeping the audio in sync when the video is constantly speeding up and slowing down due to a variable frame rate? -
DirectShowSource("E:\video.mkv", audio=false, fps=23.976, convertfps=true).
The above should add/drop frames to keep the frame rate of the encoded video constant. If the encoded video isn't smooth as a result, try:
DirectShowSource("E:\video.mkv", audio=false)
ConvertFPS(24000/1001)
The first method is the DirectShow way of converting the frame rate.
ConvertFPS() gets AVISynth to do it, and it's "Convert" function works by blending frames if need be to keep the video smoother, but it may add blurriness in places. AviSynth also has a couple of other methods of converting the frame rate but you'd probably use one of the above. You can read about AVISynth's frame rate conversion here: http://avisynth.org/mediawiki/AssumeFPS
Just don't forget DirectShow's "convertfps" is the same as AVISynth's ChangeFPS. Both duplicate or drop frames to maintain a constant frame rate. -
Okay, understood, thanks for that. Now, here's the weird bit. The video in question when analyzed with MediaInfo says it's 3:40 long for general, audio & video. Yet when I read the AAC audio from it using GoldWave for conversion, the soundtrack only comes up being 2:40.496 long. Any suggestions as to why this may be? There are no error messages or any other indication anything's wrong.
Edit: Forget it. I've just played the file on the computer and it would appear to be corrupted. The audio just stops abruptly at 2:40 while the video keeps going!
Similar Threads
-
BatchShrink, a batch wrapper for DVD Shrink 3.2
By midders in forum DVD RippingReplies: 22Last Post: 12th Feb 2012, 02:12 -
mp3 in acm wrapper?
By DarrellS in forum AudioReplies: 5Last Post: 11th Oct 2010, 21:30 -
vfw wrapper help
By video_2010 in forum CapturingReplies: 0Last Post: 21st Jul 2009, 14:48 -
Trying to understand wrapper vs codec
By brassplyer in forum Video ConversionReplies: 1Last Post: 27th Feb 2009, 00:23 -
Removing the VODEI wrapper without infecting your PC
By gremlin1812 in forum User guidesReplies: 6Last Post: 23rd Apr 2008, 02:42