Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
SugarCube 2.12.0 — "seek to X seconds" in audio macro not working, possible bug?
I think I have encountered a bug with the audio macro. I am attempting to use the code
audio "Track" time 60 loop play
(obviously with brackets) and it isn't beginning playback 60 seconds into the track, but at the very beginning. I have tried several different audio files, with and without the loop variable, and every single one begins playback at the start. Not sure if I am doing something wrong or what, but it's not doing what it should from what I gathered from the documentation.
audio "Track" time 60 loop play
(obviously with brackets) and it isn't beginning playback 60 seconds into the track, but at the very beginning. I have tried several different audio files, with and without the loop variable, and every single one begins playback at the start. Not sure if I am doing something wrong or what, but it's not doing what it should from what I gathered from the documentation.
Comments
After a quick run through my audio test project in various browsers: I cannot reproduce your issue in recent versions of Firefox, IE, or Edge—seeking worked exactly as it should in every test. I can reproduce it in recent versions of Chrome and Opera—unsure if this is an issue with WebKit or Blink at the moment.
Off-hand, I don't think that this is due to anything on my end, however, I will do additional testing and get back to you. I've appointments today, so I may not reply again until tomorrow or the day after.
Edit:
Okay, I managed to get it back by making all audio references lowercase, and all filenames lowercase, and I don't know if that was the voodoo necessary or WHAT but there we are, this is the 2016 we have to live with.
Tested it under web2exe and the seek function works just fine, so I guess provided that doesn't break that's fine with me because I'm running it wrapped as an application in the first place.
<<audio "wakingb" time 60 volume 0 fadeoverto 30 1 loop play>>
IE, seek to 60 seconds, fade in from 0 to max over 30 seconds, loop, and start playback. I can cope without it as long as the seek to 60 is present but it will make it less jarring if it gently fades in.
In further testing though I think the weirdness came down to the fact that one track was WakingA and one was WakingB — I realised that regardless of case it wouldn't work until I changed the first track to just Waking, and the second to WakingB. I don't know if it's an issue of the two filenames being too similar or what, but that fixed it and made the audio reappear.
I'll also note that you've described one of the tracks as "WakingB", but are apparently referencing it within the <<audio>> invocation as "wakingb".
As noted in the documentation for <<audio>>, both fadeoverto and play are playback actions. You cannot use both simultaneously—it's nonsensical. Use one playback action per invocation.
You want something like the following: NOTE: The order of the actions doesn't really matter, I simply moved loop there because I find it tidier.
Yeah I'm compiling everything on macOS in web2exe, but I tested the Windows version in a virtual machine — that's the best access I have to a Windows device without pestering my friends to try something.
You can ignore how I capitalised it in the thread, that was for brevity's sake. I checked and double checked and triple checked that everything was identical in the actual build, and it was only when I changed it from WakingA/WakingB to waking/wakingb that it would work (I haven't bothered checking if Waking/WakingB also works, I'm inclined to think it will though and for whatever reason the issue was the two filenames being so similar, but your guess is as good as mine and you know more about this than I do!)
Oh perfect — I wasn't sure if it mattered or not, I was going by the documentation syntax, but I will give that a try.
ETA: And that worked, excellent.
For reasons I cannot fathom, upon a seek operation some versions of WebKit (and Blink) modify an audio track's readiness state even when unnecessary—i.e. regardless of if the new position will be within a currently loaded and seekable range. I don't think I can call this a bug, as the specification doesn't forbid the behavior, though it is incredibly daft.
The readiness state modification was confusing SugarCube's audio subsystem into forcibly reloading the audio track, which caused the current time position to be reset, thus undoing the seek.
The next release will contain a workaround for the issue.
This reminds me, not sure if it's kosher to ask or not but do you have a patreon/paypal donation set up for SugarCube? I'm certainly relying on it heavily and can throw some cashmoney in for its development.
Not at the moment, no. I've been hesitant to do so for various reasons, but I perhaps I should.
- Chrome
- Edge
- Firefox
- Internet Explorer
- iOS browser core (both: iOS Safari and iOS Chrome).
- Opera
All passed. It is fixed within every WebKit-/Blink-based browser I have to test in—to be clear, browsers which I had previously been able to reproduce the issue in.As to macOS Safari specifically, I have no direct ability to test it. The best I can do, beyond testing WebKit/Blink in general, is to test the iOS browser core—which, as noted above, I did and which tests as fixed.
Please ensure that you have properly updated your SugarCube v2 install, republished your project, etc. In a build of your project which does not seem fixed, open your browser's developer console and enter the following: If that does not yield something like the following: Then that build has not been updated.
Further I have to change the syntax because this:
<<audio "bgm" loop time 60>>
produces no audio whatsoever, whereas this
<<audio "bgm" play time 60>>
does (albeit skipping the seek command and beginning at the start of the audio track). I haven't tested it in iOS since that's a bit more difficult for me to do and theoretically they're supposed to be the same codebase anyway.
The web2exe build doesn't have a console available, per se, but the developer of it is chasing down the nwjs issue and as soon as I have access to an executable build again I'll see what I can work out.
The first code example there—please use the code tag—does not include a playback action—neither loop nor time alter the playback state. If you want to start playback, then you need to include an action which does that, namely play or the various fade* actions (see: <<audio>>). For example:
As noted above, the iOS browser core (v10.2) was tested and is working with the audio samples I used. If the seek didn't work for you in iOS, then that would be very odd.
If it uses NW.js, then it uses Chromium and thus should work fine, since Chrome has been tested and is working with the audio samples I used.
NOTE: The audio samples I used were MP3 format tracks averaging around 3 minutes in length. I tested files from both my local filesystem and over the network.
I misunderstood your earlier comment re: the variables for playback and changed that in the code. So now audio works, but it doesn't appropriately seek as it should.
My audio was in wav as web2exe can't easily package mp3 files due to licensing reasons, although on a whim I tested it with an identical mp3 version in Safari and it still didn't make a difference; seek is ignored.
Actually I take it back, I'm testing still but there seems to be some weirdness with that particular version. 0.19.1 works as it should, but everything past that doesn't seem to play audio whatsoever.
This is less of an issue for me since I can just build against 0.19.1 instead of the later versions, but I don't know if it's something you want to be aware of.
(emphasis mine)
I tested the compiled build of your project which you made available—built against SugarCube v2.12.1—and the BGM in your project works as intended in all of the following:
- Tested desktop browsers—same set as before.
- NW.js stable releases: v0.16.1, v0.19.1, v0.19.5 (the current release).
- NW.js beta release: v0.20.0-beta2.
Exactly which post-v0.19.1 version of NW.js did you try where it failed?PS: At 60s in, there's only approximately 12s of non-silence left in that track. A 30s fade in seems a bit odd, considering.
That's okay, I appreciate you testing it anyway.
It definitely doesn't work in desktop Safari on macOS. I can't begin to tell you the reason for that, but I've tested every possible permutation I can and audio simply doesn't seek as it ought to. I don't use Google Chrome, but the web2exe build of it works okay so that's more important to me in the end as it's going to be a packaged executable.
I suppose to be pedantic I can host the audio online somewhere and then test in the twine editor if that works, but really as long as it works as a packaged app I'm okay.
I think it was 0.19.4 and then all of the 0.20.0 betas.
That was my fix for the audio not looping seamlessly issue that I posted about in another thread. There's two tracks, one of which is the main audio track and where the loop happens it fades to silence; simultaneously to that the secondary track kicks in just as the main track is fading out and plays over the looping section so you don't notice the transition happening. It is irrelevant for track B at the very beginning, but with a seek of 60 seconds and a fade in it sets the track up to loop in the correct place down the line.
For testing the seek I didn't use that track, obviously, since it would be too difficult to demonstrate it wasn't working — I seek'd the main track 60 seconds in, and since I'm familiar with the audio I know when it was working or not.