0
0

Hi, I thought that with FmodEx, seeking should ‘ve been sample accurate, yet when I perform seekData to a position, and then start reading again, it does not always seem to be starting to read at exactly the position I asked for.
When I seek to position zero it seems correct though.

I know the position is not correct because when I set a cue point when starting to read from the beginning, and later return to that cue point reading from just after the beginning of the track, the cue point is not accurate anymore.

Is there a possibility this will be fixed, or is there a way to get the exact sample position that readData will be starting to read from?

Thanks

  • You must to post comments
0
0

it may depend on the file format and if you’re using FMOD_ACCURATETIME, its accurate as far as i can see.

  • You must to post comments
0
0

Here’s a picture of what I tried with a CBR MP3 without fmod_accuratetime.
[img:3kmdodau]http://djdecks.be/images/cuepoint.gif[/img:3kmdodau]
The top image is the cue point set when decoding from the start, the bottom picture is the cue point when returning to it later, and only decoding from the start of the cue point.

I also tried with ogg, and from the first tests it seems is indeed accurate with ogg’s.
I thought that with CBR mp3’s it shouldn’t be necessary to use accuratetime though?

  • You must to post comments
0
0

I can’t say if it is going to be 100% accurate with cbr without using FMOD_ACCURATETIME, but did you try using that flag? Note that mpeg encoders put all sorts of stuff at the start as well as a the famous gap or block of silence.

  • You must to post comments
0
0

Ok thanks, I’ll try it

  • You must to post comments
0
0

Ok, using the fmod_accuratetime flag the problem does indeed seem to be gone.
Just wondering though, but wouldn’t it be possible to simply store the start of the first correct frame when opening the file, so that position and length calculations would be completely accurate on CBR MP3’s, even without the need to open it with accuratetime?

  • You must to post comments
0
0

Its either not cbr, or there is some rubbish at the start that a lot of mp3 encoders like to put there. If you want the non-accurate time flag to also scan the mp3 looking for valid data, then that defaults the point of having the accurate flag in the first place. For simple playback the existing behaviour works fine.

  • You must to post comments
0
0

I just tried again by creating a new 160kbps cbr mp3 from a wav file using the Lamedrop frontend for Lame.
There was no id3 tag or other garbage at the start, but I still had the same problem (which was solved when using accuratetime flag)

I can understand if you don’t have time/want to fix this, but performance-wise, there is quite some difference between scanning for just the first frame, and scanning the complete file. I would even think that this is done anyway when opening the file to see if it is in fact a valid mp3.

  • You must to post comments
Showing 7 results
Your Answer

Please first to submit.