Playing mp3 files inside the exe file with SoundPlay()

[Guest]

Hello,

i want to know if the function SoundPlay() can get a mp3 sound source from the exe file itself.

in my case, the mp3 files will be inside the exe file in some way and i want to play these files directly from the exe file and without stopping the script("0 = continue script while sound is playing (default)").

i want to do this with SoundPlay() if it is possible.

 

 If not then I need to do it with another function.

Some important points to me:
* Continue script while sound is playing.
* Ability to stop the sound.
* No need for external dll file

* Will work under vista , win7 , win8

I still  did not choose the way I store files in the exe .. I'll deal with this trouble in the future.

 

Thanks for helpers!

 

Edited November 28, 2013 by Guest

[monax]

By reading the AutoIt Help Function Reference for SoundPlay, I will say, no. Cause the parameter of the function is the path to the file to be played.

Since the exe will have the information of the sound inside (if its possible), the function will not know how to extract the sound from the rest of the info.

But maybe im wrong

[Melba23]

gil900,

Zedna's Resources UDF will allow you to play .wav files from within the resource table - but at some cost given the likely size of the sound files.

Otherwise, you could always FileInclude the sound files, play them once they are extracted, and delete them on exit.

As to your additional playing requirements - look at the _Sound UDF which gives you much more control over the sound file than SoundPlay.

M23

[UEZ]

Another way: 

 

Br,

UEZ

[Guest]

 

On 29.11.2013 at 10:27 AM, UEZ said:

Another way: 

 

Br,

UEZ

Thank you!

I loved the way how you save the file exe file.

 

I checked the two things:

1) the way how you save the file in the exe.

2) playing the mp3.

 

About 2), it is a nearly perfect. But the problem is that it does not work if it is compiled in 64bit .. I need it to work even when it is compiled in 64bit.

 

But for now, what is more worrisome to me is 1).

I like this way (how you store a file in exe).

But I did a memory test and I noticed something wrong.

 

Please download the attached example and open the exe file.

The explanation about what I found appears in the example.

test.zip

EDIT:

I reuploaded the test. i had a little mistake before

Edited March 7, 2016 by Guest

[BrewManNH]

It's not wrong, it's got to put the information for the script somewhere, even if you're not using the function it's going to get loaded.

[Guest]

It's not wrong, it's got to put the information for the script somewhere, even if you're not using the function it's going to get loaded.

And that's exactly what I want to prevent.

No need to use the mp3 files all the time...

 

now it look for you small problem because more 800 K is not a big deal.

but what will happens when there are more and more mp3 files? the Additional 800K  can easily change more few megas. Now it is big deal!

i think that with this >Resources UDF, this problem will not occur.

I'm right?

Edited November 29, 2013 by Guest

[Melba23]

gil900,

Storing the sound files in the resource table will still increase the size of the executable. However you store the files (FileInstall, resource table, external dll, etc) you have to find the space somewhere - they cannot magically appear when you want to play them.

M23

[UEZ]

I used fmod.dll because of the smaller DLL size than bass.dll. If you want you can use the x64 bass.dll version and compile your script as x64 executable.

Today most of the PCs have more than 2GB memory and it should be a big problem to embed some binary data into the exe without getting in trouble but you are right that the memory usage of my method is much higher than using resource UDF.

Using a 9.70 mb MP3 file and compiled script without UPX:

 

Resource UDF ->

• exe size: 10.6 mb
• memory usage (working set) without calling the function: 9484 kb
• memory usage (working set) loading the resource: 30320 kb

 

Embedded as Base64 ->

• exe size: 14.5 mb
• memory usage (working set) without calling the function: 51740 kb
• memory usage (working set) calling the function: 63492 kb

 

Used AutoIt version 3.3.9.23.

 

Br,

UEZ

Edited November 30, 2013 by UEZ

[Guest]

I used fmod.dll because of the smaller DLL size than bass.dll. If you want you can use the x64 bass.dll version and compile your script as x64 executable.

Today most of the PCs have more than 2GB memory and it should be a big problem to embed some binary data into the exe without getting in trouble but you are right that the memory usage of my method is much higher than using resource UDF.

Using a 9.70 mb MP3 file and compiled script without UPX:

 

Resource UDF ->

• exe size: 10.6 mb
• memory usage (working set) without calling the function: 9484 kb
• memory usage (working set) loading the resource: 30320 kb

 

Embedded as Base64 ->

• exe size: 14.5 mb
• memory usage (working set) without calling the function: 51740 kb
• memory usage (working set) calling the function: 63492 kb

 

Used AutoIt version 3.3.9.23.

 

Br,

UEZ

I knew I was right..

So I have to decide which method to use.

There are some questions that will affect the final decision. one of them still have no answer(And you can not answer that).

At the end of development, I am going to encrypt the exe file.

1) If I use the method title="">Resources UDF then - is it likely to be critical problems with the files that inside the exe file?

I mean - the encryption of the exe file can cause to the Resources UDF not to work?

I guess so..

if it is true, is there a solution to this problem? Is the solution is complicated?

2) If all of my  mp3 files will take about maximum 1.2mb, then more 1.2mb to the memory use(not in the hardisk as M23 thinking) is not big deal.. so in this case i think I prefer your method. Because it might save me a lot of headache later in development

Edited November 30, 2013 by Guest