I am now working on a 2-stroke and am using the same process that I used for the other two sound profiles, but the end result just sounds bad and is is completely unsatisfactory to me.
When you (KE) made your 2-stroke sound profiles, were they inherently more difficult to make a good one versus the 4-strokes?
I have tried 4 different attempts. With just actual recordings on some, and with software enhanced recordings on others (where you use the program to change speed for an intermediate rpm file). The best version so far has been with pure recordings only. It also seems to be best with less intermediate files than more.
I have made all my clips as close to 7 seconds as possible. I have made the intermediate steps as close to 25% as possible. But it is just not working out, unlike the 4-stroke sounds did.
Any advice?
I saw your other thread about the new engine, which I'll get into below. But to address some specific things you asked here:
I don't expect a 2-stroke engine to be significantly more difficult to capture and put in the sim than a 4-stroke. Whatever is contributing to the problems you're experiencing must have another cause.
We do not recommend artificially adjusting the pitch of your samples. The quality will suffer as a result. You should record as many different RPMs as you need to fill out the sound profile, instead of reusing samples from different parts of the RPM range and altering them to fit your needs.
The ideal number of different samples to use will vary depending on several factors, but particularly the size of the RPM range you're recording (how far apart are the min & max RPM?). Because of the way the individual engine sound samples are crossfaded, each sample will be stretched to reach the nearest sample above and below it.
So if you use too few samples, they will be stretched too far in order to cover all the RPM values in between, and your sound profile will sound bad. For example, let's say you only have 1000.ogg and 11000.ogg and nothing in between them. The 1000.ogg will be used for everything up to 11,000 RPM (albeit very quietly as it approaches that value), and it will be sped
way up in order to do it. In the same way, the 11000.ogg sample will be slowed
way down and mixed in with the lower sample for RPM values all the way down to 1,000. This would sound absolutely terrible. It's too much to ask of a sample to sound good at even double its original sample rate, let alone 11 times!
On the other hand, too many samples (something like 1200, 1500, 1800, 2100, 2400, 2700, 3000, 3300, etc.) should also be avoided. As described above, each individual sample is used for the RPM range extending to each of the samples adjacent to it (although it is only audible for a subsection of that range, meaning its effective range is actually significantly smaller). So too many samples crowded together will cause each individual sample to barely be used at all. In the example above, you might really only hear each sample within about a 300 RPM range (150 on either side). That's not really going to improve the quality of your sound profile. Each sample should be given a little more room to breathe and do its job. On top of that, I suspect that getting the sample filenames to correctly match the engine RPM value they capture is the area where users will struggle the most. If those are off, then it will sound bad when RealFlight blends between the samples, and having more samples means that crossfading will happen more often. That is, if you haven't yet figured out how to make it sound good when two samples blend, it's only going to make things worse if that happens at 30 different points in your sound profile's RPM range.
So, it's important to find a good middle ground, but it's difficult to tell you exactly what that number should be, because there's no single right answer for all sound profiles.
I don't know what your sample filenames look like, but I think it's worth pointing out that this isn't a tidy business. It is of the utmost importance that you accurately name the samples based on the exact RPM values they represent. It would be very difficult to record an engine at exactly 1000, 2000, 3000, 4000, etc., however, so you can't expect your files to come out looking like that. As an example, here are the exact values for one of our stock sound profiles: 1779, 2439, 3057, 4006, 4980, 6150, 7080, & 8100.
Regarding sample length: In the real world, the engine sound never repeats exactly, even if you do detect a pattern to its thrum. Ideally, each RPM sample in the sim would have something like 10 whole minutes' worth of audio before looping, allowing it to sound incredibly natural and making it nearly impossible to detect the loop point. Obviously we can't actually do that, though.
Long samples are a problem for two reasons:
- File size - For stock profiles, that means space on the DVD and space on users' hard drives; for custom content, that means space on our server, space on the hard disk of anyone who downloads your content, plus our bandwidth and their time whenever someone downloads it. For multiple sound profiles, it all adds up.
- Consistency - As described in the original tutorial post, it is important for the engine pitch to vary as little as possible over the course of a single sample. Electrics make this considerably easier than glow/gas engines, which make it difficult to keep a precise, constant RPM for, say, 15 or 20 seconds.
Short samples have their own problems, too, of course. The shorter the sample, the more obvious to the listener that the sample is a loop. Further, if the loop points weren't chosen perfectly, meaning there are popping artifacts when it loops, or if there are other noticeable aspects such as an engine burble or a thud at a certain point in the sample, the listener will become painfully aware of them if they happen every 2 seconds. Even worse, these kinds of problems are magnified when the sample is sped up. As the pitch increases, the sample length shrinks, meaning your 3 second sample might only be 2 seconds long at higher RPMs. So if it sounds bad to begin with
and there is a large distance between this sample and the next highest one, it's a double whammy. (And if this is the highest sample in your profile? You're really in trouble.)
Therefore, as with so many things, it is necessary to find some kind of middle ground that maximizes the good and minimizes the bad. 7 seconds per sample is just a guideline.
It is worth mentioning that sample length is only important within the context of the individual sample. There is no reason to try making all the different samples in your profile match each other. If one sample is 4 seconds long and the next one is 15, that won't cause any problems that didn't already exist. If they sound bad, cutting the 15 second sample down to only 7 or 4 seconds won't help (unless by doing that you cut out whatever made it sound bad to begin with). By itself, the difference in length between the two will cause no problems whatsoever.
Now, about your
GMS 76: From just listening to a recording, and without any insight into the samples you're using, it's difficult to say exactly what's causing you problems here. In fact, without seeing your inputs, it's hard to even know what's going on. Are you blipping the throttle at times, or are those variations actually part of the samples you've created? It would probably help to have the radio gadget visible in the video. At any rate, I agree that what you've got so far doesn't accurately reflect the sound of your engine.
From what I was able to pick out, I'd say the biggest problem is that it sounds like the RPM values you've chosen for at least some of the samples do not accurately reflect the RPM they capture. For example, you might have a file labeled 3500.ogg in which the engine is actually turning 3791 RPM. I'm pretty sure I'm hearing a lot of problems at RPMs in between samples, where two different samples are being blended together, and the pitch of the engine in one sample does not match the pitch of the engine in the other. You can test this for yourself by using the throttle to move slowly through the RPM range, watching the RPM in the NavGuides, and paying attention to where that value falls compared to the sample values whenever you hear problems. For example, let's say for a few of your samples you have 2200.ogg, 2870.ogg, and 3142.ogg. Does the engine sound good around those values, and bad in between them?
As I mentioned above, I think getting those RPM values correct is probably going to be the hardest thing to get right for anyone trying to create their own custom sound profile. It is also one of the most important pieces of the puzzle. I suggest focusing on that part and seeing how far you can get.
Ryan, will there be a discreet way to upload a custom engine sound profile to the swap pages in the future?
Tying them to the existing _EA & _AV types, like we've done with other custom items like visual blades or batteries, simplifies things a whole lot in several ways (some of which aren't immediately obvious from a user's perspective). I don't expect the way that works to change.
I hope this helps!