0
0

Brett,

I ran some tests (in VB) of the ReadData function after I discovered that my audio data were being trimmed at the end. Below is a debugging report from a process in which a 10-second, mono WAV file (441,000 samples) is processed in 512000-byte steps

[list:2yltm709]
Begin sample 0 of 441000
Reading 256000 samples…
ReadData returned 512000 audio bytes. << OK!

Begin sample 256000 of 441000
Reading 256000 samples…
ReadData returned 362224 audio bytes. << WHY NOT 370000 ?

Begin sample 437112 of 441000
Reading 256000 samples…
ReadData returned 0 audio bytes. << YOU STILL OWE ME 7776 bytes!
[/list:u:2yltm709]

The 3rd sequence is executed because ReadData previously returned a non-zero length and the end of the audio file had not been satisfied. Unfortunately, the 3rd sequence fails to glean any more data.

This is just one example. The problem can be duplicated using smaller or larger steps, or smaller or larger WAV files.

The ReadData function is supposed to advance the media position automatically, so you might want to first check if the internal navigation is failing. Another possibility is that the INITIAL media position is wrong. Before each test, the media position is set to pcm 0 (I’ve also tried seeking to pcm 1, just in case 0 is invalid).

Regards,

  • SD
  • You must to post comments
0
0

To update the above post…

I prepared a special WAV file with silence markers at the beginning and end, to determine which region of data is lost (I was just assuming the end samples). It is the beginning samples that are not accounted for when using ReadData.

The shortage problem is likely an artifact of incorrect initial positioning. After opening a stream, FMOD begins ReadData at pcm ????, rather than pcm 0 (or pcm 1). This would fully account for the aforementioned behavior, but I’ll leave it to the development team to investigate further.

Regards,

  • SD
  • You must to post comments
0
0

Isn’t the problem solved when you do a SetPosition to sample 0 just after opening the stream, but before doing ReadData’s ?
I have fixed missing the beginning that way myself.

  • You must to post comments
0
0

Ah, when I use FMOD_OPENONLY as well I don’t seem to need seekData(0) anymore.
Thanks!

  • You must to post comments
0
0

[quote:31wtuo22]yeah maybe you didnt use FMOD_OPENONLY [/quote:31wtuo22]

I am aware of the flag, but was under the impression that there shouldn’t be a problem in stream mode, provided that a manual seek is executed. [In my application, the audio file is first opened in stream mode–for other things–so I won’t open the file again, unless it is necessary.]

Indeed, I do call Channel.SetPosition(0) once, before calling the ReadData’s. So, Adion, are you certain that you were getting ALL beginning samples?

Brett, please clarify… The method I am using, and the method Adion was using, is supposed to work, right? Or is the OPENONLY flag an explicit requirement?

If it turns out that the “Open Stream > SetPosition > ReadData” method is 99% effective by design, will it be left that way?

Thank you for the information thus far,

  • SD
  • You must to post comments
0
0

Got it! Sorry for the false alarm.

  • SD
  • You must to post comments
Showing 5 results
Your Answer

Please first to submit.