The MP3 ‘chirp’ noises when seeking and positioning are back again in 3.70 and now worse than ever.
Any idea how to work around? (one workaround i’m using right now is not using 3.70 😥 )
The chirps you hear when you’re seeking (ie with a scrollbar) is not my biggest concern, but when you pause, and use SetTime to go to a specific position you’ll get a chirp when you start the playback again.
- Harold asked 15 years ago
Ok, got a really small MP3 which shows the problem. Just download it and playback, you’ll notice it sounds good (256 kbit/s Lame 3.92)
Now make a small app which allows you to enter a start position using :
FSOUND_Stream_SetTime( Stream, CuePoint );
Set the CuePont anywhere from 0 to 26, and you’ll hear the sample playback fine. Now set the CuePoint anywhere from 27 to 78 and you will hear a very agessive chirp before/during the first beat.
Try the same with 3.6.3 and you will hardley hear the chirp. It would be nice the eliminate the chirp completely if possible.
Hope this will illuminate the Chirp problem.
You can only hear the problem with the little mp3 sample when you use FSOUND_Stream_SetTime( Stream, 27..78 ). If you set it to a value lower than 27 or higher than 78 you won’t hear a chirp.
I’ve tried the media player. But it starts the sample at the beginning of the song ie pos 0, so then there is never a chirp. I don’t know what the code is behind the dragging of the slider, it sounds good, but i don’t think you’re just updating the soung with multiple FSOUND_Stream_SetTime command’s. 3. when you do drag the slider there is a very big lattency.
If you’re not able to get the sample to chirp, please download this little sample program together with the delphi source so you can hear it for yourself.
Place the test.mp3 in the programs folder.
That might be, but now there’s a new problem. Quite a few MP3’s can’t be played anymore when you use SetTime and go to a specific point. If you look at the data which comes back from FSOUND_LOCK you’ll notice something strange as well. At the points where the MP3 can’t be played, there seems to be no data, while if you move to a point later in time, data is again. Don’t know why, but if you want to hear/see the problem….
http://home.quicknet.nl/qn/prive/h.ouds … ntPlay.zip
Included is a little test app, with mp3 and source (Delphi)
I’ve just tried it with my own program again, once with the current version that uses fmod 3.70, and an older installation that uses fmod 3.62
I loaded the same song in the same way, and I did a lot of FSOUND_Stream_SetTime’s
When using 3.70 I get a chirp almost everytime I do a settime, and in 3.62 I only got a few chirps.
I have tried both hardware and software loading, as well as changing both the stream as the output buffersize.
The strange thing is that I really couldn’t reproduce it with the fmod media player.
But since more people are having problems with it, and because I haven’t changed any of the changing position code, I really think it must have something to do with fmod.
Here is a small example I have recorded from my app, in which you can clearly hear the chirps.
I am absolutely sure that I am using fmod 3.70 at that point.
When I load a stereo MP3 stream with FSOUND_FORCEMONO, GetTime and SetTime don’t seem to work right anymore.
It looks like SetTime needs double the offset compared to when you don’t use ForceMono. GetTime returns something I can’t put my fingers on, it’s not completly wrong, but it ain’t right either because when I use SetTime with the value I got from GetTime, I end up a little earlier in the stream then.
Maybe this is the way it was designed, but I think might be an ‘Undocumented Feature’.
(I use ForceMono with SetPan to “fake” 2 seperate outputs. Player 1 outputs to the left, and player 2 outputs to the right channel)
In 18.104.22.168 this was working fine….. 😥
Ok, I think I’ve found something more :
I think the fmod media player uses FSOUND_MPEGACCURATE.
When I enable this in my program, the chirps disappear.
However, when disabled, the behaviour is as said before : 3.63 produces hardly any chirps, 3.70 produces a chip almost every time.
Same result here. If I use FSOUND_MPEGACCURATE (3.7.0) then the “chirp” is not there!
But I can’t use FSOUND_MPEGACCURATE it’s still to slow (better than before but stil slow)
in 3.6.3 I dont have any “chirp” with FSOUND_MPEGACCURATE or without using FSOUND_MPEGACCURATE
Why do I only have “chirp” on MP3? I don’t have the problem on MP2 files with FSOUND_MPEGACCURATE or without using FSOUND_MPEGACCURATE
Yes, yes, yes, yes, YES!. 😛
The FSOUND_MPEGACCURATE solved the Chirp problem. And even better, finally I can position the stream accurate now. I thought FSOUND_MPEGACCURATE was only needed for VBR files!!! 😉
I can live with the few extra seconds it might take to load a file.
Thank you very much Ken for helping me solve this problem.
Sorry, tried downloading the new version and still have the same problems 😥 . I think the best thing I can do is send you a small MP3 file and point out how the get the problem to the surface.
Problems are with all sorts of MP3’s (128, 160, 192, 256, CBR/VBR) so it’s not really related to ie low bitrates or one type of compressor.
I’ll send you a MP3 file ASAP (if that’s ok with you) i’ll trim it because you can hear the problem with a very small file. If so to witch address can I mail the file?
Please login first to submit.