I'm finally happy that I have a visualizer that can respond to my live guitar playing. It's been a dream to do that and G-Force is the first program that allows me to hook up a mic or jack in and play (guitar not legos) away.
Now I want to make a music video of what I'm doing. Most of the programs that I've found that will grab streaming video do a bad job of capturing all the fidelity of G-Force, capturing very few fps. But, I did find one program that seems to do the job of capturing the full fidelity of the video stream called Fraps 2.9. Here's what I got from Download.com
"In its current form, it performs many tasks, including benchmarking (see how many frames per second you're getting in a corner of your screen; perform custom benchmarks and measure the frame rate between any two points; save statistics to disk and use them for your own reviews and applications); screen capturing (take a screenshot with the press of one key, with no need to paste into a paint program every time you want to capture; your screen captures also are automatically named and time-stamped); and real-time video capturing (record audio and video while playing your favorite game at up to 1,024x768 resolution at 30 frames per second)"
Anyone have experience with Fraps or have a good alternative for capturing the FULL fidelity of both the video and audio of G-Force?
Filming G-Force
Moderators: BTT, andy55, b.dwall, juxtiphi
There are a couple of screen- capture programs available, all of which produce video in the .avi format. So, welcome to the world of large file sizes.
Camtasia has certainly been around the longest. I stopped at version 6 so I don’t know what improvements have been made in the later versions. Camtasia is nice because it gives you more control than the FRAP program. You can capture certain areas of your screen, which means you can control or match the aspect ratio of G-Force precisely. Camtasia has a built in editing program… very basic, but useful in editing chunks of material for later editing. And Camtasia has several conversion programs so that the original video footage can be rendered in different formats.
The problem with Camtasia is that it’s a power hog. It was never designed to capture the fluidity of images such as those generated by G-Force. When I use it, I have to find a compromise between the fluidity of the G-Force output, the size of the raster and the frame rate of the video format. It’s very easy to produce jerky, stuttering images with Camtasia.
The FRAP program mentioned above seems to be much more efficient in that regard. It does not have the options offered by Camtasia. I have been able to devise a method where I originally define the area of the screen I want captured, and then invoke FRAP-- which somehow knows I want only that area of the screen captured. For example, I’m currently working with an HD format of 1280 x 720. I can define that area precisely on the monitor with Camtasia and FRAP will record just that area. Don’t ask me how this works.
It’s rather amazing to stop and think about what you are asking. Remember, there is no parallel processing involved in these steps. First, you’re going to play a sound, and then you want GForce to analyze that sound and respond by producing a sequence of animated frames… at X frames per second (typically at 30). And then you want the same computer that is analyzing the sound and producing the imagery to capture those animated frames at a frame rate different from that used by GForce, and at a frame rate which can vary from 12 to 60 frames per second.
We want all of these steps to be instantaneous, without any perceivable delay, and in real time. As we all know, that is impossible. There will always be delay because these events are handled sequentially, not in parallel. No matter how large the computer’s engine, these processes will never be simultaneous. But we want them to appear so.
It’s a rather amazing trick of perception.
Ideally, if you want to achieve the best visual fidelity, you won’t ask the same computer that is generating the images to record them. Now you’re talking about an external recording device (and I don’t mean a video camera pointed at a monitor) of which there are several on the market, and they are not cheap.
I believe, for the sake of experimentation, you will be satisfied with the performance of the FRAP software. It is well worth the $37 dollars.
Camtasia has certainly been around the longest. I stopped at version 6 so I don’t know what improvements have been made in the later versions. Camtasia is nice because it gives you more control than the FRAP program. You can capture certain areas of your screen, which means you can control or match the aspect ratio of G-Force precisely. Camtasia has a built in editing program… very basic, but useful in editing chunks of material for later editing. And Camtasia has several conversion programs so that the original video footage can be rendered in different formats.
The problem with Camtasia is that it’s a power hog. It was never designed to capture the fluidity of images such as those generated by G-Force. When I use it, I have to find a compromise between the fluidity of the G-Force output, the size of the raster and the frame rate of the video format. It’s very easy to produce jerky, stuttering images with Camtasia.
The FRAP program mentioned above seems to be much more efficient in that regard. It does not have the options offered by Camtasia. I have been able to devise a method where I originally define the area of the screen I want captured, and then invoke FRAP-- which somehow knows I want only that area of the screen captured. For example, I’m currently working with an HD format of 1280 x 720. I can define that area precisely on the monitor with Camtasia and FRAP will record just that area. Don’t ask me how this works.
It’s rather amazing to stop and think about what you are asking. Remember, there is no parallel processing involved in these steps. First, you’re going to play a sound, and then you want GForce to analyze that sound and respond by producing a sequence of animated frames… at X frames per second (typically at 30). And then you want the same computer that is analyzing the sound and producing the imagery to capture those animated frames at a frame rate different from that used by GForce, and at a frame rate which can vary from 12 to 60 frames per second.
We want all of these steps to be instantaneous, without any perceivable delay, and in real time. As we all know, that is impossible. There will always be delay because these events are handled sequentially, not in parallel. No matter how large the computer’s engine, these processes will never be simultaneous. But we want them to appear so.
It’s a rather amazing trick of perception.
Ideally, if you want to achieve the best visual fidelity, you won’t ask the same computer that is generating the images to record them. Now you’re talking about an external recording device (and I don’t mean a video camera pointed at a monitor) of which there are several on the market, and they are not cheap.
I believe, for the sake of experimentation, you will be satisfied with the performance of the FRAP software. It is well worth the $37 dollars.
I spent quite a bit of time evaluating four video capture programs, Fraps, Plawclaw, Bandicam, and Dxtory, and how each interacted with GF captures. Take whatever I post here with a grain of salt, but I thought I would post some of my "personal" findings.
I was attempting to confirm the premise, that the implementation/utilization of Sprites have the largest negative impact on capture process. Although most other elements of GF processing seem to have a rather linear impact on the total performance, the initiation/interaction of Sprite processing is all over the map and unevenly handled. To complicate the whole issue, each capture program seems to impact the process to different degrees, in different ways. For example, Fraps' old 4G file size limitation was sure to cause a stumble upon closing/opening a new file... (and which the only way I found to seamlessly merge the Fraps' output, was using VirtualDub... a time consuming, redundant operation).
To minimize GF's required effort, I first moved the Sprites to an external folder onto a Virtual ram drive (Qsoft)... which seemed to have the most beneficial effect on my OLD underpowered dual core XP machine. Next, I converted all the images to 256 B&W and resized to fullscreen dimensions (ImageMagick). Although I feel both of these moves helped things in general, I feel they did little in the way of GF impact, and interaction with the video capture program.
To help me understand the dynamic load implications I wrote the following
edit to end of: ...\Scripts\Startup.txt:
debug script ...\Scripts\Sprites.txt:
The 'Sprites.txt' script is actually a stripped down version of my original, which disabled the Sprite slideshow, and attempted to fire off a 'StartRamdomSprite();' when the Load dropped below 'some' threshold. It didn't really work very well as GF and the Video Capturing program would use each's own strategy to accomplish frame rate stabilization. And of course, you could (rightfully) argue that the script itself impacted the entire process. THIS version does help you understand 'relative' impact however, and you can use it to understand YOUR situation (maybe). I have Sprite shuffle/duration set to ~30 secs, and for SOME reason (on my Win7/64) NEED to have the toolbar startup with GF (however, you can close it, once the script gets going). The actual process of CAPTURING (as opposed to just viewing the Video Capture Programs benchmarking stats), is the INSIGHTFUL exercise ... well I am tired of typing now... more later... maybe
I was attempting to confirm the premise, that the implementation/utilization of Sprites have the largest negative impact on capture process. Although most other elements of GF processing seem to have a rather linear impact on the total performance, the initiation/interaction of Sprite processing is all over the map and unevenly handled. To complicate the whole issue, each capture program seems to impact the process to different degrees, in different ways. For example, Fraps' old 4G file size limitation was sure to cause a stumble upon closing/opening a new file... (and which the only way I found to seamlessly merge the Fraps' output, was using VirtualDub... a time consuming, redundant operation).
To minimize GF's required effort, I first moved the Sprites to an external folder onto a Virtual ram drive (Qsoft)... which seemed to have the most beneficial effect on my OLD underpowered dual core XP machine. Next, I converted all the images to 256 B&W and resized to fullscreen dimensions (ImageMagick). Although I feel both of these moves helped things in general, I feel they did little in the way of GF impact, and interaction with the video capture program.
To help me understand the dynamic load implications I wrote the following
edit to end of: ...\Scripts\Startup.txt:
Code: Select all
Run( "Sprites.txt" );
Code: Select all
// 08Jun2012 jrm
if( GetCurrentSprites()== "" )
{ print("-> Load: ");
} else
{ printf(" %s: ", GetCurrentSprites());
}
printf("%d %d [%d]\n", GetCurrentLoadMS(), GetRecommendedSleepMS(), GetCurrentFPS());
00:02
Run( "Sprites.txt" ); // Only if Toolbar startup!?! ... but can close Toolbar after things startup!?