ID:96015
 
BYOND Version:467
Operating System:Windows XP Pro
Web Browser:Firefox 3.6.3
Applies to:Dream Seeker
Status: Deferred

This issue may be low priority or very difficult to fix, and has been put on the back burner for the time being.
Descriptive Problem Summary:
When playing sounds directly after one another, there is an undesired gap between sound A and sound B.

Numbered Steps to Reproduce Problem:
Take a song, cut it in half and play them one after another.

Code Snippet (if applicable) to Reproduce Problem:
src << sound('opening_start.ogg', FALSE, FALSE, 1)
src << sound('opening_loop.ogg', TRUE, TRUE, 1)


Expected Results:
The opening_loop.ogg to play directly after the opening_start.ogg has finished.

Actual Results:
There is a half-second to a second gap between the sounds.

Does the problem occur:
Every time? Or how often? Yes.
In other games? Probably.
In other user accounts? Yes.
On other computers? Yes.

When does the problem NOT occur?
Using the workaround posted below.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Not to my knowledge.

Workarounds:
src << sound('opening_loop.ogg', TRUE, TRUE, 2, 0)
src << sound('opening_start.ogg', FALSE, FALSE, 1)
src << sound('opening_loop.ogg', TRUE, TRUE, 1)
src << sound(0, FALSE, FALSE, 2, 0)


This produces a smaller gap in the audio, but it's still slightly noticeable.

If you want a test demo of the problem, compile and run this demo.
I can confirm this behavior in your demo with those ogg files. I don't know if this is an issue with FModEx having to load the files and interpret them or if it's something more on our end. I found that playing the files in WinAmp produced no gap, so it's nothing wrong with the files themselves. This will take more research to narrow down.

(Out of curiosity, wouldn't you be better off using .mod for a chip tune? Chip tunes make for teeny tiny .mod files.)
Lummox JR wrote:
(Out of curiosity, wouldn't you be better off using .mod for a chip tune? Chip tunes make for teeny tiny .mod files.)

The sounds uses were just a temp thing to provide the demo. They're actually from the original Pokemon Red game for the original Game Boy.

That and I've never really used sound in a project before, so I don't really know all that much about formats, compression et-al.

And I also have no means to convert .mp3/.ogg/.wav to .mod, nor could I find any in extensive searches.
You can't convert .mp3/.ogg/.wav to .mod because they're completely different format types. The former are all raw sound. A module format (.mod, .xm, .it, .s3m) is similar to MIDI except that it lets you define samples for the instruments. You can convert MIDI or modules to raw sound, but not the reverse. While mods gained popularity on the Amiga, I'm really surprised not to see them a lot more often in modern games.

Generally speaking, module files give you much better bang for the buck with music, because most of the file space is taken up by the samples themselves, which in a chip tune are quite small since they're emulating the very simple music sounds from an NES-era machine. FModEx also supports a compressed .xm format called .oxm which compresses all the samples using Ogg, so that's even smaller still. Mods let you have a very long piece with a lot of variation, since a 30 minutes of content aren't appreciably bigger than 2.
There is new code in 475 that should improve this issue by preloading sounds, and by trying to play waiting sounds immediately. I'm not sure if it's a complete fix though because in your demo I still had a very slight delay, though it was much improved.
Guess my minigun will forever have a gap in its audio loop.