Jam Enslaver Plays...Shadow of the Colossus Episode 01

Hello again! I'm very excited to start my new video series in which I will be playing Team Ico's masterpiece Shadow of the Colossus. I'll be posting all the episodes here as they go live (I'm hoping to get the next one up early next week since I'm in New York right now!)

Since they will all be using a very similar recording setup I might not have much new to say about each one for this blog, but here are a couple of interesting notes about getting everything organised for a different style of video. See you next time!

Recording Setup

This was a slightly more complex recording setup than usual simply because I was going to be recording the game footage and myself talking at the same time. I wanted to avoid using multiple computers as the area I use for making my videos is pretty small; even a laptop would have to sit on the floor if I wanted to use it for recording the voice-over. I also wanted to use my headset mic rather than the Snowball. The audio quality is much better with the Snowball but when I'm recording the voice-over for my reviews I tend to hold it in my hand because the stand is quite small so the mic sits low on the desk. Whilst it picks up my voice perfectly well like that there is a lot of echo, so I hold it directly in front of my mouth. When I've got a controller in my hand and need to see the screen in front of me that doesn't really work!

Recording the video footage wasn't a problem: I have a Roxio Gamecapture HD Pro that I first used for my Beatles: Rock Band review, I just needed to get a PS3 component cable to use with it since there's no way of recording the HDMI output of the PS3 because of its always-on HDCP. The Roxio then plugged by USB into my computer to record the footage, and via HDMI into the TV so I could play the game without any input delay (see below).

This posed the question: how do I set things up so that I can hear the game audio as I'm playing? The footage being piped into the PC by the Roxio is about 1 second behind what's actually happening in the game, which is why it's good that the Roxio also delivers a pass-through feed. The monitor I was using doesn't have built-in speakers (which I wouldn't want to use anyway to avoid the sound bleeding into my headset mic) but does have a 3.5mm audio jack*. So, I could just get an extension cable and run another pair of headphones into the back of the display.

 *I actually wasn't previously aware of this jack and was very glad to discover it; I usually play PS4 games on that monitor so for audio I always plug my headset into the controller itself.

Detecting Crashes

As I mentioned in my post on my 3D Movie Maker review, my computer has been having some troubles recently. Seemingly at random it would just shut off and need a hard reset. Since it tended to happen when I was playing a game I suspected that it had something to do with overheating. I was worried that it might also happen whilst I was recording the video footage I needed, since this is a very CPU-intensive thing to do.

One of the things I was particularly worried about regarding my computer crashing was not noticing when it happened. When the computer shuts itself down in this way the screen goes black but the fans keep running (another strong indicator that this issue is heat-related). Since I would be playing the game whilst watching the pass-through video feed, I wouldn't be able to tell that the computer had crashed and stopped recording until I switched back to it when I had finished. This is especially bad for a game like Shadow of the Colossus which offers no manual save functionality: if I played past one of the points where the game saves automatically, I wouldn't be able to go back and play the same sequence again if I lost the footage!

I needed some proof-of-life indicator for the PC. Unfortunately the Roxio doesn't seem to need the computer to be on for the pass-through to work, it just needs power going to the USB port it's plugged in to. So even if the computer died, the footage I was seeing of the game would be uninterrupted. Then I thought about audio, and a way of killing two birds with one stone.

As I mentioned above, I was getting gameplay audio for myself from an audio jack on the back of the monitor. This had always seemed like an inelegant solution since it would require me to wear a second set of headphones. Luckily, I had recently discovered what the line-in port does on the back of a computer whilst playing around with ways to record footage from Android devices (some ideas brewing there, watch this space). I had often wondered what that blue jack was next to the more familiar green (audio out) and pink (mic input), but never bothered to find out. Only now do I discover that it has the amazingly useful ability to take input from any device that plays audio! And this gave me an idea...

I used the extension cable I had been expecting to run from the monitor to a set of headphones and used it to run the audio output back into the computer. Then it was just a case of turning on the listen function for the audio input and I was able to hear the non-delayed game audio through the same headset I was using to record my voice as I played the game! Not only that, but if the computer died the line-in audio would go silent and I would immediately know that something had gone wrong.

Recovering from Crashes

To test this new crash-detection system I decided to do a practice run playing Uncharted, which I've been playing in my own time in anticipation of Uncharted 4 coming out this year. I didn't have to wait long; seven minutes into playing the game the audio went dead and I switched the input on the monitor to find that the PC had crashed.

Now I had a new problem: if the computer is going to crash sometimes whilst I'm playing, can I recover the footage and voice-over that was recording at the time? The gameplay footage recorded by the Roxio seemed to be fine, (not even the zero-length issue I had seen with Hypercam), except that it was an M2TS file which Sony Movie Maker doesn't support properly (for some reason it doesn't pick up the audio). Once again the solution was to re-render the file as an MP4, which is actually what Roxio does anyway when you finish recording properly.

A bigger issue was the voice-recording, which I always do using Audacity. I had hoped that I would be able to just re-open the application and it would do some kind of automatic recovery, which it tried to do before showing an error message. This had me very worried because I've seen Tweets from podcaster Travis McElroy complaining about having to reconstruct Audacity projects from hundreds of 6 second clips. I found the clips in question, buried in a temporary folder, and even found some instructions online for the best way of putting them back together by hand. Unfortunately, after doing this for a few minutes, I realised that the audio clips weren't in any sort of order in the folder, and short of listening to every single clip and trying to figure out where it belonged in the timeline, there was no way I was going to be able to reconstruct the entire file by hand.

I will be attempting to rebuild an episode of Baby Geniuses from 1200 recovered 6-second chunks. Go fuck yourself Audacity.

— Travis McElroy (@travismcelroy) February 21, 2016

Then I decided to do what I should have done to start with: find out if there was anything to do about the error message that Audacity had shown when it had tried to automatically reconstruct the file. It turns out this would have saved me a lot of time and worry, as the problem was pretty easy to solve. It turns out that if Audacity quits unexpectedly, it can sometimes print a line of garbage characters at the end of the automatic save file which keeps track of where all the audio clips belong. All I had to do was open the save file in a text editor and remove the broken characters. Hey presto, the audio recording was back!

Keeping Things Cool

Of course, the ideal situation would be if my computer didn't crash at all! Whilst it was annoying during the production of my 3D Movie Maker review it wasn't insurmountable; the nature of my reviews calls for short clips of the games I play, so if the recording happens to unexpectedly stop it doesn't matter as long as the file is still usable. However for a Let's Play where I need to record 30+ minutes of unbroken footage, it's a different matter! 

I knew that I would always be able to recover the recordings so I could just edit the clips together if I needed to, but if my maximum recording time was seven minutes I would have multiple breaks in each video and it wouldn't always be possible to disguise the transition. So I decided to try and find a way of actually fixing the problem, or at the very least figuring out a way of extending the recording time to something more like 30 minutes so I could rely on having at most one transition for a typical video.

My research online seemed to suggest that focusing on cooling was the right way to go, so I downloaded an application called HWInfo to check the temperatures of my CPU cores whilst doing different things (idling, running Roxio and Audacity simultaneously etc). From what I could tell they didn't seem to be particularly high (around 40 - 56°C depending on the load). I tried running the logger whilst I recorded Uncharted and was able to get the PC to crash again, but the results on the logger didn't seem abnormal, although I wasn't able to work out how close to the crash the logged data actually went. The only useful information I gleaned was that all four CPU cores were working at 100% during the recording.

Based on what I had read online I decided to poke around a bit in the BIOS of my computer to see if I could find any temperature settings. After a little digging I discovered some controls for regulating temperature, specifically controlling two schemas called TM1 and TM2 which reduce the amount of work the CPU does to prevent overheating. Both of these were turned off, presumably because when the computer was new it was bought from Alienware and they had dealt with heat management by having multiple different fans in the case rather than sacrificing performance. Turning TM1 and TM2 on seemed to help a bit and I was able to get a recording time closer to 15 minutes, but it still wasn't enough!

Next I paid attention to what exactly was causing the CPU to spike. Something strange I noticed is that Roxio caused all four CPUs to run at 100% for about 30 seconds when it first opened, and that the CPU usage actually dropped for a few seconds when I started recording. Then I noticed that if I had the Roxio window minimised CPU usage dropped to about 95%, presumably because the computer wasn't having to render the preview window. A small difference, but one that could potentially offset factors like running Audacity at the same time.

Since all my readings were showing temperatures in the mid 50s, I decided that maybe I should adjust the way the fans worked on my computer. When I first went into the BIOS I noticed that they were set up to reach full power when the temperature hit 65°C. Perhaps my aging CPU couldn't deal with that kind of temperature any more and should be allowed to spin up the fans to full power at a lower temperature? Working under the hypothesis that sustaining a temperature of 55°C for long periods was what was causing the trouble, I modified the fan settings to spin up to full power at 50°C and started recording again.

That seemed to do it. I was able to play through the remainder of Uncharted (about 45 minutes) without another crash. At some point I might take a look inside the computer to see if there's anything obviously wrong, but for now this fix seems to work.

Jam Enslaver Reviews...Microsoft 3D Movie Maker

I hope everyone enjoys my latest review. It took quite a lot of work to get it completed, so as promised here are some of the things I had to deal with during production for those who are interested. See you next time!

Recording in a VM

For most of my videos, the idea for which game I should review starts with the question "What can I record footage of?" and goes from there. This was not the case with 3D Movie Maker!

I got the idea to make a review of it whilst I was finishing my review of Body Harvest. There comes a point in each project, when I've finished playing the game and recording footage, and when the voiceover is in the can, where I finally have to start pulling all the pieces together into the final video. It's a daunting prospect, similar to what a writer faces when they have a blank page in front of them, and there'a always a part of my brain that wants to procrastinate by thinking of what my next video should be about.

I'm not sure what made me think of 3D Movie Maker as a potential next project, but I really liked the idea of using it as a way to talk about my growth as a creator of videos so I was determined to find a way of making it work. Unfortunately, the game doesn't seem to be compatible with Windows 10 so I had to find a work-around. Luckily I happened to already have a copy of Windows XP installed on my computer using VMWare (which is, surprisingly, free for personal use). The game ran in a window but otherwise was perfectly playable once I had fixed a strange issue that caused my mouse to unexpectedly zoom off the edge of the screen at random intervals (it turned out I had the mouse input mapped twice, so each movement was doubled).

With a working copy of the game, the next question was how to record footage. In past PC game reviews I've used FRAPS, but I didn't have high hopes for that working since it's very flakey and doesn't even seem to work for games that run in fullscreen, let alone one playing inside a window inside a VM!* It didn't take long to confirm my fears: As I suspected, FRAPS does not work with VMWare.

Forced to find an alternative, I stumbled upon a forum thread where someone recommended Hypercam. I've looked online for better alternatives to FRAPS before and have always been disappointed. Most screen recorders seem to be designed for video tutorials of productivity software, so they tend to only record at very low frame-rates and never record system sound. So I was amazed to discover that Hypercam did exactly what I needed: allowing me to record the exact part of the screen I wanted at a smooth frame rate and choose which audio inputs were used. This one tool has suddenly opened up a world of possibilities for things I can do in the future, including revisiting that Riven idea!

* People who recall my video series playing Myst might be interested to know that I was hoping to follow up with a series in which I played Riven: The Sequel to Myst, but because I just couldn't get FRAPS to work with it I abandoned that idea.

Computer Issues and Corrupted Files

Not everything went smoothly with my recording setup, though. My trusty Alienware PC is now getting on for 9 years old and has developed a rather alarming trait where it will randomly show a black screen and stop working, which happened numerous times whilst I was recording footage. Luckily all the files were intact despite having to hard reset the machine, but when I came to edit them I discovered that not all was well. I'm guessing that when one clicks the Stop Recording button in Hypercam it does some work to 'finalise' the video file, including things like writing the length of the video into the file. Because the computer was turned off without this final step being completed, the videos were showing up as having a length of zero seconds.

Initially this didn't seem to matter. If I opened them in a video player they would work fine, but if I tried to skip ahead it would be extremely slow. I'm guessing this is because without time information to work with, the computer would have to scan through each frame from the beginning of the video to find the one you had selected. Since editing videos requires constant skipping around inside video clips, this was a problem. The solution was to re-render each of the corrupted videos, (rendering goes frame-by-frame anyway so wasn't affected by the missing data) which took an extra couple of hours but meant that I didn't have to go back and re-record any of the footage.

Finishing the Movie

This was the first time I've been blocked on a video project for creative reasons. From the beginning I wanted to make a complete movie in 3D Movie Maker as part of the review process, and then to publish it to YouTube to accompany the review as a demonstration of what the game can do. The problem is that I'm not much of a story-teller, and I spent ages trying to figure out how the story of the bank robbery should end.

Originally the two police officers were going to follow a trail of clues through a number different scenes, eventually ending up at the villain's hideout for a final showdown. I couldn't figure out what even one of those accidentally left behind clues should be, before hitting on the idea that perhaps they were left on purpose. So I started imagining that the police were lured to a location by a treasure map for some nefarious purpose. Then I couldn't think of why a bank robber would do that, until the idea of a surprise birthday party hit me as the perfectly ridiculous way to end the story.

Late Script Changes

Speaking of changing the story, I actually ended up modifying the script for the review whilst I was in the editing phase, several weeks after I had recorded my voiceover. Originally the script talked about my surprise that Movie Maker's McZee is voiced by the same person who plays Barney in the Half Life series, and I had planned on finding the scene in Half Life 2 where he first reveals himself to the player to put alongside the footage of McZee speaking.

I knew that the same actor played the G-Man, but Barney is one of my favourite characters so it seemed like the obvious choice. However, when I started playing Half Life 2 to record the footage I was immediately struck by the iconic, incredibly creepy monologue that the G-Man gives at the very start of the game, which I had somehow completely forgotten about. The juxtaposition between the two performances seemed too good to ignore, so I changed the script to mention the G-Man instead of Barney.

I usually avoid doing this for the simple reason that a re-recorded line of dialogue tends to sound different from the rest of the voiceover and can be very jarring for the viewer. Your voice can sound different on different days, and when I used to record using a headset mic the audio would vary wildly if I didn't get the positioning exactly the same between the two recordings. Luckily my new Blue Snowball mic didn't seem to have this problem, and the updated line slotted into the rest of the recording seamlessly.

The change ended up working really well as it allowed me to do something even more interesting in contrasting the two characters together in the video!

What's Next?

As I mentioned at the top of this post, I'm always thinking of what comes next for my videos. I've been tinkering with my recording setup for the last couple of days and am now able to record footage for my next project. I'm looking forward to making this one because it's going to be a little departure from what I've been doing recently: a new installment of Jam Enslaver Plays...

Look for it soon on my YouTube channel!