Sound playback from embedded data

[King Mocker]

Hi,
Long time listener, first time caller.

I'm wondering if someone can advise on solution for a problem I'm having.
I am writing a program and would like to make it as a standalone/self-contained .exe, without any extra files being required.

I have been looking at Dav's embedded data routine to embed WAV sound files and play them back.
I have had playback success using the WINMM API method PlaySoundA& but this only works with Windows.
The _SNDPLAY command needs a filehandle to work meaning the file must be loaded creating a filehandle.

I've seen RhoSigmas embed method but this extracts the data to files which are then read back it. I'd like to avoid this if possible.

When I saw Steve's post about MEMFILEs I thought I'd hit the jackpot but alas I didn't, unless I misunderstood it, always a possibility.

So, is what I am asking even possible?
Can embedded data be used as a source for _SNPLAY or _SNDOPEN without actual files being used?
Is there another method for me to consider?

Thanks
KM

[Pete]

Samuel and Matt would probably be the best ones to answer your question. QB64PE just had a new release with some advancement in the use of sound features, mostly controlling sounds using _SNDPLAYCOPY.

What I used to do when I wanted a single exe file that had dependencies was to make a exe program that divided the main program from the dependencies. Think of it as a pseudo unzip file. The first time it runs, it creates the main program and the dependencies by writing them as files in the same folder, and then shells itself open.

You'll probably get an answer to your question shortly. Sorry, but I' hardly ever work with sound files, other than wave files for a few special effects.

Welcome to forum. Loved the "Long time listener, first time caller part." Reminds me of CNBC show Mad Money.

Pete

@a740g

@DSMan195276

[mnrvovrfc]

I'm wondering if someone can advise on solution for a problem I'm having.
I am writing a program and would like to make it as a standalone/self-contained .exe, without any extra files being required.

Welcome to the forums. Are you sure you want to do this? Because the EXE files are going to be really large and users are known to complain about a c. 1MB EXE file only to print "HELLO, WORLD!" out of this programming system.

If the wave files are few and short, this might be a good idea of yours. Notice that if you try to use a low sampling rate like 22050Hz this programming system might resample them to 44100Hz or whatever the sound card supports. "Might" because I remember QB64 v0.98 had some code for changing the sampling rate of some wave file, to play it back through "_SNDRAW" or something like that.

One good thing is that a "lossy" format file like OGG could be converted to PCM data by QB64PE, so all that needs to be done is to transfer a "_MEMSOUND" buffer into a string and then use "_DEFLATE$". @Dav 's routine was necessary because the string could contain some nasty control characters especially the ASCII0 that some programs cannot handle well.

Now I don't know how to "put it back" in a way supported by QB64PE, might have to fiddle directly with the "SOUND" field in "_MEM" UDT.

[King Mocker]

Thanks for looking into this.

I only have 6 WAV's totaling 300KB, Deflated likely a lot less. The files have are 44.1khz.

@Pete The _SNDPLAYCOPY takes a handle created by _SNDOPEN so I don't think that'll work.

KM

[DSMan195276]

Unfortunately you can't yet do this, we actually have a related GitHub issue around it here. Basically the problem is that while you can use

_MEMSOUND

to manipulate an existing sound buffer (and thus could make use of that to write your embedded sound into it), there's no way to make a new sound buffer that doesn't involve having a file of the correct length already existing. The GitHub issue I linked is about adding a new command to create an "empty" sound buffer of a particular length, which you could then write to and play all from memory without having to touch any files.

That said, that's probably more complexity than you actually need, it would be better for you if we had a

_SNDOPENBUFFER

type of command that just takes a string that already contains the file contents for the sound you want to play. That has the advantage that you don't need to decode the sound yourself, you could store a regular mp3 (or similar) in your exe and play it directly. I would recommend making a GitHub issue around this and we could discuss it further, I'd have to go look but I imagine it's fairly doable.

[King Mocker]

Thanks DSMan.
I have created an issue in GitHub. #232.
I dont know how to flag it as an Enhancement issue though unless someone does that.