The high pitched sqeaulingm drop out and delay thing is a buffering bug, because it needs to be dynamic for lots of sources - once they properly fix it, we may get lots of sources.
Video games as a whole aren't into a "mature" space to start with, but recording cars for use in video games is exceptionally rare. There's maybe a total of 50 people on the planet who have done so as a profession. Recording in and of itself is a very artistic process as well - just putting a microphone in front of a thing doesn't guarantee that you record the sound you set out to capture. Cars in particular are very complex to record (kind of like a drumkit) because the sound sources are spread out over an area, and depending on where your ears are in relation to them you hear things differently. Add on top of that the volume, which affects our ears and a microphone in radically different ways, and then throw the recording environment in on top of all of that, and it's very easy to understand that a professional recording sounds different from a cell phone video, which sounds different from the real thing. Recording cars presents a host of technical challenges too, where mic placement in relation to a massive wind source of an intake/exhaust or worse on a moving car means what was a great sound at standstill or near idle becomes unusable at higher RPMs.
I didn't mean to suggest there was no art in recording, but it is a far more mature field than samples - cars weren't the first loud or windy sources people tried to record. My intuition tells me there's a difference between recording for reference purposes, and recording for the purposes of extracting samples.
With modern game audio engines the asset management issue is virtually non-existent.
As long as you shell out the licensing fee for the off-the-shelf product. But we're not talking about Indie devs here, we're talking about a big budget first party game - and a racing game to boot. Every software developer knows, if you can buy it in, do it. But only as long as it delivers what you need and doesn't compromise things in other areas. Note iRacing's decision to abandon FMod integration.
There's still that non-linear growth in time for content production issue as it relates to the ever increasing quality targets.
Technically true but only if your synths sound good. Developing synths costs you development hours, which is in-house code development time. Also there's no pre-existing solution for this type of audio system, so you'll be essentially developing your own audio engine from scratch. Not a lot of studios have the capital to invest dev time for such a thing, and publishers probably wouldn't bother funding such a system because of its limited usefulness outside of a racing game. By comparison you can outsource recordings that work with wwise/fmod to people like me for super cheap, and assuming your library of recordings is of a high enough quality, should last you a great many years before needing to be replaced.
There are pre-existing solutions, actually, mostly in research. There was one commercial product (which I'm sure you're aware of) that flopped in the '90s, because the processing power wasn't there yet.
Quality will be a tradeoff with expression, and expression is lacking with samples, but you get it for free with physically based synthesis. Sonory produces high quality synthesised samples for use in FMod, with advantages not possible with traditional samples (for-free phase alignment, variable source / ambient colouration, component deconstruction etc.)
...Thanks to the power of computers as well as the power of the new consoles, you can now feed a program an audio sample, and the computer can design the manipulations needed to make oscillators and filters reproduce that sound. So, if you had a great recording of a car going through its RPM band, you could feed this recording to the program and let it learn the manipulations needed to recreate every RPM.
There's no evidence this is what PD have done. There is evidence to suggest that this was the route Turn10 were looking into, however...
Then, you take those manipulations and program them to be driven by the game physics engine. What you get is a CPU-intensive but RAM-free audio system.
Not true, you need buffers to work in, and you will typically exchange the RAM usage you had before for the same (equivalent) amount of buffer space. Thankfully the trend is to allow sound more CPU cycles, because contrary to what you said, even sampling requires a lot of CPU (sinc resampling, in Codemaster's case, plus 25 32-bit float bus channels for spatial audio mixing! Etc.)
... However I am quite skeptical that such a system is already in existence in GT6.
Have you played the game, yet? When all I heard were recordings, I didn't believe there was anything different either. When I got my hands on the cars in question, I recognised instantly what was happening, from my own work.
[edit] oh and a blurb on the cost/workflow bit - the key part of the modern synth approach is that it still is dependent on a quality recording to reproduce, and its output can only be as good as the recording it's fed. Also the quality of the audio is dependent on how many oscillators the system is allowed to run - if it can only have 8 oscillators it'll sound like an NES for example.
You still need recordings, but only as a reference, as a minimum. There is no real need to feed the recordings into a pre-processor. I think you have a very old-fashioned view of where modeling synthesis has come.
And I'll use a couple of examples, Toca and Forza, particularly TRD3 and F4.
gear changes and all! All it just needs is the exhaust crackles and pops, maybe an external wastegate sound, induction noise and boom.
