[solved probably]Audio Loop Behavior Inconsistency

[godot]

Alright so I put this in the Gripes thread and it most likely did not belong there because it is an actual thing.

I'm getting some really weird behavior on some audio looping. I start it like this:

Code: Select all

play music "<loop 37.68>music/Filename.ogg"

where 37.68 is the actual loop I am using for a specific track. There are no problems here, and it's the same loop functionality I've used for my whole project; however, a problem arises when I do this:

Code: Select all

stop music fadeout 10.0

Again, this is the standard fadeout behavior that I've used the entire time, but something very bizarre happens with it. If I advance my text to the line which triggers the fadeout within 10 seconds of the song ending, it simply cuts itself off abruptly at the end of the song instead of seamlessly looping from 37.68 seconds again while continuing to fade.

I simply don't know what the problem is. It's an ogg file, so it should loop just fine, and I've used up to 4 decimal places in other music loops with absolutely no issue. It loops and fades as intended. All of my sound files are the same format, so I really don't think this is user error.

I first found out about this issue in 6.99.9, but I updated to the most recent version of 6.99.11 and the problem has persisted. I've also used this:

Code: Select all

$ renpy.music.stop(channel="music", fadeout=10.0)

instead of the normal fadeout behavior. This behaves in the same way. If I advance my text outside of that 10-second window, the song fades normally, but if it's within 10 seconds of the song ending it just cuts off. I'm not sure what the issue is.

As for the circumstances surrounding this: The music starts on line 18909, and the fadeout occurs on line 18944. This is the first and only time in the game that the song plays. I tried putting this same code at the very start of the game, and the same thing happened, so it has to be some weird thing with the audio file itself. I tried changing the loop to various other values, with and without decimals, but the behavior was all the same. The time length of the audio that plays after the 37.68 second loop is actually above 10 seconds in length (that is, the total audio file exceeds 47.68 seconds). Changing audio channels from "music" to "sound" also does nothing to alleviate this. It doesn't make any sense unless there's just some bizarre interaction going on with a specific audio file that is no different than any others.

And on top of this, apparently it's not just this file. This seems to be happening with more files than I realized, and it's become especially noticeable given the fact that I'm implementing sound effects which require looping. Is this a known issue? I looked before posting here but didn't find anything, and I would have expected more people to bring this up if it happened in every Ren'Py project.
--------
That's problem number 1. Sorry to bring up both in the same topic, but I'm not sure if they're related or not. Problem number 2 is this: When I build a distribution for my proofreader to use, they experience strange behavior in the loops. Some are misplaced. I don't think this is necessarily an issue with me using decimal places in the loops, because some of the odd loops seemed to happen in tracks which didn't even have specified loop times (they just played to the end and restarted from the very beginning of the file). I can't replicate this on my end.

I'm super confused about all of this. Am I misusing loops? Have I missed something? I can't find any information on this bizarre audio loop behavior anywhere, and I didn't do anything weird to these files except shift my music from flac to ogg in Foobar.

[nyaatrap]

It's mentiond on viewtopic.php?f=8&t=41201&start=30#p436924
Also the best place to put real issues is https://github.com/renpy/renpy/issues

[godot]

It's mentiond on viewtopic.php?f=8&t=41201&start=30#p436924
Also the best place to put real issues is https://github.com/renpy/renpy/issues

Oh, wonderful. I should have thought to check there, but I thought it was a more long-standing problem.

So long as it's a known thing and not some horrible user-side error I was making, and will be eventually resolved, that handles it. I'm just surprised it hasn't been brought up more often by people who tried long fadeouts for things.

I'll assume my other problem with strange looping in the compiled version is just a user error until I find something that indicates otherwise, as it's clearly not related.