With 3.73, I could open a lengthy, standard wav file for streaming and get the proper media length (in msec or bytes).
With 4.09, the three Sound length parameters (pcm, ms, bytes) repeatedly imply that the wav file is approximately 5 mins long–much too short. This is the process I’ve been using:
[code:31j4rhsq]fmod_Result = System.CreateSound(fmod_System, FileName, FMOD_NORMAL Or FMOD_CREATESTREAM Or FMOD_MPEGACCURATE, fmod_Sound)
fmod_Result = Sound.GetLength(fmod_Sound, m_lenPcm, m_lenTime, m_lenBytes)
I have tried alternate flags, checked the OpenState, and can even play/seek correctly if I add the necessary channel operations.
Would someone please advise me how to correctly analyze a standard wav file that must be opened as a stream (due to its size).
- stdev asked 12 years ago
This is all happening in VB6.
What is perhaps most peculiar is that the apparent length ceiling (just under 5 minutes in my case) doesn’t apply to smaller files which are still longer than 5 minutes.
Let me illustrate (all source files are uncompressed, 16-bit stereo, 44.1KHz WAV).
Scenario 1 – Actual media duration is 55:29.454 (55.5 mins)
m_lenPcm = 12611196
m_lenTime = 285968
m_lenBytes = 50444784
Notice that the length information is incorrect, but collectively consistent with a WAV file of duration 4:45.968.[/list:u:pupo3fg9]
Scenario 2 – Actual media duration is 7:39.333
m_lenPcm = 20256600
m_lenTime = 459333
m_lenBytes = 81026400
In this case, FMOD is properly reporting that the length of the WAV is about 7.5 minutes.[/list:u:pupo3fg9]
[quote:a3x0k3ck]&m_lenPcm, &m_lenTime, &m_lenBytes[/quote:a3x0k3ck]
Long-integer type declarations? No, that’s not the problem.
Remember, I am getting length information; but the length values are not congruent with the source WAV. I just re-checked the seeking, and found that it’s not working if the position is beyond a few minutes. Immediately after opening the WAV, if I seek to, say, the middle or end of the file, I get this type of behavior:
The zeros are the media position reported by FMOD, and the leftmost numbers are the intended seek points (in msec).
If I seek to a position closer to the beginning, FMOD can find its way:
I have tried this without the NONBLOCKING flag (which implies that FMOD should wait), and with the NONBLOCKING flag combined with a monitoring loop that does not release until GetOpenState fails to return value 5 (FMOD_OPENSTATE_LOADING). Still, I’m not sure that this should even matter, because how much “analyzing” is really needed with an uncompressed WAV file?
Please login first to submit.