due to striker’s migration from Joomla to WordPress yesterday, all my lunar related posts will now belong to my devblog at lunar linux.

Jean

1. used software/material
2. preparation
3. execution
4. results
   1. testcase1 – big buck bunny 1920×1080 » lanczos 854×480 » 1920×1080
   2. testcase2 – sintel 1920×818 » lanczos 1126×480 » 1920×1080
   3. testcase3 – elephants dream 1920×1080 » bicubic 640×360 » 1920×1080
   4. overall result
   5. visual results
5. conclusion

 
used software/material
MPlayer, Avisynth, Bash, Gimp, ImageMagick, OpenMovie Sintel, OpenMovie Big Buck Bunny, OpenMovie Elephants Dream

 
preparation
I took screenshots of a movie, stored the original highres image and created a lowscaled version of it. Then I created upscaled (to the same resolution as the highres image) variants of that lowscaled variant. And finally I compared the upscaled variant with the original highres variant.

 
execution
To create screenshots I have written a little Bashscript which gets screenshots using mplayer. The quality of the jpegs is set to 100 to have “lossless” images (more or less). The script needs ffmpeg to get the duration of the movie (pretty sure that might work with mplayer aswell, just didn’t find out how to easily parse that):

#!/bin/bash

infile=$1;
amount=$2;

# getting the length of the movie in seconds
ffmpeg -i "$infile" 2>/tmp/video.log
h=$(grep Duration /tmp/video.log | awk '{ print $2 }' | cut -d: -f1);
m=$(grep Duration /tmp/video.log | awk '{ print $2 }' | cut -d: -f2);
s=$(echo "($h * 60 * 60) + ($m * 60) - 60" | bc);

for (( x=1; x<=$amount; x++)); do
  stime=$(echo "$x * ($s / $amount)" | bc);
  echo $stime;
  tmp=$(mplayer -frames 1 -ss $stime -vo jpeg:quality=100:outdir=screens $infile > /dev/null);
  mv screens/00000001.jpg screens/$x.jpg
done

Then I’ve used gimp to create low-res variants of that screens – For the first two testcases I used lanczos and downscaled to a height of 480px. For the third testcase I used bicubic and downscaled to a height of 360px.

Then I’ve used lots of avisynth scripts to do the upscaling. An example for blackman and nnedi3:

source = ImageSource("3.jpg").Trim(0,-1)
us3 = BlackmanResize(source, 1920, 1080)
us13 = nnedi3_rpow2(source, rfactor=4, cshift="spline36resize", fwidth=1920, fheight=1080)

#ImageWriter(us3, file="3_blackman", type="jpeg")
ImageWriter(us13, file="3_nnedi3", type="jpeg")

The resulting upscaled image I’ve compared to the original image using ImageMagick:

convert originalimage.jpg upscaledimage.jpg -fx "abs(u[0]-u[1])" pgm:- \
  | identify -verbose pgm:- \
  | grep -E "mean|max|devi"

 
results

 
Big Buck Bunny

1920×1080 » (lanczos) 854×480 » 1920×1080

screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	640K
	bicubicResize	63 (0.247059)	1.39138 (0.0054564)	2.02799 (0.00795292)	564K
	bilinearResize	66 (0.258824)	1.41046 (0.00553122)	2.1246 (0.00833176)	568K
	blackmanResize	60 (0.235294)	1.32716 (0.00520453)	1.7842 (0.00699688)	584K
	lanczosResize	59 (0.231373)	1.32695 (0.00520371)	1.76561 (0.00692397)	588K
	lanczos4resize	58 (0.227451)	1.31528 (0.00515796)	1.73246 (0.00679397)	592K
	pointresize	138 (0.541176)	1.93816 (0.00760062)	3.38685 (0.0132818)	688K
	sincresize	97 (0.380392)	1.94942 (0.00764479)	3.12623 (0.0122597)	712K
	spline16resize	60 (0.235294)	1.34655 (0.0052806)	1.85531 (0.00727572)	580K
	spline36resize	58 (0.227451)	1.32948 (0.00521366)	1.78602 (0.00700402)	584K
	spline64resize	59 (0.231373)	1.3242 (0.00519292)	1.77446 (0.00695865)	584K
	nnedi3 (cshift=spline36)	59 (0.231373)	1.34151 (0.00526083)	1.76169 (0.00690858)	616K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	56 (0.219608)	1.34097 (0.0052587)	1.76592 (0.00692518)	620K
	spline36resize(hq4x)	81 (0.317647)	1.61154 (0.00631977)	2.08531 (0.00817769)	568K
screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	1100K
	bicubicresize	131 (0.513725)	2.01965 (0.0079202)	2.58451 (0.0101353)	716K
	bilinearresize	129 (0.505882)	2.06215 (0.00808685)	2.66154 (0.0104374)	724K
	blackmanresize	128 (0.501961)	1.92173 (0.0075362)	2.37666 (0.00932023)	744K
	lanczosresize	128 (0.501961)	1.91967 (0.0075281)	2.36059 (0.00925722)	752K
	lanczos4resize	128 (0.501961)	1.89933 (0.00744836)	2.33001 (0.00913729)	756K
	pointresize	173 (0.678431)	3.04469 (0.01194)	3.97362 (0.0155828)	924K
	sincresize	167 (0.654902)	2.94485 (0.0115484)	3.62896 (0.0142312)	920K
	spline16resize	128 (0.501961)	1.95451 (0.00766474)	2.44045 (0.00957039)	740K
	spline36resize	128 (0.501961)	1.92393 (0.00754484)	2.37922 (0.00933026)	744K
	spline64resize	129 (0.505882)	1.91636 (0.00751512)	2.36858 (0.00928855)	744K
	nnedi3 (cshift=spline36)	119 (0.466667)	1.94348 (0.00762151)	2.34163 (0.00918287)	776K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	112 (0.439216)	1.94203 (0.00761579)	2.34288 (0.00918778)	776K
	spline36resize(hq4x)	122 (0.478431)	2.19204 (0.00859625)	2.6589 (0.0104271)	744K
screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	732K
	bicubicresize	49 (0.192157)	1.32602 (0.00520009)	1.51821 (0.00595376)	572K
	bilinearresize	53 (0.207843)	1.33697 (0.00524301)	1.57944 (0.0061939)	572K
	blackmanresize	43 (0.168627)	1.29434 (0.00507583)	1.3829 (0.00542314)	592K
	lanczosresize	41 (0.160784)	1.29722 (0.00508715)	1.37439 (0.00538977)	596K
	lanczos4resize	41 (0.160784)	1.28806 (0.00505121)	1.35241 (0.00530357)	596K
	pointresize	144 (0.564706)	1.86225 (0.00730295)	2.74764 (0.010775)	692K
	sincresize	110 (0.431373)	1.85213 (0.00726325)	2.47998 (0.00972541)	708K
	spline16resize	44 (0.172549)	1.306 (0.00512158)	1.42527 (0.00558931)	584K
	spline36resize	43 (0.168627)	1.29596 (0.00508218)	1.38413 (0.00542798)	588K
	spline64resize	42 (0.164706)	1.29306 (0.00507082)	1.37745 (0.00540178)	592K
	nnedi3 (cshift=spline36)	39 (0.152941)	1.30354 (0.00511192)	1.36729 (0.00536193)	620K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	39 (0.152941)	1.30032 (0.00509928)	1.36227 (0.00534222)	624K
	spline36resize(hq4x)	77 (0.301961)	1.52609 (0.00598468)	1.58047 (0.00619794)	572K

 
Sintel

1920×818 » (lanczos) 1126×480 » 1920×1080

screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	620K
	bicubicresize	76 (0.298039)	1.22795 (0.00481549)	1.64521 (0.00645182)	444K
	bilinearresize	78 (0.305882)	1.22377 (0.0047991)	1.66566 (0.00653199)	440K
	blackmanresize	72 (0.282353)	1.23057 (0.00482575)	1.57433 (0.00617384)	464K
	lanczosresize	71 (0.278431)	1.2383 (0.00485609)	1.57933 (0.00619346)	468K
	lanczos4resize	70 (0.27451)	1.24825 (0.00489511)	1.59137 (0.00624068)	472K
	pointresize	106 (0.415686)	1.48345 (0.00581747)	2.42587 (0.00951323)	508K
	sincresize	88 (0.345098)	1.47682 (0.00579147)	2.15301 (0.00844318)	492K
	spline16resize	73 (0.286275)	1.2257 (0.00480666)	1.58467 (0.00621438)	460K
	spline36resize	72 (0.282353)	1.23204 (0.00483153)	1.57656 (0.00618259)	464K
	spline64resize	71 (0.278431)	1.23371 (0.00483806)	1.57686 (0.00618377)	464K
	nnedi3 (cshift=spline36)	70 (0.27451)	1.2102 (0.00474587)	1.53526 (0.00602061)	484K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	76 (0.298039)	1.20684 (0.00473269)	1.53277 (0.00601086)	484K
	spline36resize(hq4x)	77 (0.301961)	1.4199 (0.00556825)	1.62984 (0.00639155)	416K
screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	1200K
	bicubicresize	68 (0.266667)	3.90677 (0.0153207)	4.63845 (0.01819)	756K
	bilinearresize	72 (0.282353)	3.93428 (0.0154286)	4.70239 (0.0184407)	772K
	blackmanresize	70 (0.27451)	3.75073 (0.0147087)	4.45619 (0.0174752)	824K
	lanczosresize	69 (0.270588)	3.77025 (0.0147853)	4.47537 (0.0175505)	832K
	lanczos4resize	70 (0.27451)	3.80719 (0.0149302)	4.51547 (0.0177077)	832K
	pointresize	141 (0.552941)	5.41135 (0.021221)	7.10313 (0.0278554)	992K
	sincresize	113 (0.443137)	5.13697 (0.020145)	6.00752 (0.0235589)	880K
	spline16resize	70 (0.27451)	3.76273 (0.0147558)	4.47469 (0.0175478)	812K
	spline36resize	70 (0.27451)	3.75862 (0.0147397)	4.46286 (0.0175014)	820K
	spline64resize	70 (0.27451)	3.7603 (0.0147463)	4.46454 (0.017508)	824K
	nnedi3 (cshift=spline36)	75 (0.294118)	3.69705 (0.0144982)	4.36505 (0.0171178)	836K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	72 (0.282353)	3.68776 (0.0144618)	4.35658 (0.0170846)	836K
	spline36resize(hq4x)	68 (0.266667)	3.9761 (0.0155926)	4.64142 (0.0182016)	760K
screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	652K
	bicubicresize	102 (0.4)	1.61719 (0.00634193)	3.41673 (0.013399)	516K
	bilinearresize	113 (0.443137)	1.62747 (0.00638224)	3.50645 (0.0137508)	516K
	blackmanresize	103 (0.403922)	1.57874 (0.00619113)	3.1816 (0.0124769)	544K
	lanczosresize	107 (0.419608)	1.58978 (0.00623445)	3.1924 (0.0125192)	548K
	lanczos4resize	118 (0.462745)	1.60308 (0.00628658)	3.20413 (0.0125652)	552K
	pointresize	212 (0.831373)	2.33259 (0.00914742)	5.96943 (0.0234095)	612K
	sincresize	141 (0.552941)	2.18924 (0.00858526)	4.94182 (0.0193797)	588K
	spline16resize	102 (0.4)	1.58086 (0.00619945)	3.22538 (0.0126486)	536K
	spline36resize	104 (0.407843)	1.58196 (0.00620377)	3.18951 (0.0125079)	544K
	spline64resize	106 (0.415686)	1.58257 (0.00620615)	3.18302 (0.0124824)	544K
	nnedi3 (cshift=spline36)	99 (0.388235)	1.52185 (0.00596802)	2.96699 (0.0116352)	560K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	101 (0.396078)	1.52184 (0.00596802)	2.98155 (0.0116923)	560K
	spline36resize(hq4x)	106 (0.415686)	1.80159 (0.00706505)	3.38661 (0.0132808)	496K

Averaged

 
Elephants Dream

1920×1080 » (bicubic) 640×360 » 1920×1080

screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	696K
	blackmanresize	182 (0.713725)	5.15758 (0.0202258)	9.2996 (0.036469)	672K
	lanczosresize	181 (0.709804)	5.17115 (0.020279)	9.25688 (0.0363015)	676K
	lanczos4resize	180 (0.705882)	5.19959 (0.0203906)	9.21027 (0.0361187)	684K
	spline16resize	183 (0.717647)	5.21444 (0.0204488)	9.46563 (0.0371201)	672K
	spline36resize	182 (0.713725)	5.1683 (0.0202678)	9.30998 (0.0365097)	672K
	spline64resize	182 (0.713725)	5.16437 (0.0202524)	9.28429 (0.036409)	672K
	nnedi3 (cshift=spline36)	174 (0.682353)	4.71817 (0.0185026)	8.52777 (0.0334422)	724K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	176 (0.690196)	4.70834 (0.0184641)	8.60432 (0.0337424)	732K
screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	328K
	blackmanresize	62 (0.243137)	1.10186 (0.00432103)	1.69206 (0.00663553)	496K
	lanczosresize	63 (0.247059)	1.10822 (0.00434597)	1.68183 (0.0065954)	676K
	lanczos4resize	62 (0.243137)	1.11478 (0.00437168)	1.67341 (0.00656238)	504K
	spline16resize	62 (0.243137)	1.10619 (0.00433802)	1.73069 (0.00678702)	488K
	spline36resize	62 (0.243137)	1.10259 (0.00432386)	1.69271 (0.00663806)	496K
	spline64resize	63 (0.247059)	1.10177 (0.00432066)	1.68822 (0.00662046)	496K
	nnedi3 (cshift=spline36)	56 (0.219608)	1.08019 (0.00423605)	1.54706 (0.00606689)	524K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	52 (0.203922)	1.07437 (0.00421321)	1.53682 (0.00602673)	524K
screenthumbnail	method used	peak	average	standard deviation	filesize
	original	-	-	-	648K
	blackmanresize	131 (0.513725)	3.69918 (0.0145066)	6.33968 (0.0248615)	688K
	lanczosresize	128 (0.501961)	3.70108 (0.014514)	6.31411 (0.0247612)	696K
	lanczos4resize	127 (0.498039)	3.72408 (0.0146042)	6.30599 (0.0247294)	700K
	spline16resize	132 (0.517647)	3.74263 (0.014677)	6.43383 (0.0252307)	684K
	spline36resize	129 (0.505882)	3.7027 (0.0145204)	6.3419 (0.0248702)	688K
	spline64resize	129 (0.505882)	3.70227 (0.0145187)	6.33526 (0.0248442)	688K
	nnedi3 (cshift=spline36)	127 (0.498039)	3.39755 (0.0133237)	5.79667 (0.022732)	736K
	nnedi3 (cshift=spline36, pscnr=4, etype=1)	125 (0.490196)	3.39746 (0.0133234)	5.7985 (0.0227392)	740K

 
Averaged #2

first average result + picture 1 result + picture 2 result + picture 3 result / 4

 
visual results
At the top of this long article I already explained that visual results are very subjective; that is because things look differently on different screens (tft/crt/etc), also due to different brightness and similar settings. However, sometimes the visual difference is obvious. Here are some examples:

original	lanczos
spline36	nnedi3

 
Conclusion
What we can see, looking at the numbers, is that the higher the resolution of your source (or better, the more details the source has) the better upscaling works. If your source is too blurry, upscaling won’t work as good as it could. All scalers perform quite good (except for point and sinc, but that was to be expected). Spline16 performs worse than spline36 and spline64, for upscaling spline36 performs better than spline64. Lanczos and spline are quite similar the difference is very minimal, according to the numbers, lanczos performs better than spline; overall best resizer for upscaling is nnedi3. Another thing which you can see in the visual results above is that the nnedi3 image doesn’t have the stairs-effect.

If you have to decide which resizer (in avisynth) to use for upscaling, go this route:

nnedi3 > lanczos/lanczos4 > spline36 > everything else

In a perfect world five dot one (5.1) would mean, that we’ll have sounds from behind (rear/surround speakers), sounds from the left and right (front left, front right speaker) vocals from the front (center speaker) and bass from the LFE channel (subwoofer). Notice that the “positional” estimation is important. So if we watch a movie, and someone is obviously speaking behind someone, we should hear that sound from the back (from the rear speakers). “Vocals” as in Speech should come from all directions, so if someone is talking on the left → the left speaker should output that. At least, that’s how I would (mis)-understand “Surround”.

As we aren’t in a perfect world, this is somewhat different. I checked the 6-channel sound files of a few dvds and the one of the openmovie sintel. The front left and right channels aren’t containing ANY vocals or they’re sounding like in a big hall, very quiet not easy to hear. First I thought it is related to the “haas”-effect, which says, what you hear first, tells you where the sound comes from. So if you hear something from front-left first (doesn’t matter whether vocal or not – might be some high tone) you’re thinking the vocals are coming from the left. I cannot tell if that is true. I found a small post in doom9 forums which might explain that behavior. http://forum.doom9.org/showthread.php?p=717044#post717044 ← that’s, why you’ll sometimes think there aren’t any vocals on the left and right channel. That’s because they’re just containing the difference as the center-channel contains the sum.

While trying around doing such upconversations it turned out (a few people on the net reported similar results) that it seems to be easier/better to do that conversation in steps, e.g.: stereo → quadrophonic → surround instead of stereo → surround. But: That might be personal taste.

Anyway. We have a stereo file, 48kHz, 16Bit. Due to it beeing stereo, we know it has 2 channels: left and right. We can create one additional channel out of them without much trouble. The center-channel. That channel is a mix of the left and the right channel with 50% volume of each:

    sox -S -V -c 2 source.wav -c 1 combined.wav mixer 0.5,0.5
    normalize combined.wav

That channel can be used now to create the new left and right channels. We’re inverting the specific channel, so that they’ll only contain the differences:

    sox -S -V -c 2 stereo.wav -c 1 sleft.wav mixer -l
    sox -S -V -c 2 stereo.wav -c 1 sright.wav mixer -r
    sox -S -V -M -c 1 -v -1 sright.wav -c 1 center.wav -c 1 right.wav
    normalize right.wav
    sox -S -V -M -c 1 -v -1 sleft.wav -c 1 center.wav -c 1 left.wav
    normalize left.wav

The “-v -1” causes an invert. The -M is used to merge both files (the inverted left / right and the center channel) that way, only the differences are left. Now we can over to our “surround” part. Let’s first talk about frequencies:

Most of the information I found about frequencies aren’t identical. While one says deep bass is between 20 and 60 Hz another says it’s between 20 and 40 Hz. Deep high tones between 3 and 12 kHz, another says between 2 and 3.5 kHz. Here, a simplified variant (which might not be correct)

• 20 Hz – 20 kHz human hear-able range (the older, the lower the max., likely you’ll hear up to a max. of 16 to 18 kHz)
• 80 Hz – 12 kHz voice / speech (there are also pages telling it’s up to 8 kHz)
• 300 Hz – 3,4 kHz voice / speech on analog phones
• 20 Hz – 200 Hz bass
• 200 Hz – 2 kHz middles
• 2 kHz – 12 kHz high tones
• 12 kHz – 20 kHz upper high tones

20 Hz – 80 or 100 Hz bass which you can’t locate (so for this frequencies it shouldn’t matter, where the subwoofer is located)

You’ll see, that’s not as easy as one might think. However, let’s take a look at some speakers. Averaged and rounded results of a few speakers I took a look at:

• high tone speakers (7): 2000 (2342) Hz – 20 kHz (21285)
• middle tone speakers (5): 400 (375) Hz – 13 kHz (12800)
• deep/low tone speakers (30): 40 (39) Hz – 6 kHz (5961)
• subwoofer (9): 40 (35) Hz – 200 Hz (232) ← the expensive ones I checked, range to 120 Hz and 150 Hz

All these frequencies might help us with our surround audio file. For example: The real low frequencies are there for the subwoofer, we don’t need them on every speaker. To reduce the “load” of our other speakers, we’ll limit the frequencies. Then: The center-speaker should be optimized for our vocals. Thus it shouldn’t contain too high frequencies to not cause distortion there. We’ll need a frequency filter again. Our rear-speakers won’t benefit from high frequencies. So… With all the above kept in mind, my suggestion is:

• front left, right: 80 Hz – 20 kHz
• center: 80 Hz – 12 kHz
• surround left, right: 100 Hz – 6 kHz
• lfe: 20 Hz – 200 Hz

The next step would be to create the other channels and to add the frequency-limitations.

    sox -S -V -c 1 left.wav -c 1 left-sr.wav sinc 100-6000 reverb
    sox -S -V -c 1 right.wav -c 1 right-sr.wav sinc 100-6000 reverb
    sox -S -V -c 1 combined.wav -c 1 center.wav sinc 80-12000
    sox -S -V -c 1 combined.wav -c 1 lfe.wav sinc 20-200
    sox -S -V -c 1 left.wav -c 1 left-fr.wav sinc 80-20000
    sox -S -V -c 1 right.wav -c 1 right-fr.wav sinc 80-20000

Now we have all channels. Now we’ll just add a delay of 15ms to the rear speakers and we’ll put the whole stuff together. That’s all

    multimux -d 0,0,15,15,0,0 \
     left-fr.wav right-fr.wav \
     left-sr.wav right-sr.wav \
     center.wav lfe.wav > final.wav

As the Comment of Jay (thanks) states – The LFE Channel is not simply a subwoofer channel – Its for effects. So you might want to just remove the vocals instead of doing lowpass filtering and limiting the frequencies

Remember, our source has only 2 channels (left and right) – For 4 channel input or 6 channels input this whole document is not very helpful. I’m trying to make “surround” out of “stereo” – So i have to “guess” to “try” and to “hope”

the whole script to do the conversation

#!/bin/bash

###
# stereo 2 surround
###

inFile="$1";
outFile="$2";
debug="$3";

# todo ...
#if [ ! -z sox ]; then
#echo "sox"
#  run=0;
#fi

#if [ ! -x multimux ]; then
#echo "multimux"
#  run=0;
#fi

#if [ ! -x soxi ]; then
#echo "soxi"
#  run=0;
#fi

#if [ ! -x normalize ]; then
#echo "normalize"
#  run=0;
#fi

# default parameter
soxParm="";
normParm="-q";

# debug parameter
if [ $debug -eq 1 ]; then
  soxParm="-V -S";
  normParm="-v";
fi

if [ $run -eq 0 ]; then
  echo "Error: Requirenment missing: normalize multimux, sox or soxi";
else
  echo " Preparing Source";
  normalize $normParm $inFile;
  rate=$(soxi $inFile | grep "Sample Rate" | awk '{ print $4; }');
  # if rate is 44100, we'll most likely have stuff from an audio-cd,
  # which we want to deemph at least i assume so
  if [ $rate -eq 44100 ]; then
    echo " + Source is 44.1kHz, De-Emphasing & Resampling...";
    sox $soxParm -c 2 $inFile source.wav deemph rate -v -a 48000
  else
    sox $soxParm -c 2 $inFile source.wav rate -v -a 48000
  fi
  # create combined channel
  sox $soxParm -c 2 source.wav -c 1 combined.wav mixer 0.5,0.5
  normalize $normParm combined.wav
  # create pre- left and right channels
  sox $soxParm -c 2 source.wav -c 1 sleft.wav mixer -l
  sox $soxParm -c 2 source.wav -c 1 sright.wav mixer -r
  sox $soxParm -M -c 1 -v -1 sright.wav -c 1 combined.wav -c 1 right.wav
  normalize $normParm right.wav
  sox $soxParm -M -c 1 -v -1 sleft.wav -c 1 combined.wav -c 1 left.wav
  normalize $normParm left.wav
  # frequency games
  sox $soxParm -c 1 left.wav -c 1 ls.wav sinc 100-6000 reverb
  sox $soxParm -c 1 right.wav -c 1 rs.wav sinc 100-6000 reverb
  sox $soxParm -c 1 combined.wav -c 1 c.wav sinc 80-12000
  sox $soxParm -c 1 combined.wav -c 1 lfe.wav sinc 20-200
  sox $soxParm -c 1 left.wav -c 1 lf.wav sinc 80-20000
  sox $soxParm -c 1 right.wav -c 1 rf.wav sinc 80-20000
  # normalize it in batch-mode
  normalize $normParm -b ls.wav rs.wav c.wav lfe.wav lf.wav rf.wav
  # let's mux it
  multimux -d 0,0,15,15,0,0 lf.wav rf.wav ls.wav rs.wav c.wav lfe.wav > $outFile
  # cleanup
  rm left.wav right.wav combined.wav source.wav sleft.wav sright.wav
fi

Hopefully useful links
You’re visiting those pages on your own risk. I took a look over them, but i can’t assure that those pages are “good”, “correct” or anything else.

• stereo to surround sound
• Doom9: GUIDE LIST: Stereo-to-Surround Conversion Guides
• Wikipedia: Stereophonic Sound
• Musichack Tutorials: center channel extraction/isolation
• OpenMovie: Sintel (I used their sound for testing)
• Wikipedia: Quadrophonie
• Wikipedia: Mehrkanal-Tonsystem
• How to isolate and save vocals from music tracks using audacity

The definition for fastcgi-server is unclear to me. Basically I understood it as “server-process” which is in my case a wrapper-script/php. Such a fastcgi server, can serve many requests and thus has child-processes.

Keeping this in mind and taking a look at IdleTimeout we’re talking about the time a fast-cgi-application was idle and so didn’t receive any request. The important part about this setting is, that starting a new fast-cgi-application takes more time. If a user visits your website and there is no fast-cgi-application running, he/she will have a little delay. Opening another page on your website will go fast. So, you’re dealing here between performance and resources. The earlier the process is terminated, the more resources you have available for other things. The later the process is terminated, the higher the chance to serve a user with no delay.

I’m not sure how to determine a good value for this setting. Probably taking a look at all logs and determining the average time between initial requests could be used. For example: If you’re receiving new requests all 10 minutes, a setting of 11 minutes might make more sense than a setting of 5 minutes. If you’re receiving new requests every minute an even shorter value _might_ make sense. The default value for IdleTimeout is 300 seconds, which means 5 minutes. It just depends a lot on the scenario. For example: A page with high traffic and lots of visitors might want to higher idletimeout and other timeouts to make sure that the server doesn’t have to start thousands of new fast-cgi-applications/processes <- that might be end up in extreme slow downs. In another scenario, on a vserver with limited resources where you get visitors every 30 minutes you might want to limit the timeouts to save resources. So, it really depends on your use-case.

Also, another note about this: It might make sense to set max_execution time in php to 0 and just use the IdleTimeout Feature of the fast-cgi-server. One might think that the fast-cgi-stuff uses the cli, and due to that max_execution time would be 0 per default, my tests have shown that this is not true (at least not with mod_fcgid, php 5.2 and ispcp). So - The max_execution time needs to be highered to match the IdleTimeout.

Now there's also BusyTimeout which is there to define how long a single-request can keep a fast-cgi-application busy. That’s by the way where my confusion starts. The documentation says it terminates the process. Which one? The child process or the server one? Of course it wouldn’t make much sense to terminate the whole fast-cgi-application because of a single-request (if that application has child processes or is able to handle many requests simultanously) – But how could I know? It’s not documentated. Let’s assume, this defines the maximum time a single-request (child process) can run. In this case, if your fast-cgi-application is PHP the same or a similar value to your php.ini’s max_execution time would make sense. Example: The default max_execution_time of PHP is 30 seconds. The default BusyTimeout of fcgid is 300 seconds. Thus a single-request is always finished or “over” after 30 seconds. Doesn’t make much sense to allow 300 seconds then – In this case 31 or 32 would be a good value. BusyScanInterval is similar. That setting scans processes every 120 seconds, while our PHP script is already finished after 30 seconds – It will never each BusyTimeout or BusyScanInterval.

Personally I think max_execution time of 30 seconds is not enough for a php-script, Sven’s opinion is different here: Uploading large files through PHP is inefficient (which is true) and then 30 seconds is of course enough for a normal website. Uploads should be handled by the webserver directly. A good value for Busy* should match the runtime of your fast-cgi-server, in case of php’s default value, 30 seconds. With a check every 14 seconds.

You could tune max_execution time by the way, by taking a look at your max upload size. Let’s assume that the average user of your website (who is allowed to upload) got a 3mbit/s connection:

100 mbit/s = 11 MB/s (yeah ppl argue, might be 10, might be 12)
1 mbit/s = 11 / 100 = 0.11 MB/s
3 mbit/s = 0.33 MB/s

In 30 seconds you can upload 0.33*30 MB with a 3mbit/s connection. That’d be 9.9 MB. Keeping this in mind, it might make no sense to define a max upload size of 100 MB – As your users can’t reach that within 30 seconds (except they’ve got a quite good connection). However, look at this calculation sceptical – It should just give an idea on how to tune your parameters.

And finally there’s ProcessLifeTime which is meant to terminate the whole fast-cgi-application regardless of whether it is busy or idle. This is a good thing to avoid having processes eating up all memory and similar things, because the application will be “refreshed” each x minutes. That means, ProcessLifeTime should be a multiple of IdleTimeout.

Apart from BusyScanInterval there’s also IdleScanInterval. Basically you can choose how frequently to “check” the specific process for, whether it is idle or busy. The more frequently you check, the more accurate the decission might be. Per default it’s about two checks. The checks should be smaller than the amount of their parent setting. For example: BusyTimeout of 30 and BusyScanInterval 60 makes no sense. Minimum value would be 29. If you want to check twice in it’s run-time you’d set 29/2 = 14 (rounded down) – The first check happens after 14 seconds, the second check happens after 28 seconds. So basically: (*TimeoutValue – 1) / AmountOfChecks = Interval

Then there is ErrorScanInterval and ZombieScanInterval. You can choose between scanning very frequently (might eat resources/slow things down) and terminating processes faster (which might free resources earlier and give faster-responses on errors). I think a good value is between 3 and 9 seconds.

One of the most interesting settings is DefaultMinClassProcessCount with a default value of 3. Which avoids the termination of idle-processes in some circumstances. It will kill only idle-processes if there are more than 3. Which is again confusing, are processes of a fast-cgi-application or all fast-cgi-applications of the webserver meant? However, I assume, that a fast-cgi-application handles many requests which turn into child-processes and that such childs are meant with “processes”. Right after tuning IdleTimeout it makes sense to set this to 0 to always enforce the use of IdleTimeout.

And then there’s the trouble-causing (or more precisely the trouble-solving) setting PHP_Fix_Pathinfo_Enable. Usually you should set this to 1 only, if you got ;cgi.fix_pathinfo=1 in your php.ini. As you can see at the ; it’s commented in mine. Still it seems to be in-use. If I don’t use PHP_Fix_Pathinfo_Enable 1″ for mod_fcgid – Some Uploads are broken. Uploading a picture with more than 100kb results in 500 HTTP Errors which aren’t tracked by PHP or Apache Error log. Might be some PHP, Debian or mod_fcgid bug. I cannot track this issue down (Maybe I don’t want to investigate more time :p)

Finally there’s MaxRequestsPerProcess. Okay.. Errm. Probably I should just forget about server, childs, parents, processes, requests, and all this crap (In this case, I guess they mean, how many “requests” a single-fast-cgi-server can handle).

Another problematic part is MaxRequestLen which was set to 1 GB with earlier versions and which is set to 128kB. According to the documentation, “only” the header is meant – Not the message/content itself. However, I noticed errors with that low amount and so I’ve set MaxRequestLen to exactly the same value, people are allowed to upload in PHP. So if your max upload size in PHP is 10 MB, set MaxRequestLen to 10*1024*1024 (10 * 1024 * 1024) which would be 10485760 bytes.

There are a few other parameters which might be worth to look at, however – The above stuff is enough for me to tune.

A few further links. I’ve checked them and couldn’t find anything bad on those pages, however, I cannot give any guarantee for that – So click the links below on your own risk (you’re leaving this page by clicking such a link)

• large attachement error (500)
• some page with the default settings explained
• Apache mod_fcgid

And thanks to Sven for helping a bit

Hab auch zwei neue Bücher eingetragen, Rothammel’s Antennenbuch (super erklärt, leicht verständlich, aber ein Klopper…) und “Lehrbuch der Hochfrequenztechnik” von Otto Zinke (leider ein wenig komplizierter, ich muss mir da noch ein wenig die Grundlagen beibringen)

Ich glaub ich sollte mir mal eine Liste zusammenstellen mit Büchern die ich mir noch holen will und Bücher die mir empfohlen wurden…

Want to jump directly to the result and skip the boring php examples?

detecting mime-encoded-words

According to RFC (2047) a mime-encoded-word needs to fulfill these rules (I hope I haven’t forgotten or misinterpreted one):

A mime-encoded-word

• starts with =? and ends with ?=
• consists of a maximum (=?…?=) of 75 characters
• has four (4) question marks (=?..?..?..?=)
• consists of charset, encoding and the encoded word (=?charset?encoding?encodedword?=)

also:

• the charset can contain everything EXCEPT controls ” ()<>@,;:/[]?.=”
• the encoding can contain everything EXCEPT controls ” ()<>@,;:/[]?.=”
• the encoded-word can contain any printable ASCII character EXCEPT ” ?”

So… If we put that into an “exact” (php-)regexp, step by step, we’d start with:

    $token = '[^ \(\)<>@,;:\/\[\]\?\.=]+';

That would cover whitespaces and the special characters above. ascii-controls goes from 0 to 31 and 127 is also a control character. Printable characters are 32 to (including) 126. Doing this in regexp is (might) be somewhat more difficult, there are several ways to achieve what we want. For example p{Cc} might do what we want. [:cntrl:] also. [\x00-\x1F\x7F] this one of course also. I’m prefering the last one for this:

    \x00-\x1F\x7F

Putting that into our $token regexp would look like that:

    $token = '[^ \(\)<>@,;:\/\[\]\?\.=\x00-\x1F\x7F]+';

We’ll use $token for charset and encoding. Thus let’s take a look at “encoded-word”:

    $encword = '[\x21-\x3E\x40-\x7E]+';

You might wonder where i got x21 and x3E etc from and what they mean. I’d suggest you to read this link at wikipedia Take a look at “Hex” in the tables. The “-” between \x21 and \x3E is used as “range” (from to).

Alright. Now let’s form our basic regexp. I’m using _ as delimiter:

    $regexp = "_=\?$token\?$token\?$encword\?=_";

without variables:

    $regexp = '_=\?[^ \(\)<>@,;:\/\[\]\?\.=\x00-\x1F\x7F]+\?[^ \(\)<>@,;:\/\[\]\?\.=\x00-\x1F\x7F]+\?[\x21-\x3E\x40-\x7E]+\?=_';

understood why I use variables to build the regexp? However. The regexp isn’t finished yet. We need to make sure that it’s at maximum 75 chars long:

    $regexp = "_(=\?$token\?$token\?$encword\?=){1,75}_";

The above regexp is made to be used with preg_match_all. With preg_match in a foreach (prior splitting of the content by spaces) you’d add ^ at the beginning and $ at the end of the regexp.

However, let’s go back to my test. For my test I use the following regexp:

     // notice, this one is wrong!
     $regexA = '=\?[^ \(\)\<\>\@\,\;\:\/\[\]\?\.\=\x00-\x1F\x7F]+\?[^ \(\)\<\>\@\,\;\:\/\[\]\?\.\=\x00-\x1F\x7F]+\?[\x20-\x7E^ \?]+\?=';
     // notice, this one is not very accurate and uses subpattern ()
     $regexB = '=\?(.*)\?(.*)\?(.*)\?=';
     // notice, this one is not very accurate, _not_ using subpattern
     $regexC = '=\?.*\?.*\?.*\?=';
     // notice, needs modifier U and might not be very accurate
     $regexD = '=\?[[:ascii:]]+\?[[:ascii:]]+\?[[:ascii:]]+\?=';
     // this should be the correct and most accurate regexp
     $regexE = '=\?[^ \(\)<>@,;:\/\[\]\?\.=\x00-\x1F\x7F]+\?[^ \(\)<>@,;:\/\[\]\?\.=\x00-\x1F\x7F]+\?[\x21-\x3E\x40-\x7E]+\?=';

The string used for testing is:

     $test = 'From: =?US-ASCII?Q?Keith_Moore?= 
   To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= 
   CC: =?ISO-8859-1?Q?Andr=E9?= Pirard 
   Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=';

As you can see, we should get 5 results per regexp. My testscript:

	ob_implicit_flush();

	$input = 'From: =?US-ASCII?Q?Keith_Moore?= 
   To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= 
   CC: =?ISO-8859-1?Q?Andr=E9?= Pirard 
   Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=';

     // notice, this one is wrong!
     $regexps[0] = '_=\?[^ \(\)\<\>\@\,\;\:\/\[\]\?\.\=\x00-\x1F\x7F]+\?[^ \(\)\<\>\@\,\;\:\/\[\]\?\.\=\x00-\x1F\x7F]+\?[\x20-\x7E^ \?]+\?=_';
     // notice, this one is not very accurate and uses subpattern ()
     $regexps[1] = '_=\?(.*)\?(.*)\?(.*)\?=_';
     // notice, this one is not very accurate, _not_ using subpattern
     $regexps[2] = '_=\?.*\?.*\?.*\?=_';
     // notice, needs modifier U and might not be very accurate
     $regexps[3] = '_=\?[[:ascii:]]+\?[[:ascii:]]+\?[[:ascii:]]+\?=_U';
     // this should be the correct and most accurate regexp
     $regexps[4] = '_=\?[^ \(\)<>@,;:\/\[\]\?\.=\x00-\x1F\x7F]+\?[^ \(\)<>@,;:\/\[\]\?\.=\x00-\x1F\x7F]+\?[\x21-\x3E\x40-\x7E]+\?=_';

	$i = 0;
	foreach($regexps as $regexp)
	{

		echo "Test: #$i\n";
		echo "Run:\n";
		$teststart[$i] = microtime(true);
		for($run = 0; $run < 100000; $run++)
		{
			echo $run;
			$runstart[$i] = microtime(true);
			preg_match_all($regexp, $input, $matches);
			$runcount[$i] = $runcount[$i] + sizeof($matches[0]);
			$runstop[$i] = microtime(true);
			$rundiff[$i] = $rundiff[$i] + ($runstop[$i] - $runstart[$i]);
		}
		$teststop[$i] = microtime(true);
		$testdiff[$i] = $teststop[$i] - $teststart[$i];
		$i++;

	}

	echo "testno, testduration, testcount, testmicrotime, testseconds\n";
	for($i = 0; $i < count($regexps); $i++)
	{
		$runmilliseconds = $rundiff[$i] / 1000;
		echo $i.' '.$testdiff[$i].' '.$runcount[$i].' '.$rundiff[$i].' '.$runmilliseconds."\n";
	}

The Result?

As to be expected 100 000 runs:

Conclusion?

You can see, that all regexp matches (count of 500 000 - we have 100 000 runs and 5 matches - do the maths, luke!). You can also see, that the slowest regex uses (.*). The regex using .* is a bit faster, which shows that the slowness is not caused by the subpattern (). The last regex, is the fastest (and also the most accurate one) - interesting, isn't it?

For my tests I used debian lenny’s PHP 5.2.6 (in debian squeeze) using CLI. All tests have been averaged (the first test-case 1000 runs, the second test-case 10 000 runs). If you want to skip the “how I did it” and just want to read my conclusion, click this link

Notice: The regexp used here for detecting mime-encoded-words is not 100% correct; if you’re looking for a correct variant, take a look at my next article here.

1st test-case (mime-encoded-words)

For my test case I’m using mime-encoded-words – a few thousand of them:

	$mew = "";
	$word = "=?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= =?US-ASCII?Q?Keith_Moore?=";
	for($i = 0; $i < 80000; $i++)
		$mew .= $word." ";
	$tw = trim($mew);

Now after generating that list, we can start our time-measurements using microtime();

	$start = microtime(true); 

I'm processing that list in a foreach, by exploding our wordlist using a whitespace as delimiter:

	foreach($elements as $element)
	{
		if(
			(substr($element, 0, 2) == '=?') &&
			(substr($element, -2) == '?=') &&
			(substr_count($element, '?') == 4)
		){
			$reAcount++;
		}
	}
	$stop = microtime(true);
	$testcaseA = ($stop - $start)

within that foreach we'll need the str* stuff

		if(
			(substr($element, 0, 2) == '=?') &&
			(substr($element, -2) == '?=') &&
			(substr_count($element, '?') == 4)
		){
			$reAcount++;
		}

Let's calculate the time:

	$stop = microtime(true);
	$testcaseA = ($stop - $start);

Let's do the same with preg now. The content of the foreach:

		if(preg_match('/^=\?(.*)\?(.*)\?(.*)\?=$/is', $element))
		{
			$reBcount++;
		}

Someone might say, my regexp isn't very good and the use of (.*) is causing all this stuff.. Here you go:

	$token = '[^ \?]';
	$especials = '[^ \(\)\<\>\@\,\;\:\/\[\]\.\?\=]';

content of foreach:

		if(preg_match('/^=\?'.$token.'*\?'.$token.'*\?'.$especials.'*\?=$/is', $element))
		{
			$reDcount++;
		}

last but not least there's also preg_match_all. With it we can avoid the foreach:

	$start = microtime(true);
	preg_match_all('/=\?(.*)\?(.*)\?(.*)\?=/U', $tw, $matches);
	$reCcount = sizeof($matches[0]);
	$stop = microtime(true);
	$testcaseC = ($stop - $start);

The averaged result of 1000 test runs is:

preg_match #1 means (.*) was used
preg_match #2 means [^ ...]* was used
preg_match_all #1 and #2 as above.

Conclusion?

First of all, this test-case is not ideal; I'm using the same mime-encoded-words (3 different ones) and there's apart from the mime-encoded words nothing else in the string. This test-case is still useful tho, because you can see the similarities between the results. Interesting is for example that using [^ ..]* in the regexp is faster than using (.*) and using preg_match_all is as fast as str*. However: As you can see in the results, we're talking about microseconds, it's not like you would notice a difference between 0,0004 and 0,0018, would you? If we put it together: str* is slightly faster than a proper preg_match_all which is slightly faster than a proper preg_match - a general preg_match using (.*) is the slowest approach. I guess preg_match is slower than preg_match_all in this case, due to overhead from using foreach.

2nd test-case (mime-encoded-words out of rfc 2047)

My 2nd test-case parses the whole text of rfc 2047 - I just downloaded the .txt and wrote the following in the top of my php script:

	$mew = trim(str_replace(array('(', ')', '"', '\r\n', '\n', '\0', '\t'), '', implode('', file('rfc2047.txt'))));
	$tw = preg_replace('_\s+_', ' ', $mew);

So basically, I'm just removing a few characters, newlines, tabs ( I know unlikely that \0 and \t will be there.. ) and I converted many spaces to one space. Processing that with my previous script shows the following result:

Conclusion?

Well. I'm a bit confused and impressed myself. Because I expected str* to be faster here. The opposite is the case. While doing this test I noticed inacurate behaviour of preg*, thus preg_match got 25 as count where it should get 22. I wasn't able to find out what's causing that; however: regexp might be inaccurate and shouldn't be generalized using (.*) if it's possible, avoid (.*). A proper regex and preg_match_all is faster here than str* still str* is faster than a regexp using (.*).

3rd test-case (parsing a log-file / getting the date)

For one of my projects I wrote a log-parser, the first version of it was using a lot of regexp and it was damn slow. I'm not sure whether this was due to the use of regexp (I rewrote the whole thing recently and switched from using preg* to non-regexp - Let's take a look. I'm using a real mail log file:

wdp@lunar ~ $ du -h mail.txt
2.2M    mail.txt

And the following regexp to get the date (1000 runs):

preg_match('/^([A-Za-z]{3}) ([0-9]{1,2}) ([0-9]{1,2}):([0-9]{1,2}):([0-9]{1,2}) (.*)$/', $logentry, $matches);

For the non-regexp variant I'm using substr, str*, explode.

The result is:

Conclusion

again, not much difference between both variants, however in this case, regexp are faster.

Overall conclusion

The performance of regexp depends on the regexp itself. I noticed that (.*) is slower than for example [^ \?]* or [A-Za-z0-9]. So the general rule should be: try to write your regexp as exact as possible. Generally regexp seems to be slightly slower than str* and similar things. In some scenarios regexp MIGHT be faster. The general rule "try to avoid regexp whenever possible" is wrong, tho. However: Using regexp you might make things worse (in some cases, they might be slower and they might be inaccurate) keeping that in mind, there's some sense in "try to avoid them"