Does FMOD really works fine with VBR Mp3s? I thought so, but if I play a vbr mp3 in a FMOD_System object a second time (stop, sound_release and create_sound again) it causes an exception. Why? Should I reinitialize the System every time I play a new song?
- psychoquaker asked 12 years ago
I had some crashes even in release 13 as well.
My audio code (and all fmod-ex calls) happen in a vc++ dll, but my main app is visual basic.
I only open songs (in streaming, vbraccurate mode), use read/seek to get data and then close them.
But I’m still not 100% sure about how to reproduce it, and I’m not 100% that it isn’t my fault by mistake.
I’ll let you know if I get some always reproducable error.
- Adion answered 12 years ago
Well, one obvious way to procede here is to email you one of the offending MP3 files. I have one: It is a 5MB, standard song file (320kps/stereo) that ALWAYS crashes my VB/FMOD application (in the manner explained above)
You can use your C code (or whatever code you like), BUT open the song using the STREAM and VBRACCURATE flags, seek or read some data, and then try closing it out (as if you were about to open a new file).
If you don’t have any problems, then I will conclude that this is a VB issue (I can’t speak for all the other VB users).
If you are interested in this experiment, please confirm that it’s ok to email you a 5MB MP3. As I said, I already gave up on this problem months ago, and don’t really care to spend more time on it.
I have also found (since Alpha 6, I think) that FMOD-EX triggers crashes in VB when certain MP3 content are CLOSED. When the app tries to terminate the sound object, an exception error is raised at the point of the FMOD function (so that it’s not possible to read what the function returns).
However, the MP3 files that crash FMOD-EX are not VBR, which has made it difficult for me to find a correlate.
I was able to reproduce this problem with the early VB example Janus put together, after I revised his ‘open’ flags. The only thing I can contribute here is that there does seem to be a problem that originates when certain MP3 content are opened with these flags:
MPEGACCURATE (this has since been renamed)
And, I also found that the crash requires an intervening operation. That is, there is no crash if you open and then close, but there is a crash if you open, seek or read, and then try to close.
I gave up months ago trying to solve this bug, and have come to accept the fact FMOD-EX will crash when certain MP3 content are closed.
Please login first to submit.