I have a problem with FMOD’s FSOUND_Stream_GetTime Function.
If I open a VBR MP3 file without FSOUND_MPEGACCURATE, the function stops giving new values after the playback has ‘passed’ the length of the stream which the inaccurate open believed it would be.
VBR file IS 200 sec long.
Opening without FSOUND_MPEGACCURATE gives a length of 150 sec.
When I play the file, and read the GetTime value, it remains at 150 sec after it reached this point, but plays on.
This was different in old FMOD 3.61. There I got a GetTime value even if the file played longer than FMOD expected.
Note: I can’t use FSOUND_MPEGACCURATE while opening because it’s way too slow. I even can’t preopen the stream, because I have two instances of FMOD running and the user will switch from one instance to the other.
So I need this old behaviour back (I scan for the real length in another thread and set the real length then or read the actual values from a DB).
I think FSOUND_NONBLOCKING won’t help, I still can’t start playback until the file is ‘open’. The problem I have is that I’m building a broadcast software with 2 instances of FMOD, and the user will open one or the other fader in the mixer, which will trigger instance one or two of FMOD. But I think it’s impossible to pass a stream opened by instance one to instance two. I would be happy if you could correct me.
The solution with the internal timer is quite good, opening with MPEGACCURATE would be better (if passing a stream to a different FMOD instance worked).
When my app scans all mp3’s for the database you can check for MPEGACCURATE and store the value in the proper ID3v2 TAG.
Then when i open the song for playback i check the ID3v2 field.
So mostly no need for MPEGACCURATE at opening when you use your own counter and stuff.
Another way is stop using MP3 and use OGG which is far much better.
Would be cool though that FMOD scans the file while playback for your purpose.
Not for me because mine counts down.
Thanks for your input…
OGG: Oh yes, I begin to love this format.
The files will be scanned upon insertion in the database, but it’s the opening of files that are not indexed in the DB (a common case if there’s something to be played quickly from the file system).
I think I will go for the internal counter in case the file is VBR and a quick open returns a value shorter than the real length.
(I also show a countdown, but it’s easy to calculate the remaining lenght if the whole lenght is known)
Another question: What type of ID3v2 library are you using? The one I’ve tried gave the same readings for length as a file opened inaccurately.
[quote="Minetti":m1enq3av]Another question: What type of ID3v2 library are you using? The one I’ve tried gave the same readings for length as a file opened inaccurately.[/quote:m1enq3av]
[code:m1enq3av]String time = GetID3v2String(ID3FID_SONGLEN);
int Time_ms = atoi(time.c_str()); // TLEN[/code:m1enq3av]
I try to read the v2 tag at opening for playback.
If the tag doesn’t have the TLEN i use MPEGACCURATE.
[color=yellow:m1enq3av][b:m1enq3av]Brett this an idea for the next FMOD release ?[/b:m1enq3av][/color:m1enq3av]
Don’t want to seem to be a smart-arse, but winamp can open all vbr files and jump to the given time, without delay.
I have at least one file that can’t be set to a position further than the length calculated by a quick stream open.
And that is the only problem that’s left, but I think I can live with it.
I just checked back… FMOD 3.61 has the same effect. GetTime stops giving back new values when the song passed the length FMOD thinks it has.
Just lucky to have never encountered such an VBR MP3.
The way round, true length less than FMODs calculation works fine.
So, still ideas welcome.
Please login first to submit.