[steamer_ctn]

As a result of a question regarding the triggering of curve wheel squeal not working as it was previously, I have done some investigation.

At the moment there appears to already be two ways that wheel squeal can be triggered, as follows:

i) On a Route basis - A SMS file can be triggered when the curve radius drops below certain values. Typically these are hard coded at the moment around 300m.

ii) On a vehicle basis - The CurveForceControlled parameter in the SMS file can be used to "turn squeal on and off". This parameter is currently linked to the curve friction, which in my opinion is not the most efficient value to monitor for curve squeal, as the issues reported have demonstrated.

For a bit of background reading on wheel squeal, this document can act as a starting point. Other research documents can be found on the Internet.

Hence my thinking is that we would achieve a better outcome if we used the wagon's AoA (Angle of Attack). At its simplest, this is the ratio of "Rigid Wheelbase / Curve Radius", and is already calculated in OR. AoA can vary depending upon other factors, and therefore using this value would provide some level of "future proofing" as the calculation method in OR could change over time to take into account different factors, but the AoA output should still represent the same performance outcome.


As one document puts it:

Quote

Curve squeal noise only occurs when the lateral creepage (or angle of attack) exceeds a certain level, around 7~10 mrad.

If we were to go ahead with this approach we would need to consider what to do with items i) and ii) already "in service". I think that keeping them in place only complicates the OR code, and also causes complexity for users.

I also believe that this feature would be better suited to implement on a route basis, rather then a vehicle by vehicle basis.

What level of interest is there in this approach?

[Laci1959]

Hello.

I like point i) more. We use it in several railway tracks (Routes) in Hungary. It was an easier and faster solution to use CurveForceControlled.
The "rigid wheelbase / curved radius" approach would be more realistic, for sure. Would it be built into a vehicle, or into a railway track, with markers placed in the appropriate place? Or the third solution to the program.

Sincerely, Laci1959

[Jonatan]

I like ii because it's simpler to add it to cars, and isn't route-specific so I can get alot more out of it for the same amount of work.

[RR1]

I interpret Peter's ending question (What level of interest is there in this approach?) as Peter asking whether or not there is support to REPLACE the current options 1 and 2 with the new approach which is per the quote (i.e. Curve squeal noise only occurs when the lateral creepage (or angle of attack) exceeds a certain level, around 7~10 mrad).

For the record, I would support the new approach and the (eventual?) abandonment of the current approach . . .

[Weter]

As it likely depends on combination of rigid wheel base (and might be wheel's diameter) and curve's tightness - I'd support "AoA" approach, as Peter suggests.

[Laci1959]

Weter, on 02 February 2024 - 02:22 PM, said:

As it likely depends on combination of rigid wheel base (and might be wheel's diameter) and curve's tightness - I'd support "AoA" approach, as Peter suggests.

Hello.

And the speed.
The point is that due to the taper of the wheels, the bicycle is positioned in the middle on a straight track. IN THEORY. In an arc, gravitational force and centrifugal force fight each other. If the vehicle speed is less than the ideal range, the gravitational force overcomes the centrifugal force and the vehicle rubs against the inner rail. If the vehicle is in the ideal range, there is no friction because the two forces balance each other. Just like in the straight line. If the speed of the vehicle is higher than the ideal range, the centrifugal force is greater than the gravitational force and the vehicle rubs against the outer rail. What is a dark horse for me is the ideal speed range for the given overlift.
"At night, I walked through the entrance of Hatvan, sneaking onto the red light in an elevated curve, and then stopped.
After starting, at low speed, the vehicle "fell onto the inner rail".
A quote from a train driver.
I'm sorry, but sometimes the machine translator is terrible.

Sincerely, Laci1959

[Weter]

Very reasonable addition.
That's why every curved section has it's speed limitation.
Wheel rims have conical surface, rails are inclined towards center by concrete ties, or iron pads (1:20), so their heads surfaces are sloped.
In curves, distanse between rails is increased too.

Quote

What is a dark horse for me is the ideal speed range for the given overlift.

There must be tables in technical rules.
Said measures allow outer wheels to roll upon greater diameter, than inner wheels, what compensates shorter way, given by inner rail, therefore - decreasing creep and wear of wheels, sharing common axle.

[Laci1959]

It depends more on the actual speed of the vehicle.
The passenger train travels at a speed of 80 km/h in a given curve. As it approaches the stop in the curve, it slows down and accordingly falls out of the ideal speed range. In the same place, the express train travels at 120 km/h somewhere near the upper limit of the ideal speed range. Since the curve is designed for a speed of 120 km/h, including the overhang and the associated transition, there is no speed limit.
The speed limit depends on the design speed of the railway line and the design of the curve.

[ErickC]

Some thoughts:

Quote

ii) On a vehicle basis - The CurveForceControlled parameter in the SMS file can be used to "turn squeal on and off". This parameter is currently linked to the curve friction, which in my opinion is not the most efficient value to monitor for curve squeal, as the issues reported have demonstrated.

I can only speak for myself, but I don't use the curve force to turn the stream on and off in the sense that the stream is silent and then is audible like a switch (which is how the current route-based automatic squeal approach works). The initial triggers activate the stream above and deactivate below a certain threshold, but this is for the sole purpose of culling streams to ensure that, regardless of train length, a minimal number of streams is active at any given time as streams rapidly deactivate with distance. If I didn't do this, then the number of streams across a 150-car train would rapidly exceed the 1024 OR can handle at any given time. Conventional MSTS wisdom of abruptly deactivating an entire SMS at some unrealistically short distance doesn't really make sense given that some sounds that freight cars make should be heard at fairly large distances, especially rail hum, so the compromise was heavy culling and optimization.

Insofar as making the stream audible, a volume curve utilizing curve force is applied to blend the low-force and high-force streams in and out as necessary after the streams are activated. Curve squeal is a very nuanced sound effect and doesn't work at all with the on/off approach to any believable degree. The sound at low force is, quite simply, radically different than at high force. At low force, it's more of a mild squeaking sound, at high force the rails begin to make harmonic ringing noises. All of this depends on the speed and the radius of the curve, and the overall volume varies greatly. An on/off approach simply doesn't sound very accurate at all.

Quote

Hence my thinking is that we would achieve a better outcome if we used the wagon's AoA (Angle of Attack). At its simplest, this is the ratio of "Rigid Wheelbase / Curve Radius", and is already calculated in OR. AoA can vary depending upon other factors, and therefore using this value would provide some level of "future proofing" as the calculation method in OR could change over time to take into account different factors, but the AoA output should still represent the same performance outcome.

So long as this is implemented as a variable allowing smooth blending of multiple streams and not an on/off value, I'm all for it. If it's implemented as an on/off value I don't really have any interest.

Quote

I also believe that this feature would be better suited to implement on a route basis, rather then a vehicle by vehicle basis.

I'm not so sure about this. You're then at the mercy of the route developers to make good curve squeal sounds, and very few route developers are particularly good at building sounds as most of them specialize in building routes. Fewer still seem to understand dynamic range, which is why we end up with tiny incidental sounds like birds chirping that are as loud as a Saturn V at liftoff. This last point is pretty important as OR applies a limiter when it renders the final audio output and large numbers of excessively-loud sounds stepping on each other leaves the output highly susceptible to compressor pumping, which sounds awful. I spend much more time managing dynamic range, culling streams, and blending varying distance levels together than I do building frequency curves or editing samples, and I don't think most route developers treat audio as much more than an afterthought.

On the other hand, I could certainly create a "standard" set of SMS files based on the curve squeal streams I already have. Of course, there's no guarantee anyone and everyone would use them, so you're left with a mixed bag. For the end user, though, it would be a pretty simply copy/paste job, and we could even place a set of SMS files in the global folder as a fallback like we do with rolling stock sounds.

I guess I'm ultimately going to do things my own way, but hopefully this gives you some ideas behind my thought process.

[steamer_ctn]

ErickC, on 05 February 2024 - 07:43 AM, said:

Insofar as making the stream audible, a volume curve utilizing curve force is applied to blend the low-force and high-force streams in and out as necessary after the streams are activated. Curve squeal is a very nuanced sound effect and doesn't work at all with the on/off approach to any believable degree. The sound at low force is, quite simply, radically different than at high force. At low force, it's more of a mild squeaking sound, at high force the rails begin to make harmonic ringing noises. All of this depends on the speed and the radius of the curve, and the overall volume varies greatly. An on/off approach simply doesn't sound very accurate at all.

Thanks for the feedback.

The current CurveForceControlled does have a "step function", when there is no curve then force = 0, when train is on the curve force jumps to full friction response, there is no graduated ramp up or down. This is just a comment as I appreciate you have studied it and worked with it a lot more then I have, so I will bow to to expertise in setting it up.

ErickC, on 05 February 2024 - 07:43 AM, said:

I'm not so sure about this. You're then at the mercy of the route developers to make good curve squeal sounds, and very few route developers are particularly good at building sounds as most of them specialize in building routes. Fewer still seem to understand dynamic range, which is why we end up with tiny incidental sounds like birds chirping that are as loud as a Saturn V at liftoff. This last point is pretty important as OR applies a limiter when it renders the final audio output and large numbers of excessively-loud sounds stepping on each other leaves the output highly susceptible to compressor pumping, which sounds awful. I spend much more time managing dynamic range, culling streams, and blending varying distance levels together than I do building frequency curves or editing samples, and I don't think most route developers treat audio as much more than an afterthought.

On the other hand, I could certainly create a "standard" set of SMS files based on the curve squeal streams I already have. Of course, there's no guarantee anyone and everyone would use them, so you're left with a mixed bag. For the end user, though, it would be a pretty simply copy/paste job, and we could even place a set of SMS files in the global folder as a fallback like we do with rolling stock sounds.

It would be my preference that we have a "standard" curve squeal module that route builders could easily into their routes with minimal effort, or even by users as a special addon.

I think that the type of control that you have suggested above could also be "coded" into OR to achieve the best outcomes.

By taking this approach we would end up with commonality and consistency across all routes and stock, rather then the current hit and miss approach that we have, with some routes and some wagons having curve squeal, and others not. Or wagons having both route and wagon based curve squeal.

Implementing this type of approach might make some "legacy" parameters redundant, and that requires ORMT input.