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?
- Adion asked 11 years ago
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.
Here’s a picture of what I tried with a CBR MP3 without fmod_accuratetime.
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?
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?
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.
Please login first to submit.