Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
1 page
--
--
List results:
Search options:
Use \ before commas in usernames
Encoding notes:

* DooM runs internally at 35 fps. The runs are at 30, so every 6 frames the video will miss a "tic". This creates the same "bad" feeling as the Zelda  runs (game=20fps, video=30fps). I understand that with video capture this might be rather difficult to fix (if the "framerate gaps" don't remain constant), but while I don't know what do you use to capture DooM runs, I would suppose getting perfectly smooth 35 fps is possible.

* It seems the policy on open sourced games is to keep as close to the original as possible, but I'm just making sure you're aware there are community created high resolution texture packs for both DooM and Quake, amongst other assets, which improve quality dramatically.

<rant>

What's the mania with the audio sample rate? It's atrocious that stereo low quality runs have 128kbit video and 64kbit audio.

I know, psicologically, people hate to go down from 22050hz to 11025, just as they hate going from stereo to mono. This is the same reason people hate LAME for not allowing 44Khz@96kbit, and who glee in extasy when they discover you can force 44Khz stereo @ 32kbit.

I have news for you: the reason the codec doesn't want 22500hz at less that 64kbit is because the lowpass filter is falling already under 5Khz or so, and using a lower frequency will improve efficiency because the subbands in the filterbank will be better used.

Now, for a traumatic experience: when encoding 44100hz audio @ 128kbit, said filter is usually on the 16Khz-s, hence the effective sampling rate is already around 32000hz. Something similar is already happening with 22050hz @ 64kbit. You can check this with a spectometer.

In other words: don't be shy to cut to 11025hz, and from stereo to mono (this is a different issue but it makes a lot of impact at lower bitrates). I'd rather much have 11025hz mono @ 24kbit with 170kbit video than 64/128.

This doesn't apply to the DooM run as it's mono and therefore 32Kbit, and it's not like I get a lot of low quality runs, but anyway...

</rant>

Now, on to the interesting stuff:

The moment I saw the run I thought it'd be interesting to see both players at once. This is rather easy to do with a simple avisynth script:

StackHorizontal(AVISource("Doom2_SS_UV_2p_a_2227_LQ.avi"),AVISource("Doom2_SS_UV_2p_b_2227_LQ.avi"))

For example. It's rather cool and they match up more or less; in the end they desynch a second or two.
Thread title:  
(If the audio thing wasn't clear, a rather valid analogy would be that the sampling rate is equivalent to the resolution in video. Surely you don't want 640x480@128kbit, so you have to lower the resolution, since it's the best way to achieve lower bitrates - otherwise you would get all blocks - which is horrible metallic sound in MP3)
Heretic and Doom fan
I am made these Doom2 Coop AVIs.

I know about the choppyness, fraps induces it somehow. I tried recording 35 fps with fraps but it doesnt change much.

About the sound issues you talk about I used :
- LQ : 32kb mono
- MQ : 64kb stereo
- HQ : 128kb stereo

now I am using 96kb for HQ, since I dont see a difference. Let me know what you would suggest, as I feel that doom sounds are not so affected by low bitrates.

for the FPS/choppiness issue, I have been using a new doom port that interpolates frames and creates motionblur. the result is much smooth animation.
There are some torrents for Final Doom's Plutonia in  these forums, get the MQ one if you can.
I finally watched Final_Doom_Plutonia_UV_4111_HQ.avi, and I like it a lot Smiley I thought that 35Hz looking exactly like the original would be best, but now I don't know Smiley

However, perhaps such smoothness makes the run look too different to the original? Too easy, perhaps? (things appearing easier to dodge, etc...)

About the sound, the one from your encoding was OK, I was complaining mostly about other runs. IIRC DooM had 11KHz sound so 96Kbit should be more than enough; I don't even know if with modern ports it's useful to use 22KHz or 44KHz. Perhaps for the LQ run using 11KHz/stereo would be better than 22KHz/mono, but I don't know if it'll sound good @ 32Kbit.

Just out of curiosity, how does this port do graphics? It looks like software rendering with some smoothing, but it has alpha transparency...
ZZT &gt; *
I know that COMPET-N requires all runs to be done on the original game, but those videos don't look like they're from original DooM ][. The textures on rising platforms don't scroll out of the floor, and the plasma rifle balls look semitransparent. What source port was used to do the avi recording?

I'm not accusing anyone of cheating here, BTW. I'd expect that the legit LMPs from the speedrunners were loaded into a different version of DooM ][ to make capturing easier. I'm just curious what version it was.
Edit history:
vincedss: 2006-04-26 12:41:03 am
Heretic and Doom fan
The original demos were recorded with the original DOS games. They are current Compet-N records, so they are legit.

In this case I used fancy doom ports to playback the demo and record it into AVI.

Btw, about doom audio, I lowered the bitrates abit.

LQ = 11025 Khz  16Kb/s mono
MQ = 11025 Khz  40Kb/s stereo
HQ = 22050 Khz  80Kb/s stereo

The LQ sounds a little metallic sometimes but it's kinda acceptable. And allows me to get an extra +16kb/s for DivX, which is very important ^^
ZZT &gt; *
Just as I suspected. Which port was used?
Heretic and Doom fan
I used glboom for 2 reasons :
- it's compatible with demos LMP recorded with original engine (doom2.exe)
- it has openGL support, necessary for FRAPS (in software fraps lags like hell) and also I get trilinear filtering, antialiasing...