In a different thread, Brett helped me to identify why my use of ReadData was not a reliable method for reading through WAV files…

[quote:v6eyuikb]Channel::setPosition seeks then flushes the buffer. (it is a sound command, and therefore expects to be played)
You shouldnt be calling Channel::setPosition it at all if you used FMOD_OPENONLY.
If you dont use FMOD_OPENONLY, you should be using seekData. It is right next to readData.
You probably just want to use FMOD_OPENONLY then dont call setPosition at all.
I’m starting a new thread because I am running into a variant of the original problem with MP3 content–but presumably the cause is different.

Problem: When working with MP3 files, the number of audio samples extracted with ReadData is often less than the number expected.

I then starting wondering if the problem is not ReadData, but the “expected” part. To ensure that all pcm data are accounted for when using ReadData, one must first know how many samples there are in the source file.

If one uses the OPENONLY flag with compressed media, does FMOD return an accurate value for lenPCM? Surely, it shouldn’t. Isn’t it true that OPENONLY opens the file for read access, but no reading/scanning takes place?

The ReadData method could end prematurely for two reasons. First, the initial sync position is wrong: For instance, ReadData begins at pcm 760, not pcm 0. Second, ReadData syncs and executes correctly, but when the file was opened, FMOD overestimated the number of samples (and so it only appears that ReadData missed some of the data). The original problem I described in the other thread turned out to be an example of the first case. When working with WAV files, use the OPENONLY flag, SeekData and ReadData.

Ok, but that solution does not seem to always work with MP3 content.

Should I, instead, open the file in stream mode, using the MPEGACCURATE flag? I normally open audio files this way, and I’m now wondering if it is possible for the value of lenPCM to be inflated? This would explain why ReadData sometimes ends “prematurely” when working with MP3 files.

If, on the other hand, the length values (lenMsec, lenBytes, lenPCM) are to be trusted, is there some other reason ReadData might miss some of the data?

[EDIT–I should add that when I open a file as a stream using the MPEGACCURATE flag, my application waits for FMOD to complete its initial processing, so the problem should NOT be due to premature length estimates.]


  • SD
  • You must to post comments

[quote:1we17lwi]just use openonly and mpegaccurate together?[/quote:1we17lwi]
😮 Arrg… I inferred from the coverage of OPENONLY that these were mutually exclusive options.

Ok, I will try opening audio files using both the OPENONLY and MPEGACCURATE flags.


  • SD

[FOLLOW UP: There is no problem using these two flags together (despite the paradoxical nomenclature), but it did not resolve the mismatch between the number of samples reported when a file is opened, and the number of samples read using ReadData. I have tested this with and without a SeekData(0) immediately after the MP3 is opened.]

  • You must to post comments
Showing 1 result
Your Answer

Please first to submit.